AO2 - Segurança e Arquitetura Orientada a Serviços 3,0 de 6,0

Prévia do material em texto

AO2
Iniciado: 13 jun em 21:33
Instruções do teste
Importante:
Caso você esteja realizando a atividade através do aplicativo "Canvas Student", é necessário que você clique em "FAZER
O QUESTIONÁRIO", no final da página.
0,6 ptsPergunta 1
Leia o texto abaixo:
SOA vs. Microsserviços: qual é melhor para o seu negócio? 
Definir qual arquitetura de software é a melhor solução para o seu negócio vai depender do tipo de
problema que você quer resolver. 
No SOA, os serviços são independentes da plataforma ou da tecnologia. Eles podem ser desenvolvidos
usando qualquer linguagem de programação em qualquer sistema operacional, desde que se comuniquem
entre si. 
O resultado disso é a integração com outros sistemas, serviços e aplicações. Contudo, toda a arquitetura
orientada a serviços é baseada em padrões de comunicação. Então, apesar da interoperabilidade e
diversidade de aplicações e serviços dentro de um mesmo produto, eles utilizam a mesma comunicação. 
Já o foco da arquitetura dos microsserviços é a independência. Eles não precisam, necessariamente, ser
escritos usando a mesma linguagem de programação. Assim, os microsserviços são recomendáveis,
principalmente, para projetos de alta complexidade, ajudando a antecipar entregas. 
Entretanto, os microsserviços demandam cuidados e esforços adicionais para manter sua gestão,
governança e segurança operacional. 
Se bem implantados, tanto os microsserviços quanto o SOA trazem benefícios importantes para uma
empresa. 
Para algumas empresas, o ideal é que eles coexistam, em um modelo de integração de dados híbrido,
com cada um carregando suas vantagens e sendo utilizados para projetos em que melhor se adaptam.
Nesse caso, a experiência com as tecnologias pode ser a diferença entre as boas e as más decisões para
seus projetos.
Fonte: SOA vs. microsserviços: como determinar qual é o ideal? Supero, 11 mar. 2021. Disponível em:
https://www.supero.com.br/blog/soa-vs-microsservicos-como-determinar-qual-e-a-arquitetura-ideal/. Acesso
em: 17 jun. 2022.
Considerando as informações apresentadas, avalie as afirmações abaixo:
I. A SOA tenta trazer componentes compartilhados para serviços mútuos e reutilizar o máximo possível,
pois microsserviços são sobre modularização e desacoplamento de recursos de backend.
II. A abordagem SOA foi desenvolvida para a era nativa da nuvem, onde os serviços individuais são
expostos interna e externamente, pois qualquer microsserviço deve ser o mais autônomo possível.
III. Um microsserviço completo pode ter seu próprio sistema de registro e manipulação de autenticação,
pois SOA é uma maneira de construir um backend que pode ser dimensionado no desenvolvimento.
IV. Enquanto os microsserviços maximizam a reutilização, a SOA tenta ser clara sobre o contexto limitado,
resultando eventualmente na duplicação, pois SOA é um estilo de arquitetura, não uma implementação
específica.
É correto o que se afirma em:
A+
A
A-
II e III, apenas.
I e IV, apenas.
I e II, apenas.
I e III, apenas.
II e IV, apenas.
0,6 ptsPergunta 2
Leia os textos a seguir:
Texto I
As ontologias leves (lightweight ontologies) são aquelas que não se preocupam em definir detalhadamente
cada conceito representado. A principal ênfase das ontologias leves é definir a taxonomia que representa a
relação hierárquica entre conceitos. Esse tipo de ontologia vem sendo utilizado na Web para categorizar
grandes quantidades de dados, principalmente em portais como Yahoo! e AOL (Bechhofer et al., 2006;
Bizer, 2009). Ontologias pesadas ou densas (heavyweight ontologies) enfocam não apenas a taxonomia,
mas também a representação rigorosa da semântica entre os conceitos. O desenvolvimento de ontologias
pesadas requer a definição de cada conceito, a organização desses conceitos baseados em princípios
bem definidos, uma definição formal da semântica entre os conceitos e suas relações, além de outras
considerações. Para criar bases de conhecimento reusáveis e compartilháveis é fundamental definir
ontologias pesadas.
Ontologias de domínio e de tarefa são necessárias para criar sistemas mais flexíveis e inteligentes e que
possam ser aplicados em diversos domínios. A ontologia de domínio define e caracteriza o domínio no qual
as tarefas ocorrem, e a ontologia de tarefa representa os processos e atividades para resolver um
determinado problema abstraindo o contexto do domínio. Em outras palavras, a ontologia de domínio
representa o conhecimento sobre um tópico, enquanto a ontologia de tarefa representa a habilidade de
aplicar esse conhecimento para resolver problemas em diferentes situações. Essa distinção é muito
importante, pois, por meio dela, torna-se possível criar sistemas e bases de conhecimento mais modulares,
compartilháveis e extensíveis.
Para criar uma ontologia de tarefa, inicialmente, os passos de resolução de problemas precisam ser
decompostos em ações básicas. Além disso, a estrutura hierárquica que representa as restrições para
executar essas ações deve ser desenvolvida.
Fonte: ISOTANI, S.; BITTERNCOURT, I. I. Dados abertos conectados. 2015. Disponível em:
https://ceweb.br/livros/dados-abertos-conectados//capitulo-3/. Acesso em: 28 jun. 2022.
Texto II
Por diversos motivos a criação de ontologias de domínio, como é o caso da Ontologia SOA, baseadas em
ontologias de fundamentação é de extrema importância. Isso por que as ontologias de fundamentação
permitem o estabelecimento de ontologias de domínio mais consistentes, expressivas e semanticamente
mais ricas.
Fonte: FERNANDES, M. Ontologia para SOA. TAAS – Thoughts as a service, 3 jul. 2011. Disponível em:
https://thoughtsasaservice.wordpress.com/2011/07/03/ontologia-para-soa/. Acesso em: 28 jun. 2022.
Considerando as informações apresentadas, avalie as afirmações abaixo:
I. Devido ao fato de existirem poucas tecnologias que cobrem a área de SOA, o desenvolvimento e
avaliação de arquiteturas compatíveis com SOA é especialmente interessante. A SOA é frequentemente
caracterizada como um estilo que oferece suporte a serviços de rede fracamente acoplados.
A+
A
A-
II, apenas.
I e III, apenas.
III, apenas.
I e II, apenas.
II e III, apenas.
II. A SOA considera os serviços como blocos de funcionalidade dependentes e fracamente acoplados que
trocam informações por meio do uso de metadados. Os serviços em SOA representam conhecimento
grosseiramente granulado de um domínio de aplicativo.
III. Quando o conhecimento é reunido e formalizado como uma ontologia, a realização de uma avaliação
de forma mais exaustiva é facilitada. Um conector é independente de aplicativo e genérico se não
introduzir dependência real.
É correto o que se afirma em:
0,6 ptsPergunta 3
Leia o texto e analise a imagem a seguir:
As principais diferenças entre SOA e API estão relacionadas à governança e ao escopo. SOA é uma
metodologia/framework que será usada pelo departamento de TI para prover soluções às demais áreas da
empresa, se preocupa em saber quais sistemas farão parte do parque tecnológico, quais áreas poderão
acessar quais informações, linguagem de programação, fluxo de informação entre as áreas, integração
entre aplicativos e outros.
As iniciativas de API são mais específicas e focadas no desenvolvimento e uso de determinadas
aplicações ou atividades. As APIs podem ser REST ou SOAP, isso vai depender do tipo de agilidade e
segurança que você precisa para expor aquela informação. Se as APIs estiverem reunidas em um portal,
isso permite que os desenvolvedores, bem como parceiros de negócios, procurem essas APIs que
precisam, peçam acesso a elas e venha a fazer os usos necessários para agilizar determinadas atividades,
automatizar processos, trazer visibilidade a uma determinada etapa do processo, os objetivos são quase
que infinitos.
Assim, como em toda iniciativa SOA, as APIs internas precisam ser bem planejadas e projetadas, precisam
ter nível de controle de políticas e operacionais e ser monitoradas e governadas de forma eficaz. Somente
dessa maneira elas serão verdadeiramente bem-sucedidas.
Fonte: Estratégia de API não éestratégia de SOA. Vestígio, 24 mar. 2016. Disponível em:
https://vertigo.com.br/estrategia-de-api-nao-e-estrategia-de-soa/. Acesso em: 27 jun. 2022. Adaptado.
A+
A
A-
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
As asserções I e II são proposições falsas.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
Refletindo sobre as diferenças entre API e SOA, avalie as seguintes asserções e a relação proposta entre
elas.
I. Segurança e governança, e aplicativos e serviços bem documentados são alguns dos muitos benefícios
das APIs, pois API é um software de intermediação que permite que dois aplicativos conversem entre si.
PORQUE
II. APIs são uma abordagem de projeto de arquitetura que fornece serviços a componentes por meio de um
protocolo de comunicação em uma rede, pois as empresas que adotaram APIs agora estão migrando para
uma abordagem de microsserviços.
Com base nas asserções, assinale a opção correta:
0,6 ptsPergunta 4
Leia o texto a seguir:
A sigla ESB, e outra relacionada - SOA - podem ser uma fonte de confusão. ESB se expande para
Enterprise Service Bus. SOA significa Arquitetura Orientada a Serviços.
Isso ainda não explica muito por isso damos aqui mais informações em linguagem simples, sem
demasiado jargão corporativo [...]
Pense no que acontece quando você entra na aplicação frontend do seu banco:
1. Seu nome é exibido;
2. O saldo da conta está lá;
3. Seus cartões de crédito e débito são apresentados;
4. A lista de seus fundos de investimento pode estar lá;
5. Você obterá uma lista pré-calculada de empréstimos atraentes em que você poderá estar interessado.
Agora, é muito provável que todas estas partes pertençam a diferentes sistemas e aplicações, sendo que
cada qual expõe dados através de uma interface de algum tipo (REST, JSON, AMQP, Kafka, SOAP, FTP,
CSV, realmente não importa):
No. 1) é de um CRM rodando em Linux e Oracle;
No. 2) é de um sistema COBOL em um mainframe z/OS;
No. 3) diz-se que é de um mainframe mas ninguém lhe dá mais detalhes, dizendo apenas que preferem
CSV a qualquer outra coisa
No. 4) é de uma mistura de PHP e Ruby rodando em Windows;
No. 5) é de PostgreSQL, Python e Java rodando em Linux e IBM System i.
A questão agora é, como você faz a aplicação frontend conversar com essas de 1 a 5? Bem, você não faz.
Esta é a base fundamental para garantir que estes tipos de ambientes podem escalar acima de um
punhado de sistemas. Você não pode deixá-los falar diretamente uns com os outros.
Fonte: O que esb e soa são, afinal? Zato. Disponível em: https://zato.io/docs/intro/esb-soa-pt.html. Acesso
em: 27 jun. 2022.
Qual alternativa representa corretamente um dos benefícios do ESB?
A+
A
A-
Os serviços SOA podem ser criados do zero.
Cada serviço em uma SOA incorpora o código e os dados.
Um ESB centralizado oferece o potencial de padronizar.
É possível implementar uma SOA sem uma arquitetura ESB.
Um ESB é um componente essencial de SOA.
0,6 ptsPergunta 5
A maneira como as equipes modernas trabalham exige que as equipes de TI sejam flexíveis e adaptem seu
processo de gerenciamento, pois o gerenciamento de ativos de TI garante que os itens valiosos, tangíveis e
intangíveis de uma organização sejam rastreados e usados.
Leia o trecho abaixo:
Por que a gestão de ativos de TI é fundamental? [...]
Organização e transparência
Um dos primeiros fatores é o aumento da transparência. Uma vez que a empresa conta com relatórios
detalhados acerca de seus ativos, é possível obter clareza quanto aos equipamentos utilizados e quanto à
forma como são utilizados. Desse modo, a gestão consegue tomar melhores decisões, com uma visão
ampla e precisa. Fica mais fácil gerenciar questões complexas como licenças e contratos, ciclos de vida,
versões de software, entre outras.
Segurança
A segurança é certamente outro dos impactos positivos de uma boa gestão de ativos. Ao controlar o ciclo
de vida e a necessidade de manutenção e atualização dos equipamentos, a empresa se mantém
consistente e protegida diante de ataques e explorações criminosas. Ou seja, é possível eliminar as
brechas principais de modo a otimizar a produtividade e evitar grandes problemas com a TI.
A gestão de ativos inclui também uma preocupação com o uso dos softwares certos para a gestão da
segurança, como firewall, backups e antivírus. Com a visão desses sistemas como bens gerenciáveis, a
empresa consegue otimizar o uso deles e garantir a eficiência das aplicações.
ROI
Desperdícios no uso de software, hardware e insumos são um grande problema para a gestão de TI. O
gerenciamento de bens e equipamentos é interessante nesse sentido, pois ajuda a atacar essa questão e
a otimizar o retorno sobre o investimento.
Ou seja, a companhia não terá mais sistemas não utilizados ou utilizados para um fim que não é o ideal.
Da mesma forma, será possível pensar melhor antes de novas compras para adquirir exatamente o que
vai trazer um impacto positivo.
Antecipação de problemas
A gestão de ativos contribui para uma visão proativa que previne instabilidades internamente.
Em vez de agir somente quando os problemas surgem, a empresa garante um controle global dos seus
bens para evitar que eles apresentem falhas nos momentos cruciais. Assim, há maior previsibilidade de
gastos e ações, bem como consistência e estabilidade produtiva.
Com uma rotina de atualizações e manutenções que considera o ciclo de vida e o uso, é possível obter
sempre os melhores resultados de um ativo. Isso representa também extrair o melhor ROI.
Fonte: Gestão de ativos de TI: entenda sua importância e como começar em sua empresa. Global Data
Solutions, 05 fev. 2021. Disponível em: https://gdsolutions.com.br/sem-categoria/gestao-de-ativos-de-ti/.
Acesso em: 27 jun. 2022.
Considerando as informações apresentadas, assinale a opção correta.
A+
A
A-
As planilhas ainda são uma das melhores maneiras de as empresas começarem a rastrear os ativos que
possuem, pois à medida que as equipes começam a adotar o gerenciamento de serviços, o gerenciamento de
ativos também se torna importante para vários departamentos.
O gerenciamento de ativos de TI (também conhecido como ITAM) é o processo que busca garantir que os ativos
tangíveis de uma empresa sejam contabilizados, pois a colaboração é uma parte importante do gerenciamento
eficaz de ativos.
Um processo de gerenciamento de ativos cria várias fontes de verdade ao otimizar orçamentos e apoiar o
gerenciamento do ciclo de vida, pois o ativo de TI inclui hardware, sistemas de software ou informações que as
organizações valorizam.
Com maior controle, visibilidade e responsabilidade atribuída, as equipes podem ampliar o consumo excessivo,
incluindo superprovisionamento e instâncias ociosas, evitando custos desnecessários, pois os ativos de TI têm um
período de uso finito.
0,6 ptsPergunta 6
Leia o texto e analise a imagem a seguir:
A UML disponibiliza, através de conceitos, objetos, símbolos e diagramas, uma forma simples, mas
objetiva e funcional, de documentação e entendimento de um sistema. Você pode utilizar os diagramas e
arquivos que compõe um modelo UML para o desenvolvimento, apresentação, treinamento e manutenção
durante todo o ciclo de vida da sua aplicação. Ela é mais completa que outras metodologias empregadas
para a modelagem de dados pois, tem em seu conjunto todos os recursos necessários para suprir as
necessidades de todas as etapas que compõe um projeto, desde a definição, implementação, criação do
modelo de banco de dados, distribuição, enfim, proporcionando sem qualquer outra ferramenta ou
metodologia adicional, um total controle do projeto.
Fonte: Introdução a UML. DevMedia. Disponível em: https://www.devmedia.com.br/introdução-a-uml/6928.
Acesso em: 27 jun. 2022.
Disponível em: https://pt.wikipedia.org/wiki/UML#/media/Ficheiro:UML_diagrams_overview_pt.svg. Acesso
em: 27 jun. 2022.
Com base nos conceitos de UML apresentados, qual das alternativas apresenta corretamente um dos tipos
de diagramas?
A+
A
A-
Java
Clientes
UML 2.0.
Desenvolvedores
Estrutura
0,6 ptsPergunta 7
Leia o texto a seguir:
O serviço de engenharia de requisitos inclui algumas atividades básicas, divididas em etapas que visam
padronizar o gerenciamento do projeto e garantir o seu sucesso. São elas:
Levantamento dos Requisitos
Esse é o momento inicial, em que são levantadas as necessidades dos usuários do software, além de
informações gerais, como as de domínio, sobre sistemas já utilizados na empresa, legislação, entre outras.
O principal objetivo é entender as demandas, processos, restrições e possibilidades dos contratantes e, a
partir desses detalhes, elencar os requisitos do sistema.
No levantamento de requisitos, quatro entendimentos básicos devem ser obtidos pela equipe de
desenvolvimento:
Entendimento do Domínio da Aplicação, ou seja, em qual área o software será utilizado;
Entendimento do Problema, no qual são levantados os detalhes referentes às demandas que o sistema irá
sanar;
Entendimento do Negócio e Atores, que apontam como o software impactará a organização e contribuirá
para que ela atinja seus objetivos;
Entendimento das Necessidades e Restrições dos Interessados, que compreende os processos e funções
que serão auxiliados pelo sistema e as demandas para a realização dos trabalhos de seus interessados.
Muitas são as técnicas para que os requisitos sejam levantados. Elas podem incluir entrevistas e
questionários entre os interessados, observação do ambiente de trabalho em que ele será aplicado,
simulações junto aos usuários finais, etc.
Análise de Requisitos
Depois que os requisitos são levantados, eles precisam ser analisados para se ter clareza sobre como eles
serão utilizados na modelagem do software.
Além de descrever todos os requisitos em uma linguagem natural, para que todos os envolvidos o
compreendam, também é comum a criação de representações gráficas.
Essas representações servem para melhor demonstrar os processos da organização, os problemas que
precisam ser resolvidos e, com base nisso, os melhores meios para o desenvolvimento do sistema.
Podemos afirmar que a análise de requisitos consiste em uma modelagem conceitual do software, em que
meios de análise são desenvolvidos para se obter uma melhor compreensão e especificação do sistema
que será criado.
Essa é uma etapa com menos foco em questões técnicas. Seu centro são questões baseadas em
perspectivas conceituais e comportamentais.
Enquanto a primeira diz respeito aos conceitos e relações de domínio importantes para o desenvolvimento
do software, a segunda visa estabelecer como será o comportamento dele e o contexto de suas
funcionalidades.
Fonte: Serviço de engenharia de requisitos: entenda como funciona. Monitora, 28 ago. 2020. Disponível
em: https://www.monitoratec.com.br/blog/servico-de-engenharia-de-requisitos/. Acesso em: 28 jun. 2022.
Refletindo sobre a engenharia de requisitos e algumas de suas etapas, avalie as seguintes asserções e a
relação proposta entre elas.
A+
A
A-
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições falsas.
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
I. Um dos objetivos da engenharia de requisitos é avaliar se o sistema é útil para o negócio, o chamado
estudo de viabilidade, pois na prática, a engenharia de requisitos é um processo sequencial e também um
processo iterativo no qual as atividades são intercaladas.
PORQUE
II. Os requisitos do sistema significam uma descrição mais detalhada dos serviços do sistema e das
restrições operacionais, pois a engenharia de requisitos é um processo de fragmentação e definição de
quais serviços devem ser fornecidos pelo sistema.
A respeito dessas asserções, assinale a opção correta:
0,6 ptsPergunta 8
Leia o texto a seguir:
As empresas que estão optando por aproveitar os benefícios do DevOps estão experimentando ganhos
relacionados à eficiência operacional, à fluidez na comunicação entre as equipes, à redução de custos da
TI e à maior satisfação dos clientes internos e externos.
Conheça as melhorias trazidas pela cooperação entre desenvolvimento de software e operação:
Integração entre áreas
Não é repetitivo abordar essa questão. Mesmo porque o DevOps não só une times de áreas específicas da
TI como também promove uma ruptura nas barreiras existentes com o negócio, com os gestores de
processos e com os “donos” de produtos e de serviços.
Assim, além de promover uma atuação sinérgica entre quem desenvolve e quem coloca uma solução na
rua, o DevOps permite uma maior comunicação com o demandante de funcionalidades para otimizar os
negócios, já que a visão passa a ser fim a fim e o propósito de entregar real valor ao cliente prepondera.
Simplificação de processos
Esse modo de trabalho prega algumas premissas que permitem tornar fluxos de trabalho menos onerosos
e burocráticos.
Uma delas é o reuso de módulos de software, a flexibilidade nos projetos para que se adaptem às
mudanças e a redução de esforços de entrega.
Automação de tarefas
Na cultura DevOps, os deploys manuais e outras atribuições dos times de TI passam a ser substituídos por
rotinas automatizadas.
Com isso, equipes antes alocadas nas etapas para subir novas funcionalidades ou softwares inteiros
passam a se dedicar ao aprendizado, à documentação, ao entendimento dos erros recorrentes e à
proposição de melhoria contínua.
Racionalização de processos
Se há simplificação e automação, não há como não ocorrer uma revisão dos processos da TI de modo a
torná-los mais racionais, eficientes e econômicos. Um exemplo clássico é a redução do tempo dos ciclos
de entregas, dotando os pequenos pacotes de desenvolvimento de um valor antes não reconhecido.
A+
A
A-
Com uma cultura DevOps ocorre a centralização de informações, o que simplifica muito o gerenciamento de
incidentes. O DevOps surgiu do sucesso do Agile em melhorar a velocidade de desenvolvimento e da percepção
de que desconecta as equipes de desenvolvimento e operações.
O DevOps alcançou o status de mainstream, todos os adotantes são convertidos completos em DevOps. O
DevOps continua a evoluir, à medida que a inteligência artificial surge para ajudar em tudo, desde a criação de
código até o gerenciamento de incidentes.
A cultura DevOps resolve problemas de comunicação e é prioridade entre especializações de TI. Em vez de
etapas fechadas, o DevOps conta com processos de desenvolvimento contínuo, integração contínua, entrega
contínua e monitoramento contínuo.
Em um fluxo de trabalho exclusivo para DevOps, as equipes de desenvolvimento e operações têm objetivos e
liderança separados. Para aprimorar suas estratégias, as organizações devem entender os contextos
relacionados ao desenvolvimento de DevOps, Agile e Waterfall.
Com uma cultura DevOps, os desenvolvedores recorrem à resposta “Funcionou na minha máquina” quando surge
um problema. O modelo DevOps alinha os esforços de desenvolvimento, controle de qualidade e operações de TI
com menos portas e fluxo de trabalho mais contínuo.
A internalização do novo modelo obriga as empresas a adequarem os seus padrões e a redirecionarem os
seus esforços para criar um terreno favorável ao pleno funcionamento do paradigma DevOps.
Modernização da TI da empresa
É intrínseca ao DevOps a tendência da cloud computing, já que plataformas, softwares e infraestruturas
oferecidos por terceiros podem ser utilizados para viabilizar os objetivos do cliente.
Assim, é possível atuar com nuvens híbridas que diminuem custos operacionais e melhoram a rotina da TI
da empresa. Elas ainda agregam ao padrão interno tecnologias de ponta sem que a empresa precise
investir em aquisição de equipamentos de última geração.Fonte: DevOps. Gaea. Disponível em: https://gaea.com.br/o-que-e-devops-conceito/. Acesso em: 21 jul.
2022.
Considerando as informações apresentadas, assinale a opção correta:
0,6 ptsPergunta 9
Leia o texto e a analise a figura a seguir:
O desenvolvimento de software é extremamente amplo. Nesse mercado, existem diversas linguagens de
programação, que seguem diferentes paradigmas. Um desses paradigmas é a Orientação a Objetos, que
atualmente é o mais difundido entre todos. Isso acontece porque se trata de um padrão que tem evoluído
muito, principalmente em questões voltadas para segurança e reaproveitamento de código, o que é muito
importante no desenvolvimento de qualquer aplicação moderna.
A Programação Orientada a Objetos (POO) diz respeito a um padrão de desenvolvimento que é seguido
por muitas linguagens, como C# e Java [...].
Na Figura 1 vemos uma comparação muito clara entre a programação estruturada e a programação
orientada a objetos no que diz respeito aos dados. Repare que, no paradigma estruturado, temos
procedimentos (ou funções) que são aplicados globalmente em nossa aplicação. No caso da orientação a
objetos, temos métodos que são aplicados aos dados de cada objeto. Essencialmente, os procedimentos e
métodos são iguais, sendo diferenciados apenas pelo seu escopo.
A+
A
A-
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
As asserções I e II são proposições verdadeiras, mas a II não é uma justificativa da I.
As asserções I e II são proposições verdadeiras, e a II é uma justificativa da I.
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
As asserções I e II são proposições falsas.
 
Figura 1. Estruturada x Orientação a Objetos
Fonte: Os 4 pilares da Programação Orientada a Objetos. DevMedia. Disponível em:
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264. Acesso em: 27 jun.
2022.
Refletindo sobre a Programação Orientada a Objetos (POO), avalie as seguintes asserções e a relação
proposta estre elas.
I. A POO é um contrato de operação bem definido que separa os dados do comportamento, e os serviços
são os blocos de construção. 
PORQUE
II. A POO usa serviços para construir sistemas, e a SOA usa objetos para construir sistemas e tende a
casar dados e comportamento. 
A respeito dessas asserções, assinale a opção correta:
0,6 ptsPergunta 10
Leia os textos a seguir e analise a imagem:
Texto I
O desenvolvimento baseado em componentes é uma variação do desenvolvimento geral de aplicativos em
que:
• O aplicativo é construído a partir de componentes executáveis distintos, que são desenvolvidos de
modo relativo e independente um do outro, possivelmente por equipes diferentes. Eles são chamados no
RUP de "componentes de montagem".
• É possível fazer upgrade do aplicativo em incrementos menores, fazendo upgrade apenas de alguns
componentes que constituem o aplicativo.
• Os componentes podem ser compartilhados entre os aplicativos, criando oportunidades para
reutilização, mas também criando dependências entre projetos.
• Apesar de não haver uma relação estrita com o fato de serem baseados em componentes, os
aplicativos baseados em componentes tendem a ser distribuídos.
Os componentes de montagem resultam do seguinte:
A+
A
A-
• Ao definir uma arquitetura muito modular, você identifica, isola, projeta, desenvolve e testa
componentes bem formados. Esses componentes podem ser testados individualmente e gradualmente
integrados para formar o sistema inteiro.
• Além disso, alguns desses componentes podem ser desenvolvidos para serem reutilizáveis,
especialmente os componentes que fornecem soluções comuns para uma ampla variedade de problemas
comuns. Esses componentes reutilizáveis, que podem ser maiores que apenas conjuntos de utilitários ou
de bibliotecas de classes, formam a base de reutilização dentro de uma organização, aumentando a
produtividade e a qualidade geral do software.
Fonte: Arquiteturas de Componentes. Disponível em: https://www.cin.ufpe.br/~gta/rup-
vc/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5 . Acesso em:
27 jun. 2022.
Texto II
Arquitetura baseada em componente/desenvolvimento baseado em componente é uma prática de RUP
porque os componentes são um meio eficaz de dividir um sistema complexo em partes gerenciáveis e
porque os componentes permitem a reutilização. A SOA (Arquitetura Orientada ao Serviço) é uma
especialização da arquitetura baseada em componente com base no uso dos serviços publicados e que
podem ser dinamicamente descobertos.
O que é SOA?
Um Serviço é um componente lógico que define um conjunto de interfaces e que não é alocado para um
usuário definido, mas para vários clientes que podem compartilhá-lo. Um Fornecedor de Serviços é um
componente que implementa as interfaces de serviço. Os serviços e os fornecedores de serviços são
publicados e acessados por um repositório chamado de Intermediário de Serviço. Esses serviços podem
ser descobertos e acessados por outros componentes (aplicativos de usuário ou outros serviços) por meio
do intermediário de serviço, seguindo os princípios mostrados na figura abaixo.
Fonte: Conceito: Introdução à Arquitetura Orientada ao Serviço. Disponível em:
http://walderson.com/IBM/RUP7/LargeProjects/modernize.legacy_evol/guidances/concepts/service-
oriented_architecture_92BDF995.html. Acesso em: 27 jun. 2022.
Considerando as informações apresentadas, avalie as afirmações abaixo:
I. Os componentes são projetados para aceitar determinadas propriedades e dados do servidor, manter
uma experiência de usuário consistente e adicionar recursos aos aplicativos criados, pois os códigos
muitas vezes resolvem mais problemas do que criam.
II. Com o desenvolvimento de aplicativos tradicionais, todas as camadas devem ser construídas umas
sobre as outras, o que cria dependências e um único ponto de falha, pois modificar componentes é
simples, eles são construídos para aceitar qualquer informação que seja colocada neles.
III. Uma arquitetura baseada em componentes significa que, em vez de perder tempo codificando uma
função que já existe, é possível extrai-los de uma biblioteca de componentes independentes, pois com
uma arquitetura baseada em componentes é comum realizar manutenção legada.
É correto apenas o que se afirma em:
A+
A
A-
Salvo em 21:53 
I.
II e III.
I e II.
I, II e III.
II
Enviar teste
A+
A
A-