Buscar

Colaborar - Av2 - Arquitetura de Software


Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

 Arquitetura de Software (/aluno/timeline/in…
Av2 - Arquitetura de Software
Sua avaliação foi confirmada com sucesso
Colaborar   (/
notificacao/
index)
×
Informações Adicionais
Período: 26/02/2024 00:00 à 08/04/2024 23:59
Situação: Cadastrado
Tentativas: 1 / 3
Pontuação: 2500
Protocolo:
Avaliar Material
1)
a)
b)
c)
d)
e)
2)
a)
b)
c)
d)
e)
3)
Os princípios de design de software são diretrizes fundamentais que ajudam os desenvolvedores a criar sistemas de software eficientes, flexíveis e de alta qualidade. Esses princípios
fornecem orientações sobre como organizar o código, estruturar as classes e módulos, lidar com a complexidade e garantir a manutenibilidade do software ao longo do tempo. Esses
princípios são baseados em décadas de experiência na indústria de desenvolvimento de software e foram consolidados em uma série de conceitos chave. Esses princípios, entre outros,
ajudam os desenvolvedores a criar sistemas de software mais robustos, de fácil manutenção e adaptáveis a mudanças. A compreensão e aplicação desses princípios são essenciais para o
desenvolvimento de software de alta qualidade.
Qual é o objetivo dos princípios de design de software?
Alternativas:
Organizar o código de forma estética e elegante.
Facilitar a compreensão e manutenção do software ao longo do tempo. Alternativa assinalada
Criar sistemas de software complexos e intrincados.
Minimizar a flexibilidade e adaptabilidade do software.
Aumentar a complexidade do software para desafiar os desenvolvedores.
O design de software é fundamental no desenvolvimento de sistemas eficientes. Envolve a criação de soluções que atendam às necessidades dos usuários e do negócio, garantindo
qualidade e desempenho. Para entender o design de software, é importante considerar objetivos, restrições, alternativas e representações. Levar em conta as restrições impostas ao
projeto é crucial. Isso inclui prazos, recursos disponíveis e requisitos técnicos. Por exemplo, ao desenvolver um aplicativo móvel para um evento, é necessário adaptar o design ao prazo
apertado, exigindo uma abordagem ágil e eficiente. Durante o processo de design, várias alternativas são exploradas para atender aos requisitos. Isso envolve a seleção cuidadosa de
tecnologias, arquiteturas e abordagens. Por exemplo, em um sistema de comércio eletrônico, a equipe pode considerar diferentes alternativas, como uma abordagem monolítica ou uma
arquitetura de microsserviços, dependendo dos requisitos específicos. A representação visual, como diagramas, facilita a comunicação e compreensão do design. Além disso, a
documentação adequada permite que os desenvolvedores entendam o raciocínio por trás das decisões de design e auxilia na manutenção do software. A divisão adequada do software em
componentes coesos é essencial. Isso facilita alterações isoladas e reduz o impacto em outras partes do sistema. Por exemplo, em um sistema de gerenciamento de biblioteca, é possível
dividir o software em módulos para o cadastro de livros, gerenciamento de empréstimos e geração de relatórios. Em resumo, o design de software é um processo complexo para o
desenvolvimento de sistemas eficientes. Envolve objetivos, restrições, alternativas e representações. A divisão adequada e a seleção de alternativas são aspectos cruciais para o sucesso do
design de software (MARTIN, 2019).
Qual dos seguintes elementos é um princípio fundamental no design de software que busca ocultar os detalhes internos do software e fornecer interfaces bem definidas para interagir com
o sistema?
Alternativas:
Restrições
Alternativas
Representações
Encapsulamento Alternativa assinalada
Divisão adequada
A empresa XYZ é uma startup de tecnologia que desenvolveu um aplicativo móvel inovador para ajudar pessoas a encontrar restaurantes e fazer reservas em tempo real. O aplicativo já
está em funcionamento há algum tempo e ganhou popularidade rapidamente, atraindo um grande número de usuários. No entanto, com o aumento da base de usuários e a crescente
demanda, a empresa enfrenta desafios em relação à escalabilidade do sistema. O aplicativo atualmente está hospedado em servidores locais, o que pode limitar a capacidade de atender a
um grande número de acessos simultâneos e pode resultar em tempos de resposta lentos durante os horários de pico. Além disso, a equipe de desenvolvimento percebeu que algumas
funcionalidades do aplicativo estão se tornando complexas de manter e evoluir devido à falta de uma arquitetura bem definida. O código do aplicativo tornou-se menos modular e a adição
de novos recursos está se tornando cada vez mais trabalhosa e propensa a erros. A alta administração da empresa está preocupada com esses problemas e solicitou que a equipe de
arquitetura de software tome decisões estratégicas para enfrentar esses desafios e garantir o sucesso contínuo do aplicativo.
Com base no cenário da empresa XYZ, qual das seguintes decisões descritivas seria mais adequada para abordar os desafios de escalabilidade do sistema? 
https://www.colaboraread.com.br/aluno/timeline/index/3353030405?ofertaDisciplinaId=2155072
https://www.colaboraread.com.br/aluno/timeline/index/3353030405?ofertaDisciplinaId=2155072
https://www.colaboraread.com.br/aluno/timeline/index/3353030405?ofertaDisciplinaId=2155072
https://www.colaboraread.com.br/aluno/timeline/index/3353030405?ofertaDisciplinaId=2155072
https://www.colaboraread.com.br/aluno/timeline/index/3353030405?ofertaDisciplinaId=2155072
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
https://www.colaboraread.com.br/notificacao/index
javascript:void(0);
javascript:void(0);
a)
b)
c)
d)
e)
4)
a)
b)
c)
d)
e)
5)
a)
b)
c)
d)
e)
Assinale a alternativa correta
Alternativas:
Selecionar um estilo arquitetural cliente-servidor para facilitar a comunicação entre os dispositivos móveis dos usuários e os servidores centrais da empresa
Migrar o aplicativo para uma infraestrutura em nuvem escalável, como o Amazon Web Services (AWS) ou o Microsoft Azure, para lidar com os picos de tráfego e
garantir maior disponibilidade
Alternativa assinalada
Utilizar um padrão de projeto de balanceamento de carga para distribuir as solicitações de usuários entre vários servidores e evitar gargalos de desempenho
Integrar um banco de dados distribuído para garantir a rápida recuperação de informações e a redução da latência nas operações de consulta
Documentar todas as decisões arquiteturais, incluindo os padrões de projeto e estilos arquiteturais selecionados, para facilitar a comunicação entre os membros da equipe e garantir
uma evolução organizada do sistema
De acordo com a abordagem de ROZANSKI E WOODS (2012) para capturar diferentes perspectivas sobre a arquitetura de software, os viewpoints são utilizados para:
Assinale a alternativa correta
Alternativas:
Criar uma única visão abrangente da arquitetura de software, ignorando as preocupações específicas dos stakeholders
Descrever a organização interna do sistema e a relação entre o sistema e seu ambiente externo Alternativa assinalada
Limitar a documentação arquitetural a uma única perspectiva para facilitar a comunicação entre os membros da equipe de desenvolvimento
Ignorar as necessidades e fluxos de dados dentro do sistema, concentrando-se apenas nas decisões arquiteturais
Apenas fornecer uma estrutura sistemática para a utilização de requisitose metas estabelecidas pelos stakeholders
Imagine que uma equipe de desenvolvimento está trabalhando em um novo sistema bancário que visa melhorar a experiência dos clientes ao realizar transações financeiras. Eles
decidem utilizar a abordagem de ROZANSKI & WOODS (2012) para capturar diferentes perspectivas sobre a arquitetura de software. Após identificar os stakeholders, eles definem três
viewpoints relevantes para o projeto:
1. Viewpoint de Segurança: Concentra-se em garantir a integridade, confidencialidade e disponibilidade dos dados do cliente e das transações financeiras, abordando as preocupações dos
clientes e do departamento de segurança do banco.
2. Viewpoint de Desempenho: Explora a eficiência do sistema, levando em conta a velocidade e capacidade de processamento das transações, e atende às necessidades do setor de TI do
banco.
3. Viewpoint de Experiência do Usuário: Enfoca a usabilidade e a interface do sistema, garantindo que os clientes possam realizar suas transações de forma intuitiva e agradável.
Assinale a alternativa que representa a importância dos viewpoints na abordagem de Rozanski e Woods para o desenvolvimento do sistema bancário:
Alternativas:
Os viewpoints são desnecessários e apenas aumentam a complexidade do projeto, pois uma única perspectiva seria suficiente para atender a todas as preocupações dos stakeholders
Os viewpoints são relevantes apenas para a equipe de desenvolvimento, permitindo-lhes visualizar a arquitetura do sistema sob diferentes perspectivas técnicas
Os viewpoints são cruciais, pois cada um representa as necessidades e preocupações específicas de diferentes stakeholders, permitindo que as decisões arquiteturais
sejam tomadas considerando todas as partes interessadas envolvidas
Alternativa assinalada
Os viewpoints são úteis apenas para fins de documentação e não têm impacto significativo no desenvolvimento e na qualidade final do sistema
Os viewpoints são aplicados apenas em fases iniciais do projeto e não têm relevância para a implementação real do sistema

Continue navegando