STJ/2015 (Analista) - Comentários da Prova de Engenharia de Software e Desenvolvimento
Questões e Provas comentadas

STJ/2015 (Analista) – Comentários da Prova de Engenharia de Software e Desenvolvimento

Fala, galera.

 

Perdão pela demora, estou enroladíssimo. Consegui somente agora fazer um comentário da prova. Em geral, achei a prova bem tranquila. Vamos ver…

 

75 – Embora os engenheiros de software geralmente utilizem uma abordagem sistemática, a abordagem criativa e menos formal pode ser eficiente em algumas circunstâncias, como, por exemplo, para o desenvolvimento de sistemas web, que requerem uma mistura de habilidades de software e de projeto.

Certo. Apesar de soar estranho, isso está no Sommerville: “No entanto, engenharia tem tudo a ver com selecionar o método mais adequado para um conjunto de circunstâncias, então uma abordagem mais criativa e menos formal pode ser eficiente em algumas circunstâncias. Desenvolvimento menos formal particularmente adequado para o desenvolvimento de sistemas Web, que requerem uma mistura de habilidades de software e de projeto”. Além disso, o que eu sempre falo na hora de avaliar uma questão: observem que ele usou um termo ‘pode’. Isso facilita a nossa vida, porque – se essa questão estiver errada – o examinador teria que ‘provar’ que não há nenhuma possibilidade de uma abordagem criativa ser eficiente.

 

76 – O foco da engenharia de software inclui especificação do sistema, desenvolvimento de hardware, elaboração do projeto de componentes de hardware e software, definição dos processos e implantação do sistema

Errado. Até trata de alguns aspectos de hardware, mas desenvolvimento de hardware, definitivamente não.

 

77 – As principais atividades de engenharia de software são especificação, desenvolvimento, validação e evolução.

Certo. Bem, essa questão poderia gerar controvérsias, porque fica-se sem saber se essa é uma lista de atividades principais taxativa ou exemplificativa. De todo modo, acho difícil o CESPE aceitar um recurso, porque – em geral – realmente são essas mesmo.

 

78 – Os requisitos reguladores, legais e éticos são externos e não funcionais.

Certo. Bastava lembrar do quadrinho da aula 10. No entanto, vamos tentar resolver por lógica? Faz sentido pensar em requisitos reguladores, legais e éticos como externos? Sim! E eles são funcionais ou não funcionais? Ora, não-funcionais. Logo, era possível matar a questão.

 

79 – Os requisitos ambientais, operacionais e de desenvolvimento são organizacionais e não funcionais.

Certo. Bastava lembrar do quadrinho da aula 10, mas também era possível resolver por lógica.

 

80 – No diagrama de caso de uso, as formas corretas de se ligar um ator a um caso de uso são por meio de associação, que demonstra a utilização, pelo ator, da função representada pelo caso de uso, e por meio da generalização, que demonstra a relação de herança entre ambos.

Errado. Vimos em aula que “(…) agora vamos falar sobre os tipos de relacionamentos em um diagrama de classes. Há três tipos de relacionamentos entre classes: Dependência, Generalização e Associação”. Esses são tipos de relacionamento do Diagrama de Classes e, não, Casos de Uso.

 

81 – No diagrama de estrutura composta, a denominação de uma ocorrência de colaboração possui a mesma notação utilizada na denominação de um objeto, e essa ocorrência representa a aplicação do padrão descrito por uma colaboração a uma situação específica que envolve classes ou instâncias que executam papéis específicos da colaboração, em que uma colaboração pode conter outras colaborações dentro de si

Certo. Vocês se lembram que o Diagrama de Estrutura Composta trata de modelar colaborações? Pois é, a notação realmente é a mesma (vejam o Diagrama de Objetos na aula). Além disso, uma colaboração pode conter outras colaborações.

 

82 – No diagrama de classe, os símbolos #, + e !, que precedem atributos e métodos para indicar nível de acessibilidade, significam, respectivamente, protegida, pública e privada.

Certo. Questão bem tranquila, bastava lembrar da tabelinha que tinha em aula 11.

 

83 – Na contagem de pontos de função, deve-se contar um dado elementar referenciado (DER), correspondente a uma função de dados, para cada atributo único ou não, repetido e reconhecido pelo usuário, mantido na função de dados ou recuperado dessa função por meio da execução de todos os processos elementares pertinentes ao escopo da contagem.

Errado. Vimos em aula que “DER é um atributo único, reconhecido pelo usuário e não repetido”.  Essa questão possui, então, dois erros: os campos devem ser obrigatoriamente únicos e eles devem ser obrigatoriamente não-repetidos.

 

84 – O modelo relacional de dados consiste em um banco de dados percebido por seus usuários como uma coleção de variáveis de relações que trata das questões lógicas e físicas da estrutura, da integridade e da manipulação de dados.

Errado. Dizer que o Modelo Ralacional consiste em um banco de dados soa estranho; além disso, ele não trata de questões físicas.

 

85 – O modelo relacional consiste em uma coleção ilimitada de tipos escalares e de um operador de atribuição relacional que atribui valores às variáveis de relações que integram os componentes desse modelo.

Certo. De acordo com Date, é possível, em termos simples, definir um modelo relacional em cinco componentes:  (1) uma coleção ilimitada de tipos escalares, incluindo, em particular, o tipo booleano ou valor verdade; (2) um gerador de tipo de relação e uma interpretação pretendida para esses tipos de relação gerados; (3) recursos para definição de variáveis de relações desses tipos de relações gerados; (4) um operador de atribuição relacional, para atribuição de valores de relações a essas variáveis de relações; e (5) uma coleção ilimitada de operadores relacionais genéricos, para derivar valores de relações de outros valores de relações.

 

86 – A manutenibilidade é atributo de qualidade externa que pode ser medida por atributos internos, como a profundidade da árvore de herança e a complexidade ciclomática.

Certo. Vimos no quadrinho da aula 10 que é um atributo de qualidade interna e externa e pode ser medida por atributos internos (ou subcaracterísticas). No entanto, não encontrei nada na ISO 9126 que fale sobre profundidade da árvore de herança e complexidade ciclomática. Inclusive, essas duas são métricas de complexidade e, não, de manutenibilidade. Logo, acho que cabe recurso.

 

87 – A funcionalidade e a usabilidade, características dos atributos de qualidade de software, possuem como subcaracterísticas, respectivamente, a operacionalidade e a interoperabilidade.

Errado. Bastava lembrar do quadrinho da aula 10 e notar que a questão inverteu as subcaracterísticas.

 

88 – A apreensibilidade cuida da capacidade de o usuário compreender se o software é apropriado e como este pode ser usado para a tarefa e as condições específicas.

Errado. Vimos no quadrinho da aula 10 que a Apreensibilidade é uma subcaracterística da Usabilidade, mas a questão descreveu a Inteligibilidade, que é outra subcaracterística da Usabilidade. A Apreensibilidade é a capacidade do produto de software de possibilitar ao usuário aprender sua aplicação.

 

89 – A arquitetura de microsserviços, abordagem em que o aplicativo é desenvolvido em uma única unidade contendo pequenos serviços, dependentes entre si, que se comunicam com um ente central denominado biblioteca de componentes, propicia o gerenciamento centralizado desses serviços para automatizar a segurança.

Errado. Vimos em aula que “A Arquitetura de Microsserviços é uma abordagem para o desenvolvimento de uma aplicação como um conjunto de pequenos serviços, cada um executando em seu próprio processo e se comunicando por meio de mecanismos leves”. Vimos em aula também que a abordagem em que há uma única unidade é a abordagem monolítica.

 

90 – A arquitetura duto e filtro para aplicações em ambientes web provê interatividade, pois prescinde do processamento de fluxo de dados

Errado. Essa questão trata de Pipes & Filters. Como o edital pede Arquitetura de Software, ele pode cobrar absolutamente qualquer uma. É a primeira vez que eu vi isso em prova, dificulta a vida do aluno, não custa nada especificar as arquiteturas. De todo modo, ela não prescinde do processamento de fluxo, ela necessita dele.

 

91 – Na arquitetura em camadas MVC (modelo-visão-controlador), o modelo encapsula o estado de aplicação, a visão solicita atualização do modelo e o controlador gerencia a lógica de negócios.

Errado. Vocês se lembram que o MVC é uma arquitetura triangular, i.e., nem toda comunicação passa pelo Controlador. O modelo encapsula o estado da aplicação? Sim, essa é tranquila! A visão solicita atualização do modelo? Sim, porque ela não atualiza diretamente o modelo, mas ela manda atualizações para o controlador e esse, sim, atualiza o modelo. O Controlador gerencia a lógica de negócios? Não, isso também é função do modelo. O controlador trata do fluxo de controle, mas não gerencia a lógica de negócio.

 

92 – SOAP é um protocolo-padrão para definição de interface do serviço, suas operações, associações requeridas e fornecidas.

Errado. Quem define isso é o WSDL (Binding, para interface; Operation, para operação; e Port, para associações). Na aula, há um quadrinho com essas características.

 

93 – A arquitetura orientada a serviços é forma de desenvolvimento de sistemas distribuídos em que os componentes de sistemas são serviços autônomos, razão por que, devido à interoperabilidade, as ligações entre os serviços devem ser rígidas para não provocar mudanças durante sua execução.

Errado. SOA é forma de desenvolvimento? Não. Os componentes são serviços autônomos? Sim. As ligações devem ser rígidas? Jamais, isso aumentaria o acoplamento entre os serviços. Nós vimos em aula que o objetivo é justamente o contrário.

 

94 – Adapter é um padrão do tipo estrutural que lida com a interface para um objeto, ao passo que builder refere-se a como um objeto composto será criado e instanciado por uma classe.

Errado. Adapter é estrutural? Sim. Lida com a interface para um objeto? Não, com a interface para uma classe. Edit: Alguns alunos comentram que ele serve também para objetos. É verdade, ele é um daqueles poucos que servem para objetos e classes. A pegadinha da questão é que o Builder se refere a como um objeto COMPLEXO e, não, COMPOSTO será criado e instanciado por uma classe. Vocês se lembram que eu falo na aula que tem que se decorar algumas palavras chaves? Essa era uma delas.

 

95 – Um dos princípios-chave do Domain-Driven Design é o uso de uma linguagem ubíqua com termos bem definidos, que integram o domínio do negócio e que são utilizados entre desenvolvedores especialistas de negócio.

Certo. Vimos em aula que “para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua”. De fato, essa é a linguagem comum do domínio do negócio e dos desenvolvedores especialistas do negócio.

 

97 – ECM é um conjunto de ferramentas, como aplicativos, linguagens de desenvolvimento e sistemas operacionais, que dão forma aos conceitos de gerência do conhecimento, por meio de estratégias, métodos e ferramentas utilizadas para capturar, gerenciar, armazenar, preservar e distribuir conteúdo e documentos relacionados aos processos organizacionais.

Certo. Vimos em aula que “é um meio de organizar e armazenar documentos e demais conteúdos relacionados aos processos de uma organização. Esse termo abrange estratégias, métodos e ferramentas usadas durante o ciclo de vida do conteúdo. (…) Ele é um guarda-chuva que abarca conceitos como Gerenciamento de Documentos (inclusive eletrônicos), Gerenciamento de Conteúdo Web, Mecanismos de Busca e Colaboração, Gerenciamento de Registros, Ativos Digitais e Fluxos de Trabalho, entre outros. (…)Galera, existem cinco componentes principais no Modelo ECM. São eles: Captura, Gestão, Preservação, Armazenamento e Difusão” – logo, a questão está correta.

 

98 – O encapsulamento, característica da programação orientada a objetos, é uma técnica utilizada para ocultar os detalhes da implementação de um objeto.

Certo. Vimos em aula que “o mecanismo de encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto”, i.e., os detalhes de implementação.

 

99 – O princípio da responsabilidade única estabelece que uma classe deva executar apenas uma tarefa; dessa forma, caso uma classe possua mais uma responsabilidade, deve-se considerar sua decomposição em duas ou mais classes.

Certo. A responsabilidade única diz que uma classe deve ter uma e apenas uma responsabilidade e realizá-la de maneira satisfatória.

 

100 – Métodos callback são formas de instanciar métodos utilizando-se tecnologia de chamada em segundo plano escondido do plano sequencial da aplicação.

Errado. De cara, o que vocês veem de estranho nessa questão? Não faz sentido falar em instanciar métodos, instanciam-se classes – métodos, não. No mais, Métodos Callback são formas de chamar métodos ou funções utilizando-se tecnologia de chamada em segundo plano escondido do plano sequencial da aplicação. Esses métodos fazem uma requisição ao servidor e ficam esperando a resposta, que não necessariamente volta imediatamente, i.e., é assíncrono. De todo modo, quando a resposta vier, aí sim ele chama a função ou faz o que tiver que fazer. A ideia é liberar a aplicação para que outras ações sejam tomadas sem que ela fique aguardando o retorno de processos síncronos (esses, sim, estão em um plano sequencial).

 

101 – O valor da variável e no fim da execução do seguinte algoritmo será 143.

Certo. Questão que avalia se você sabe como funciona uma estrutura de repetição e uma atribuição. Basta calcular na mão – o resultado será 143.

 

106 – O desenvolvimento orientado a testes é uma metodologia de desenvolvimento de casos de teste de classes de funcionamento de aplicações para dispositivos móveis com ênfase nas falhas de comunicação.

Errado. Essa questão é engraçada, a única parte correta é: “é uma metodologia de desenvolvimento” – o restante está tudo errado e maluco.

 

107 – O Git, sistema de controle de versões que mantém um histórico completo de todas as alterações, permite a recuperação das versões do projeto na busca de informações sobre o estado dos arquivos em versões anteriores.

Certo. Essa é uma função básica de qualquer sistema de controle de versão. A diferença do Git é que ele busca alterações por meio de estados.

 

108 – O framework Java Struts foi construído para padrão de projetos estruturados em camadas que separam a camada física da camada lógica do banco de dados

Errado. Ele, de fato, foi construído para padrão de projetos estruturados em camadas, mas não em camada física/lógica do banco de dados, mas em camadas MVC!

 

109 – Ao se executar o código Java apresentado a seguir, o resultado obtido será 13.

Errado. Recurso fácil, o examinador esqueceu do operador em if (valor == 0 valor == 1). Sem colocar o operador, o código daria erro de compilação, logo o resultado não seria 13 – é questão de sintaxe e, não, de lógica de programação (mesmo que fosse a intenção do examinador).

 

110 – O processo de refatoração deve sempre começar com a criação de um sólido conjunto de testes para o trecho de código a ser trabalhado.

Certo. Galera, você tem um código que funciona, mas deseja melhorar a eficiência dele. Recomenda-se que se faça uma série de testes sólidos para verificar as funcionalidades antes de refatorar o código. Dizer que SEMPRE se deve começar com testes soa estranho e cabe, sim, recurso, visto que – muitas vezes – os testes já foram feitos; mas estou com a impressão de que o CESPE não vai aceitar :(

 

112 – No contexto de clean code, as funções devem ter tamanho reduzido.

Certo. Vimos em aula que “quanto às funções:  devem ser pequenas e devem fazer apenas uma coisa (responsabilidade única); não deve ter nível de endentação maior que dois; preferencialmente, devem ter poucos parâmetros; recomenda-se não repetir código (evitar redundância)” – logo, a questão está correta.

 

113 – Considere uma página HTML cujo código seja o apresentado a seguir.

Errado. Observem que somente o h2 está inline, logo apareceria um embaixo do outro. Para chegar ao resultado apresentado na questão, nós deveríamos colocar <h2>Subtítulo</h2>. Dessa forma, Título e Subtítulo estariam inline.

 

114 – JSON (JavaScript Object Notation) é um formato de arquivo de texto para troca de dados em que um objeto é um conjunto de pares nome/valor.

Certo. Nós vimos em aula: “Trata-se de um formato para intercâmbio de dados! (…) Pessoal, há também semelhanças: ambos são formatos texto (plain text) (…)” – logo, a questão está correta.

 

115 – A tag definida a seguir é obrigatória na especificação de uma página que utilize HTML5.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 5. //PT”

 “http://www.w3.org/TR/html5/strict.dtd”>

Errado. Nós vimos em aula: “No entanto, antes de tudo isso, devemos sempre declarar logo na primeira linha de código qual tipo de documento o navegador deverá esperar, por meio da instrução: <!DOCTYPE html>. Atenção: isso não é uma tag – é uma instrução para indicar ao navegador o tipo de documento que deve renderizar e a versão da linguagem”. Logo, não se trata de uma tag – além disso, não é necessário escrever tudo isso; no HTML5, basta escrever <!DOCTYPE html> – logo, a questão está errada.

 

116 – JPQL (Java Persistence Query Language) é uma linguagem de manipulação de dados adotada para criar, alterar estrutura de tabelas e gatilhos utilizados na especificação JPA (Java Persistence API).

Errado. JPQL manipula dados, mas não manipula estruturas ou gatilhos. Ele trata de Queries: Java Persistence QUERY Language.

 

117 – O Hibernate define um objeto transient com uma instância de um objeto que tenha persistido e que esteja em transição para consulta e utilização pela aplicação.

Errado. Nós vimos em aula que “no estado transiente, a instância não esteve nem está associada a um contexto persistente, isto é, não há uma representação no banco de dados, nem um valor identificador. Ela é instanciada, utilizada, destruída e não pode ser reconstruída de forma automática” – logo, a questão está errada!

 

118 – JUnit é um framework utilizado para facilitar a geração de testes a fim de se verificar se os resultados gerados pelos métodos escritos em Java são os esperados.

Certo. Nós vimos em aula que “uma dessas ferramentas é o JUnit, que é um framework de testes para a linguagem Java! (…) Cada teste individual é implementado como um objeto e um executor de testes realiza todos os testes. Estes em si devem ser escritos de maneira que indiquem se o sistema testado se comportou conforme esperado” – logo, a questão está correta.

 

119 – O JMS (Java Message Service) permite a troca de mensagens assíncronas entre um ou mais clientes e faz parte da especificação do Java EE.

Certo. Nós vimos em aula que “realiza processamentos fracamente acoplados, em que todas as operações que envolvem a troca de mensagens são feitas de forma assíncrona, fazendo com que as aplicações participantes não precisem ficar bloqueadas esperando o término de alguma computação remotamente solicitada” – logo, a questão está correta.

 

120 – A finalidade das ferramentas de integração contínua é a criação de soluções integradas com foco em sistemas fortemente acoplados, com necessidade de criação de uma documentação contínua

Errado. Sistemas fortemente acoplados? Jamais! Necessidade de criação de uma documentação contínua? Também não! A questão nos deu duas chances de acertar.

 

É isso! Espero que tenham gostado do nosso curso. Qualquer erro ou dúvida, só mandar! ;)

Posts Relacionados

Diego Carvalho

Diego Carvalho

Formado em Ciência da Computação na Universidade de Brasília (UnB), com pós-graduação em Gestão de Tecnologia da Informação na Administração Pública e, atualmente, é Auditor Federal de Finanças e Controle - Especialidade Governança e Gestão em Tecnologia da Informação da Secretaria do Tesouro Nacional (STN).

Veja os comentários:

Deixe seu comentário:

Deixe seu comentário:

Vídeos Relacionados