Questões de Tecnologia da Informação - Engenharia de Software - Arquitetura em camadas
Limpar pesquisa
Questão: 11 de 116
62bee0946da699610079f5df
Banca: CESPE / Cebraspe
Órgão: Defensoria Pública do Distrito Federal
Cargo(s): Analista de Apoio à Assistência Judiciária - Informática - Desenvolvimento de sistemas
Ano: 2022
Matéria/Assunto: Tecnologia da Informação > Engenharia de Software > Arquitetura em camadas
I A arquitetura deve ser em camadas, de modo que uma camada forneça serviços à camada acima dela.
II A arquitetura deve permitir que os dados sejam alterados de forma independente de sua representação, e vice-versa.
III A arquitetura deve permitir várias maneiras de visualizar os dados e de interagir com eles.
A partir dessa situação hipotética, julgue o item subsequente, a respeito de arquitetura de software.
Questão: 12 de 116
62c31a99f50281479569a686
Banca: CESPE / Cebraspe
Órgão: FUNPRESP/EXE
Cargo(s): Analista de Previdência Complementar - Área de Atuação: Tecnologia
Ano: 2022
Matéria/Assunto: Tecnologia da Informação > Engenharia de Software > Arquitetura em camadas
Questão: 13 de 116
634028ccb6ab486c18449878
Banca: CESPE / Cebraspe
Órgão: Tribunal de Justiça do Rio de Janeiro
Cargo(s): Analista Judiciário - Analista de Sistemas
Ano: 2021
Matéria/Assunto: Tecnologia da Informação > Engenharia de Software
Na engenharia de software, pode-se dividir uma metodologia genérica em cinco macroatividades; entre elas, a que tem como objetivo criar um esboço do projeto a ser desenvolvido é
o planejamento.
a modelagem.
o emprego.
a comunicação.
a construção.
Questão: 14 de 116
637cc48db01b8b516919ab3f
Banca: CESGRANRIO
Órgão: Banco da Amazônia
Cargo(s): Técnico Científico - Tecnologia da Informação
Ano: 2021
Matéria/Assunto: Tecnologia da Informação > Engenharia de Software
Ao construir uma aplicação bancária, um projetista de software modelou a classe “Conta”. Posteriormente, percebeu que cada instância da classe “Conta” poderia ter um conjunto de responsabilidades variadas e independentes, sendo que uma requisição poderia ter que ser atendida por uma ou várias dessas responsabilidades.
Isso não permitiria usar de forma eficiente o mecanismo de subclasses para representar essas responsabilidades.
Buscando uma solução adequada para essa limitação, o projetista encontrou um padrão de projeto que permite adicionar e retirar dinamicamente responsabilidades apenas aos objetos individuais, e não à classe inteira, estendendo a funcionalidade do objeto, o que seria a solução ideal para o seu caso.
Esse padrão de projeto específico tem uma estrutura comum, em que existe uma
superclasse abstrata, por exemplo “ComponenteConta”, que também é superclasse de uma segunda classe, e essa segunda classe, também abstrata, será superclasse das várias classes concretas que representam as responsabilidades adicionais.
classe, por exemplo “InterfaceConta”, que converte a interface de uma classe em outra interface que o cliente espera, evitando incompatibilidades causadas por interfaces diferentes.
classe, por exemplo “FabricaContas”, que separa a construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
classe que define uma dependência um-para-muitos entre objetos, de forma que, quando o estado de um objeto da classe “Conta” é alterado, todos os outros objetos dependentes são notificados e podem implementar atualização automática de suas propriedades, em uma relação publicar-subscrever.
classe abstrata, por exemplo “InterfaceConta”, cuja finalidade é definir a interface que permite que suas subclasses tratem uma requisição, sendo que as subclasses concretas são estruturadas em uma cadeia onde cada classe trata a requisição ou a envia para a classe sucessora, até que uma delas atenda a requisição.
Questão: 15 de 116
637cc48eb01b8b516919ab4d
Banca: CESGRANRIO
Órgão: Banco da Amazônia
Cargo(s): Técnico Científico - Tecnologia da Informação
Ano: 2021
Matéria/Assunto: Tecnologia da Informação > Engenharia de Software
O Guia Geral MPS de Software 2020, versão de maio de 2020, declara que o Processo de Engenharia de Requisitos tem por propósito definir, gerenciar e manter atualizados os requisitos das partes interessadas e do produto, garantindo que inconsistências entre os requisitos, os planos e os produtos de trabalho sejam identificadas e tratadas.
Além disso, tal guia explicita que, no Processo de Engenharia de Requisitos, é esperado que os requisitos sejam validados a partir do nível
F
B
C
D
E