Arquituras de software e conceitos básicos sobre elas que todo desenvolvedor deve conhecer
- Eduardo Nepomuceno da Rocha
- 5 de mar. de 2024
- 4 min de leitura
Atualizado: 13 de mai.
O trabalho de todo desenvolvedor de software vai além de programar ou entender códigos. É preciso compreender todo processo de construção de uma solução de software. O domínio das etapas, conceitos gerais e boas práticas do ciclo de produção é essencial, pois não depende da linguagem do sistema. Por isso, hoje trago aqui as arquiteturas mais simples de software e conceitos básicos desse mundo.
Ciclo de vida de software
Um ciclo comum se baseia nas exigências técnicas (requisitos), design(arquitetura), implementação, verificação e manutenção.
Modelo WRSPM
É um modelo de referência para entender a conexão entre requisitos e especificações e mundo real. W = Wolrd, R = Requirements, S = Specifications, P = Program, M = Machine. W assume o que será usado para desenvolver o sistema, se está na internet, se consumirá eletricidade, princípios básicos. Requisitos são as definições do problema em termos de um usuário do sistema. Especificações são os requisitos técnicos, a ligação da ideia de solução ao sistema por si só. Programa é o programa e seu código, enquanto M de máquina são as especificações de hardware.
Modelo Visual WRSPM
Variáveis do WRSPM
Eh - Elementos do environment(ambiente) que estão escondidos do sistema, exemplo um cartão de crédito por si só.
Ev - Elementos que estão visíveis ao sistema, como um chip, etc.
Sv - Elementos do sistema que são visíveis ao sistema, tais como botões, telas, no geral front-end
Sh - Elementos do sistema não visíveis, por exemplo, as funcionalidades back-end
Ev e Sv são especificações, enquanto Sh pertence ao sistema e Eh ao ambiente no modelo visual.
Padrões de Arquitetura
Arquitetura é o mais alto nível de design. É a ligação entre ideia e realidade. Arquiteturas ruins não são corrigidas com boas práticas de código. Não é algo que possa simplesmente ser corrigido uma vez que foi implementada. Arquitetura de software deve quebrar sistemas maiores em sistemas menores e focados.
Pipe-And-Filter
Enquanto Pipe trata de conexões entre dados, filtros são operações de seleção/filtragem.
Nessa arquitetura seus componentes são filtros. Esses filtros possuem um conjunto de entradas e um conjunto de saídas, realizando um processamento de um stream de dados. No java, por exemplo, é fácil implementá-la por meio dos streams Java, que possuem um aspecto de programação funcional. Os conectores dessa arquitetura são pipes, que são condutores, transmitindo as saídas de um filtro para as entradas de outro.
Outras características da arquitetura de pipe e filtros, no que diz respeito a sua implementação, são:
As tarefas do sistema são dividas em uma sequência de estágios de processamento. Esses estágios dependem apenas da saída do estágio anterior. É uma característica funcional e de dados em série.
O aspecto, no entanto, de filtros, não impede realimentação, isto é, que os pipes interajam com estados anteriores. Isto é, não é necessariamente sequencial.
Arquitetura Cliente-Servidor
Essa arquitetura trabalha com um servidor central. Esse servidor é contactado por diversos clientes que solicitam informações, então o servidor devolve uma resposta. É o padrão mais comum na internet.
Essa arquitetura separa os interesses devido à independência dos clientes, possui balanceamento de carga e boa escalabilidade, já que basta aumentar a capacidade computacional do servidor. No entanto, as falhas no servidor e custos de manutenção são pontos desvantajosos.
Padrão Mestre-Escravo
Nessa arquitetura o mestre sempre dirá aos escravos o que fazer. Não há influência dos pontos escravos sobre o mestre. É uma arquitetura centrada na figura do mestre na qual os escravos só atuarão diante de uma ordem do mestre. Os escravos são independentes. Em linguagem de software, o mestre no geral é um controlador. Os escravos não se comunicam. Esse modelo é eficiente porque promove a distribuição de cargo, otimizando a utilização de recursos. É comumente usado na computação distribuída, pois facilita o gerenciamento de tarefas complexas e também é fácil estabelecer sincronismo. Também usado com bastante frequência para alimentar base de dados e redes.
Arquitetura em camadas
Essa arquitetura divide o software em camadas. As camadas não trabalham com comunicação cruzada. Cada camada é bem definida, deixando mais prático identificar falhas em funcionamento por exemplo. Uma camada pode receber dados de outra, mas a atuação não vai além disso. Um padrão muito comum é a arquitetura MVC. Em caso de necessidade de uma comunicação cruzada, haverá uma camada intermediária que receberá o dado de uma camada e fornecer à outra. Por exemplo: No MVC a view fica com a visão e o front-end em HTML, Javascript e outros. O modelo fica com o banco e entidades, enquanto o controlador faz a comunicação entre ambos. O sistema de camadas é organizado hierarquicamente. Em APIs é notável que uma camada oferece serviços para uma camada superior e também utiliza de camada inferior. Por exemplo: O padrão com repository, service e controller em java. Esse padrão também observado no modelo OSI de redes, sendo um conceito que vai além de engenharia de software.
O arquiteto deve pensar em sempre em comunicação de camadas adjacentes.
Esse modelo apresenta como vantagens uma fácil compreensão(níveis crescentes de abstração), desenvolvimento independente, no geral as dependências terão restrição de 2 camadas e fácil manutenção de código e padronização. Como desvantagens, é importante ressaltar que uma mudança numa camada inferior pode propagar as mudanças em camadas superiores. Escrever testes também pode tornar-se algo trabalhoso.
Considerações básicas para criar uma arquitetura de software
Ter noção de como um programa é decomposto, sua iteração interna e também com o mundo externo
Modelar como a estrutura do sistema se comporta
Quebrar o projeto em módulos e subsistemas.
Subsistemas : Integração, independência de sistemas
Módulo Componente de um subsistema que não funciona por si só.
Comments