Olá sejam bem-vindos ao canal engenharia de software com ênfase uml Eu sou professor jilian gedes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos ou modelagem utilizando a linguagem uml na aula de hoje eu pretendo continuar o tema sobre arquiteturas de software dessa vez enfocando alguns conceitos básicos sobre projeto arquitetural Então vamos iniciar a nossa aula retomando alguns conceitos básicos uma arquitetura ela é uma estrutura de software que determina como o sistema será dividido logicamente
e Quais componentes estarão estruturados estarão localizados em cada uma dessas divisões uma boa arquitetura de software ela orienta como o software será desenvolvido implantado mantido e evoluído falar um pouquinho sobre componentes os componentes eles implementam os requisitos funcionais do sistema requisitos funcionais são as funcionalidades que o software deverá suportar ou seja funções e serviços que o software deve oferecer ao seus usuários Então os componentes eles encapsulam classes e outros componentes que irão implementar esses requisitos funcionais já a arquitetura do sistema ela é projetada de tal maneira que ela suporte os requisitos não funcionais do software
requisitos não funcionais são características gerais do sistema que devem ser suportadas como desempenho usabilidade confiabilidade escalabilidade manutenibilidade proteção segurança portabilidade entre outros a arquitetura obviamente ela é projetada também para para satisfazer os requisitos funcionais mas os requisitos não funcionais são os que têm uma influência maior sobre que padrão deverá ser adotado de que maneira a arquitetura deverá ser estruturada além disso a arquitetura ela estabelece como os componentes estão organizados em módulos ou camadas por exemplo dependendo da arquitetura eh utilizada e determina como esses componentes e esses módulos se comunicam a escolha da arquitetura irá forte
irá afetar fortemente características como desempenho do software a sua robustez a sua capacidade de distribuição a sua capacidade de manutenção de evolução a sua capacidade de escalabilidade entre diversos outros atributos de qualidade então é preciso identificar quão complexa deve ser uma arquitetura para determinar como atender ao os requisitos não funcionais de acordo com suvel existem três vantagens principais em projetar e documentar a arquitetura do software o summerville e foi uma das principais fontes utilizadas para produzir esse material ah as três vantagens são comunicação com os interessados análise de sistema e reuso em larga escala com
relação à comunicação com os interessados interessados são todas as pessoas que T interesse no software e ou serão afetadas por ele bom a arquitetura ela é uma apresentação de alto nível do sistema dessa forma ela pode ser utilizada como uma maneira de discutir com os interessados a respeito de como o a solução como o software deverá ser estruturado obviamente esses interessados devem ter algum conhecimento técnico para compreender eh alguns conceitos da arquitetura com relação à análise sistema análise sistema é uma das fases da engenharia de requisitos A análise sistema ela permite tornar explícita a arquitetura
do sistema já em um estádio Inicial aliás é importante destacar que a engenharia de requisitos ela tem como saída a sugestão de uma arquitetura geral e abstrata e essa saída seria uma entrada para o o projeto do software onde a arquitetura seria consolidada então o desenvolvimento da arquitetura é uma fase intermediária entre as fases de engenharia de requisitos e de projeto bom mas analisar uma arquitetura do sistema Exige uma que o sistema seja analisado de forma mais profunda eh principalmente levando em consideração os requisitos não funcionais do software então ah produzir uma sugestão de arquitetura
já durante a análise de sistema ã é importante porque as decisões de projeto de arquitetura costumam ter um efeito profundo se o software irá atender ou não a requisitos críticos tais como desempenho confiabilidade manutenibilidade escalabilidade e outros requisitos não funcionais com relação ao Rio uso em larga escala bom uma vez que ã uma arquitetura ela é uma descrição compacta e gerenciável de como o sistema está organizado e como os módulos e componentes operam e se comunicam entre si eh essa arquitetura um padrão de arquitetura costuma ser eh reutilizado aplicado em situações semelhantes e isso permite
apoiar o reuso de software em termos de reutilizar componentes reutilizar módulos e obviamente reutilizar padrões arquiteturais que se comprovaram ser bem-sucedidos para determinadas situações eh falar um pouco sobre decisões de projeto de arquitetura bom o projeto de arquitetura ele é um processo criativo durante esse processo é definida uma estrutura e uma forma de organização para o software o objetivo disso é satisfazer os requisitos funcionais e principalmente aos requisitos não funcionais do software então para isso é preciso tomar uma série de decisões estruturais E essas decisões irão afetar o software e o seu processo de desenvolvimento
então o projeto de arquitetura irá depender do tipo de sistema a ser desenvolvido da formação e experiência do arquiteto dos requisitos específicos para o sistema Como já foi falado os principalmente os requisitos não funcionais então de acordo com o tipo de sistema a ser desenvolvido se pode determinar Qual o padrão de arquitetura mais adequado para aquele sistema ou se é necessário criar uma arquitetura totalmente nova Como já foi falado se existe um padrão de arquitetura que pode ser utilizado para o software isso diminui o custo a complexidade e o risco de desenvolver o software já
se é necessário criar uma arquitetura totalmente nova o custo é muito maior e o risco e a complexidade obviamente são maiores também bom eh de acordo com summerville eh devem se considerar nove questões fundamentais para a a escolha da arquitetura primeira pergunta existe uma arquitetura genérica que pode atuar como modelo para o sistema se existe uma arquitetura que pode ser a base para o modelo que ela pode ser aproveitada adaptada para desenvolver o software isso é bastante útil como eu falei diminui o custo diminui o risco diminui a complexidade uma outra pergunta que deve ser
considerada como o sistema será distribuído ele é voltado para uma máquina individual ou ela pretende ser ou ele pretende ser distribuído entre vários servidores isso influencia bastante o tipo de arquitetura que deverá ser escolhido a questão três é bastante associada com a primeira questão ela pergunta que padrões ou estilos de arquitetura podem ser usados ah atualmente existem vários padrões de arquitetura um padrão de arquitetura é a documentação de uma solução de arquitetura que se mostrou adequada para solucionar um determinado problema e que portanto pode ser reaproveitada reutilizada em situações semelhantes existem vários padrões de arquitetura
como mvc Arquitetura em camadas arquitetura de microsserviços soa Clean arquitect arquitetura cliente servidor entre diversos outros cada uma delas tem pontos fortes e fracos e são mais adequadas ou não para determinadas situações então é função do arquiteto s saber que padrões existem quais são a sua Quais são as vantagens e desvantagens de aplicar o determinado padrão se eu posso aplicar um padrão para desenvolver a arquitetura do meu software como eu falei anteriormente eu tenho uma economia de custo uma economia de tempo os meus riscos e a complexidade do meu software diminuem quarta pergunta qual será
a abordagem fundamental para se estruturar o sistema cinco como os componentes estruturais do sistema serão decompostos e subcomponentes seis que estratégia será usada para controlar o funcionamento dos componentes do sistema sete qual a melhor organização de arquitetura para satisfazer os requisitos não funcionais do sistema como o sistema deve ser estruturado para satisfazer aos requisitos não funcionais aos atributos de qualidade isso vai depender de quais os requisitos não funcionais considerados mais importantes Como projeto de arquitetura será avaliado como a arquitetura do sistema deve ser documentada Essas são questões que o iville recomenda para as decisões de
projeto de arquitetura ah com relação a sistemas que são voltados para computadores pessoais para aplicativos de celular são para sistemas embarcados Então não é necessário projetar uma arquitetura distribuída agora ã se se trata de um sistema de grande porte então provavelmente ele será distribuído entre diversos servidores Possivelmente localizados geograficamente de distante geograficamente Ah então a escolha de como será a arquitetura de distribuição irá afetar o desempenho e a confiabilidade do sistema eh como já foi falado a arquitetura do sistema de software ela pode se basear em um determinado padrão de arquitetura esse padrão de arquitetura
descreve uma forma de organizar o sistema Como já foi falado os padrões de arquitetura eles capturam a essência de uma arquitetura que já foi utilizada anteriormente com sucesso eh no desenvolvimento de vários outros sistemas em situações semelhantes ao projeto atual a Ah então para tomar as decisões sobre a arquitetura do sistema é preciso ter conhecimento sobre quais padrões arquiteturais existem atualmente Em que situações eles podem ser utilizados e quais são seus pontos fortes e fracos ah obviamente Como já foi falado os requisitos estão funcionais eles precisam ser considerados quando se projeta a arquitetura do sistema
eles afetam fortemente a escolha da arquitetura então a deve-se considerar os requisitos não funcionais para que a arquitetura possa atendê-los Então os requisitos não funcionais eles influenciam fortemente os atributos de qualidade de um software eh alguns atributos de qualidade Como já foi falado são desempenho proteção segurança confiabilidade e manutenibilidade desempenho desrespeito ao tempo de resposta do software tempo esperado o tempo de resposta esperado pelo software proteção ã leva em consideração impedir que pessoas não autorizadas roubem informações tenham acesso a informações ou mesmo queer destruam segurança leve em consideração eh tentar impedir que eh acidentes não
intencionais aconteçam confiabilidade é a garantia de que o software eh permanecerá funcionando mesmo que algum erro aconteça ou que que novos hardwares ou manutenções sejam Ah e executadas sobre o sistema manutenibilidade a capacidade que eu tenho de manter e evoluir o meu software existem outros atributos de qualidade se o desempenho for um atributo de qualidade crítico então a arquitetura ela precisa eh estruturar os seus componentes com uma granularidade mais grossa Isso significa que existirão poucos componentes e que eles implementarão muitas funcionalidades possuirão muitos métodos e terão pouca comunicação entre si Então as operações mais importantes
devem estar contidas dentro de um número de componentes pequenos esses componentes deve estar devem preferencialmente estar instalados em um mesmo servidor e não distribuídos pela rede ã esses componentes em geral São relativamente grandes não devem ser pequenos e de baixa granularidade baixa granularidade se significaria que haveria muitos componentes com pouca com poucas funcionalidades cada um implementaria poucas funcionalidades e haveria muita comunicação e solicitação de serviços entre eles Ah então no com relação ao desempenho se espera que seja H que se que que seja escolhido oposto muitos poucos componentes com eh muitas funcionalidades e com pouca
comunicação eh eventualmente pode-se considerar que o sistema seja organizado eh aliás pode se considerar a organização do sistema em tempo de execução Ah isso permite que o sistema ele seja replicado espelhado e executado em diversos servidores uma outra alternativa é se pensarem uma arqu ura baseada em hardware multiprocessado com relação à proteção se a proteção ela for um atributo de qualidade crítico então Eh deve-se utilizar uma estrutura em camadas para arquitetura então um seguir o padrão por exemplo de Arquitetura em camadas pode ser útil para esse tipo de atributo no momento em que os ativos
mais críticos podem estar localizados nas camadas mais internas e eu posso H estabelecer um alto nível de de validação para garantir que pessoas não autorizadas não tenham acesso a esses eh ativos mais importantes então Eh utilizar essa abordagem eh resolve satisfaz o atributo de qualidade e proteção porém pode deixar o atributo ã de desempenho menos atendido uma vez que Em algumas situações Vai ser necessário passar por muitas camadas para ter acesso a determinados recursos e isso pode deixar o sistema um pouco mais lento com relação à segurança se esta for um atributo de qualidade crítico
então ela deve ser Concebida de maneira que as operações de segurança estejam concentradas em um pequeno número de componentes com objetivo de reduzir custos e problemas de validação de segurança Lembrando que segurança na engenharia de software leva em consideração impedir que acidentes não intencionais ocorram então quando esse atributo é crítico deve-se fornecer sistemas de proteção que permitam desligar o sistema de maneira segura quando houver e os componentes de segurança eles precisam implementar medidas para diminuir a possibilidade de riscos de segurança e planos de contingência para diminuir ou evitar o impacto caso problemas ocorram já com
relação ao atributo de confiabilidade ou disponibilidade se este for crítico a arquitetura ela precisa ser Projetada para incluir componentes redundantes espelhados e deve haver uma forte política de eh cópias de segurança ã no caso se esse atributo for crítico é preciso o sistema deve deve-se permitir que o sistema consiga ser atualizado ou substituído que seus componentes consigam ser atualizados ou substituídos eh sem que o software pare e de maneira transparente para os usuários eles não podem perceber que os componentes estão sendo atualizados e também se houver alguma falha que essa falha seja transparente o sistema
deve continuar funcionando da mesma maneira sem que o usuário perceba a que algum serviço se tornou indisponível por isso a importância de replicação redundância espelhamento de recursos entre os servidores com relação à manutenibilidade manutenibilidade desz respeito à capacidade de alterar e evoluir o software se este for um atributo de qualidade crítico então a arquitetura precisa ser Projetada A partir de componentes autocontidos com baixa granularidade e que podem ser alterados de maneira rápida e segura sem causar contraindicações de manutenção ou seja que se algo está funcionando antes que deixe de funcionar depois de uma manutenção Ahã
então nessa situação os produtores de dados eles precisam ser separados dos consumidores então não são recomendadas estruturas de dados compartilhadas então arquiteturas como arquitetura de repositório não é uma não é uma boa alternativa para situação ã então não utilizar estruturas de dados compartilhadas permite que a manutenção do software seja mais rápida e mais simples agora existe um certo conflito entre atender aos requisitos não funcionais aos atributos de qualidade ã em geral não é possível atender totalmente a todos os requisitos não funcionais é preciso Identificar qual quais os requisitos mais importantes realmente os requisitos mais críticos
porque muitas vezes atender um requisito não funcional Ah faz com que outro requisito não funcional possa ser sacrificado então por exemplo em se tratando do requisito não funcional de proteção ele pode afetar o desempenho em situações em que há muitas camadas de proteção para acessar determinados recursos Então essas situações podem deixar o sistema mais lento uma outra situação é com relação à manutenibilidade se eu uso componentes de grande porte então isso costuma melhorar o desempenho do meu software em compensação isso torna a manutenção do software difícil já seu trabalho com componentes de componentes pequenos e
de baixa granularidade isso melhora a manutenibilidade Mas pode deixar o sistema mais lento dessa forma eu tenho que sempre levar em consideração Qual o atributo de qualidade realmente mais importante e projetar a arquitetura para atendê-lo eventualmente tendo que sacrificar ou não atender completamente um outro requisito não funcional Mas então nós concluímos mais essa aula eu espero que ela tenha sido útil para vocês se vocês gostaram desse vídeo peço que vocês compartilhem com quem possa se interessar ã se o vídeo Foi útil para vocês então eu peço que vocês curtam esse vídeo se ainda não estão
inscritos eu peço que se inscrevam nesse canal obrigado pela atenção nós nos vemos nos próximos vídeos l
