Engenharia de Software Flashcards

Question

6. (CESPE / TJ-RJ - 2021) Em um ambiente cliente/servidor, a arquitetura que permite a mesma aplicação assumir tanto o papel de cliente quanto o de servidor é conhecida como arquitetura C/S: a) simples. b) de dois níveis. c) multinível. d) de três camadas. e) par-par.

Answer 1

A arquitetura par-a-par (ou peer-to-peer) trata-se do modelo não hierárquico de rede mais simples em que máquinas se comunicam diretamente, sem passar por nenhum servidor dedicado, podendo compartilhar dados e recursos umas com as outras. Nesse tipo de rede, todas as máquinas oferecem e consomem recursos umas das outras, atuando **ora como clientes, ora como servidoras.** O gabarito definitivo foi arquitetura multinível – eu não consigo concordar com esse gabarito. Gabarito: Letra C

Answer 2

✅ **Item correto (Verdadeiro).** A afirmação descreve adequadamente **vantagens e desvantagens da arquitetura cliente/servidor**. 🔹 **Vantagens**: * **Facilidade de manutenção**: a lógica e os dados costumam estar centralizados no servidor. * **Maior segurança dos dados**: controle de acesso, backups e políticas de segurança ficam concentrados no servidor. 🔹 **Desvantagens**: * **Possíveis gargalos/bloqueios no tráfego de rede**, já que muitos clientes dependem de um servidor central. * **Problemas de atualização da interface de aplicação**, especialmente quando a interface está instalada nos clientes (ex.: aplicações desktop), exigindo atualização máquina a máquina. 📌 Portanto, o item está **correto**.

Answer 3

Perfeito! Como os servidores são centralizados, e em quantidade menor que os clientes, há mais facilidade em se administrar as atualizações deles. Em suma, em um modelo clienteservidor, uma de suas vantagens é a facilidade de manutenção dos servidores. Gabarito: Correto

Answer 4

❌ **Item incorreto (Falso).** A afirmação **confunde conceitos distintos** da área de testes de software. 🔹 A **Regra do 10 de Myers** (ou *Regra do Custo 10x*) estabelece que: * **o custo de corrigir um defeito aumenta exponencialmente** à medida que ele é descoberto mais tarde no ciclo de desenvolvimento (ex.: um erro que custa 1 para corrigir na fase de requisitos pode custar 10, 100 ou mais em produção). 🔹 Já a ideia de **planejar testes estáticos e dinâmicos o mais cedo possível** está relacionada ao **princípio de “testar cedo” (early testing)**, e **não** à Regra do 10 de Myers. 📌 Portanto, o item é **falso**, pois atribui à **Regra do 10 de Myers** um conceito que pertence a **outro princípio de teste**.

Answer 5

❌ **Item incorreto (Falso).** A descrição apresentada **não corresponde ao conceito de teste de fumaça (smoke test)**. 🔹 **Teste de fumaça (smoke test)**: * é um **teste superficial e rápido**; * verifica se as **funcionalidades básicas e críticas** do sistema funcionam após uma build; * serve para avaliar se o software está **estável o suficiente** para testes mais aprofundados. 🔹 O enunciado, porém, descreve algo mais próximo de: * **integração de componentes**, * **uso de módulos reutilizáveis**, * **organização estrutural do código**, o que **não faz parte do objetivo nem da definição de smoke test**. 📌 Portanto, o item é **falso**, pois atribui ao **teste de fumaça** características relacionadas à **integração e estruturação de código**, e não à **validação rápida de funcionalidades essenciais**.

Answer 6

✅ **Item correto (Verdadeiro).** A afirmação está **correta** e reflete conceitos fundamentais de **testes de software**. 🔹 **Defeito (fault/bug)**: erro no código ou artefato do software. 🔹 **Falha (failure)**: manifestação visível do defeito durante a execução do sistema. 🔹 Um **defeito pode existir no código sem provocar falha**: * se o trecho defeituoso **não for executado**; * se a condição que dispara a falha **não ocorrer durante o teste**; * se o erro não impactar o comportamento observado naquele cenário. 🔹 Como o **teste dinâmico** depende da **execução do software**, ele **pode não detectar** defeitos que **não se manifestam como falhas**. 📌 Portanto, o item é **verdadeiro**.

Answer 7

Perfeito! O teste estático é uma ótima maneira de identificar possíveis erros no código antes mesmo de executar o programa. Ele pode ajudar a reduzir o tempo e os custos associados ao processo de desenvolvimento de software, pois os erros podem ser detectados e corrigidos mais rapidamente. Além disso, o teste estático também pode melhorar a qualidade do software, pois permite que os erros sejam identificados e corrigidos antes que o programa seja liberado para o usuário final. Gabarito: Correto

Answer 8

Os testes de estresse são usados para verificar a capacidade de um sistema de suportar um alto volume de tráfego. Eles não são projetados para verificar o uso da memória ao longo do tempo. Na verdade, a questão trata de Testes de Resistência. Gabarito: Errado

Answer 9

❌ **Item incorreto (Falso).** O enunciado **confunde objetivos de diferentes níveis de teste**. 🔹 **Teste de integração** tem como objetivo principal: * verificar a **interação entre módulos/componentes**; * identificar **falhas nas interfaces**, comunicação e troca de dados entre partes do sistema. 🔹 O que o item descreve, na verdade, corresponde a outros tipos de teste: * **verificar se requisitos atendem à especificação** → **teste de validação / aceitação**; * **testar todo o sistema simulando ambiente real** → **teste de sistema**. 📌 Portanto, o item é **falso**, pois atribui ao **teste de integração** características que pertencem ao **teste de sistema e ao teste de aceitação**, e não à integração propriamente dita.

Answer 10

✅ **Item correto (Verdadeiro).** A afirmação descreve corretamente o **objetivo dos testes unitários**. 🔹 **Testes unitários**: * verificam **unidades individuais** do sistema (funções, métodos, classes); * são realizados de forma **isolada**, normalmente com uso de *mocks* e *stubs*; * garantem que cada parte funcione **conforme o especificado**, independentemente das demais. 📌 Portanto, o item é **verdadeiro**.

Answer 11

✅ **Item correto (Verdadeiro).** A afirmação está **correta**. 🔹 **Teste unitário** tem como foco testar **componentes individuais do programa**, como: * **métodos**, * **funções**, * **classes**, * ou pequenas unidades de código. 🔹 O objetivo é garantir que cada unidade funcione corretamente **de forma isolada**, antes da integração com outras partes do sistema. 📌 Portanto, o item é **verdadeiro**.

Answer 12

❌ **Item incorreto (Falso).** A afirmação **contraria um princípio importante dos testes orientados a objetos**. 🔹 Ao testar **classes de objeto**, é necessário: * testar as **operações (métodos)** associadas à classe **em diferentes cenários**; * **simular os eventos que causam mudanças de estado**, pois o comportamento do objeto **depende do seu estado interno**. 🔹 Limitar-se a testar apenas “amostras de operações”, **sem considerar todas as transições relevantes de estado**, pode deixar defeitos ocultos, especialmente em: * classes **stateful**, * objetos com **regras de negócio dependentes do estado**. 📌 Portanto, o item é **falso**, pois **é sim necessário considerar e simular eventos que provoquem mudanças de estado** para garantir a correção do comportamento da classe.

Answer 13

✅ **Item correto (Verdadeiro).** A afirmação está **correta** e descreve adequadamente o **princípio dos testes unitários eficazes**. 🔹 **Casos de teste unitário efetivos** devem: * verificar o **comportamento esperado** do componente quando usado corretamente; * confirmar que ele **cumpre sua finalidade** conforme a especificação; * ser capazes de **revelar defeitos**, caso existam, por meio de entradas, cenários e condições adequadas. 🔹 Bons testes unitários validam tanto: * o **fluxo normal (casos positivos)**, * quanto **situações que possam expor falhas** (casos negativos, limites, exceções). 📌 Portanto, o item é **verdadeiro**, pois reflete boas práticas consagradas de **teste unitário**.

Answer 14

❌ **Item incorreto (Falso).** Em **serviços RESTful**, os métodos **não são acionados por portas diferentes**, nem “todos os métodos” são simplesmente identificados apenas por uma mesma URL sem contexto. 🔹 **Conceito de REST / RESTful** **REST (Representational State Transfer)** é um **estilo arquitetural** para sistemas distribuídos, especialmente serviços web. Um serviço é dito **RESTful** quando segue os princípios do REST, tais como: * **Recursos identificados por URIs**; * **Uso dos métodos HTTP** (GET, POST, PUT, DELETE etc.) para definir as operações; * **Comunicação sem estado (stateless)**; * **Representações dos recursos** (JSON, XML, etc.); * **Uso de códigos de status HTTP**. 🔹 Em um serviço RESTful: * a **URL identifica o recurso**, não a operação; * a **operação é definida pelo método HTTP**, e não por portas; * normalmente utiliza-se **uma única porta padrão** (80 ou 443). 📌 Exemplo: ```text GET /clientes → obter clientes POST /clientes → criar cliente PUT /clientes/10 → atualizar cliente DELETE /clientes/10 → remover cliente ``` 📌 Portanto, a afirmação é **falsa**, pois viola os princípios do **REST**, ao associar métodos a **portas específicas**, algo que **não existe em arquiteturas RESTful**.

Answer 15

✅ **Alternativa correta: letra e) comunicação stateless.** **Justificativa:** Em uma **API RESTful**, uma das restrições fundamentais é a **comunicação stateless (sem estado)**. 🔹 **Stateless** significa que: * **cada requisição é independente**; * a solicitação deve conter **todas as informações necessárias** para que o servidor a processe; * o servidor **não armazena estado de sessão** do cliente entre requisições. 🔹 Assim, o servidor não depende de dados guardados em interações anteriores para atender uma nova requisição. Analisando as alternativas: * **a) cache** ❌ Refere-se ao armazenamento de respostas para reutilização. * **b) arquitetura cliente-servidor** ❌ Trata da separação de responsabilidades, não do estado da comunicação. * **c) interface uniforme** ❌ Diz respeito à padronização da interface (URI, métodos HTTP etc.). * **d) sistema de camadas** ❌ Relaciona-se à organização em camadas intermediárias. * **e) comunicação stateless** ✅ **Correta**, pois descreve exatamente a exigência apresentada no enunciado. 📌 **Resposta final: letra E.**

Answer 16

✅ **Alternativa correta: letra c) TRACE** **Justificativa:** O método **HTTP TRACE** é utilizado principalmente para **depuração (debugging)**. 🔹 Ele instrui o **servidor a devolver exatamente a requisição recebida**, permitindo que o cliente: * verifique **alterações feitas por proxies intermediários**; * inspecione **cabeçalhos e conteúdo** da requisição ao longo do caminho. Analisando as alternativas: * **a) OPTIONS** ❌ Usado para consultar métodos suportados pelo servidor. * **b) GET** ❌ Recupera um recurso. * **c) TRACE** ✅ **Correta** — ecoa a requisição para fins de diagnóstico. * **d) CONNECT** ❌ Cria um túnel (ex.: HTTPS via proxy). * **e) POST** ❌ Envia dados ao servidor. 📌 **Resposta final: letra C (TRACE).**

Answer 17

✅ **Item correto (Verdadeiro).** A afirmação está **correta**. 🔹 **SOAP (Simple Object Access Protocol)** é um **protocolo de comunicação** usado para a **troca de mensagens estruturadas em XML** entre um **cliente** e um **provedor de serviços**. 🔹 Características principais do SOAP: * utiliza **XML** para padronizar o formato das mensagens; * é **independente de plataforma e linguagem**; * pode operar sobre diferentes protocolos de transporte, como **HTTP**, **HTTPS**, **SMTP**, entre outros; * é amplamente usado em **Web Services tradicionais**, geralmente descritos por **WSDL**. 📌 Portanto, o item é **verdadeiro**.

Answer 18

✅ **Item correto (Verdadeiro).** A afirmação está **correta**. 🔹 **UDDI (Universal Description Discovery and Integration)** é um **padrão utilizado em SOA (Service-Oriented Architecture)** para: * **publicar**, * **descobrir**, * e **consultar** serviços disponíveis em um ambiente distribuído. 🔹 Ele funciona como um **repositório de descrições de serviços**, armazenando informações como: * dados do provedor; * serviços oferecidos; * referências técnicas (como WSDL). 📌 Portanto, o item é **verdadeiro**.

Answer 19

O WSDL é o documento que, resumidamente, descreve quais são as operações disponíveis em um serviço web com todas as particularidades de suas interfaces como métodos, parâmetros, protocolos, entre outros. Além disso, o WSDL separa a descrição de um serviço em duas perspectivas: abstratas e concretas. Gabarito: Correto

Answer 20

✅ **Item correto (Verdadeiro).** A afirmação está **correta** e está alinhada com a definição clássica de **Web Service**. 🔹 Um **Web Service** é um **sistema de software** projetado para permitir a **interação entre máquinas** por meio de uma rede. 🔹 Ele expõe uma **interface descrita em um formato processável por máquina**, o que possibilita que outros sistemas descubram e utilizem seus serviços automaticamente. 🔹 No modelo tradicional de Web Services: * essa interface é descrita por meio do **WSDL (Web Services Description Language)**; * o WSDL define **operações**, **mensagens**, **protocolos**, **bindings** e o **endpoint** do serviço. 📌 Portanto, o item é **verdadeiro**, pois descreve corretamente o conceito de Web Service e o papel do **WSDL** na sua definição.

Answer 21

❌ **Item incorreto (Falso).** A afirmação **inverte completamente os conceitos de SOAP e REST**. 🔹 **SOAP**: * é um **protocolo**; * **não se baseia no uso semântico dos métodos HTTP** (GET, POST, PUT, DELETE); * normalmente utiliza **apenas POST** (ou às vezes GET) para enviar mensagens **XML** encapsuladas no envelope SOAP; * o foco está no **conteúdo da mensagem**, não no verbo HTTP. 🔹 **REST**: * é um **estilo arquitetural**; * **utiliza corretamente os métodos HTTP**, cada um com sua semântica: * **GET** → recuperar recurso * **POST** → criar * **PUT** → atualizar * **DELETE** → remover * **não se limita a XML** (pode usar JSON, XML, etc.). 📌 Portanto, o item é **falso**, pois: * atribui ao **SOAP** uma característica típica do **REST**; * afirma incorretamente que o **REST usa apenas POST e XML**, o que é errado.

Answer 22

👉 **Item: ERRADO (FALSO).** Vamos por partes, no estilo **CESPE/Cebraspe**: * **SOAP** 👉 é, sim, um **protocolo**, fortemente baseado em **XML**. * **REST** 👉 **não é um protocolo**, e sim um **estilo arquitetural**. * Além disso, **REST não depende de XML**: ele pode usar **JSON**, XML, YAML, texto puro etc. (JSON é o mais comum hoje). 📌 O erro da afirmativa está em **dois pontos clássicos**: 1. Tratar **REST como protocolo** 2. Dizer que **XML compõe a estrutura básica de todos os web services**, o que não é verdade para REST 💡 **Como a banca gosta de confundir**: > SOAP + XML = ok > REST + XML = **nem sempre** 🔎 **Versão correta da ideia** (se fosse para virar verdadeiro): > SOAP é um protocolo baseado em XML, enquanto REST é um estilo arquitetural que pode utilizar diferentes formatos de dados, como JSON ou XML. ✔️ **Gabarito CESPE/Cebraspe**: **ERRADO** ✅

Answer 23

✅ **Alternativa correta: letra a) PUT.** **Justificativa:** No **REST**, os **verbos HTTP** indicam a ação a ser realizada sobre um **recurso** identificado por uma URI. 🔹 Uso típico dos principais verbos: * **GET** → recuperar um recurso (leitura); * **POST** → criar um novo recurso (ou submeter processamento); * **PUT** → **atualizar um recurso existente** (substituição completa); * **DELETE** → remover um recurso; * **TRACE** → diagnóstico/depuração. 🔹 O verbo **PUT** é **idempotente** e é o mais indicado quando se deseja **atualizar um recurso já existente** em uma URI conhecida. Analisando as alternativas: * **a) PUT** ✅ **Correta**. * **b) CREATED** ❌ Não é verbo HTTP (é um status HTTP: 201). * **c) GET** ❌ Apenas leitura. * **d) POST** ❌ Usado principalmente para criação. * **e) TRACE** ❌ Depuração. 📌 **Resposta final: letra A (PUT).**

Answer 24

✅ **Alternativa correta: letra e) Builder e Memento.** **Justificativa:** A questão pede **dois padrões**, respectivamente: 1. **Separar a construção de um objeto complexo da sua representação** 2. **Capturar e externalizar o estado interno de um objeto** 🔹 **Builder** * Separa o **processo de construção** de um objeto complexo da sua **representação final**; * Permite criar diferentes representações usando o **mesmo processo de construção**. 🔹 **Memento** * **Captura e externaliza o estado interno** de um objeto **sem violar o encapsulamento**; * Permite restaurar o objeto a um estado anterior (ex.: *undo/rollback*). Analisando as alternativas: * **a) Visitor e Builder** ❌ Visitor não trata de estado interno. * **b) Decorator e Interpreter** ❌ Nenhum deles atende às descrições. * **c) Proxy e State** ❌ State muda comportamento conforme estado, mas não o externaliza. * **d) Command e Adapter** ❌ Não relacionados aos conceitos pedidos. * **e) Builder e Memento** ✅ **Correta**, corresponde exatamente às definições do enunciado. 📌 **Resposta final: letra E.**

Answer 25

✅ **Alternativa correta: letra c) Builder.** **Justificativa:** O padrão de projeto que **separa a construção de um objeto complexo da sua representação**, permitindo que **o mesmo processo de construção gere diferentes representações**, é o **Builder**. 🔹 **Builder**: * isola o **processo de construção** do objeto; * permite criar **variações do mesmo objeto** usando os mesmos passos; * é ideal quando o objeto possui **muitas partes** ou **múltiplas configurações possíveis**. Analisando as alternativas: * **a) Prototype** ❌ Cria objetos por clonagem. * **b) Mediator** ❌ Centraliza a comunicação entre objetos. * **c) Builder** ✅ **Correta**. * **d) Abstract Factory** ❌ Cria famílias de objetos relacionados. * **e) Bridge** ❌ Separa abstração de implementação, não construção. 📌 **Resposta final: letra C (Builder).**

Answer 26

✅ **Alternativa correta: letra c) descrever como os objetos são colocados juntos.** **Justificativa:** Na classificação dos **padrões GoF (Gang of Four)**, os padrões são divididos em três categorias: 🔹 **Criacionais** → tratam da **criação de objetos** 🔹 **Estruturais** → tratam da **composição e organização de classes e objetos** 🔹 **Comportamentais** → tratam da **interação e distribuição de responsabilidades** 📌 **Padrões estruturais** têm como objetivo principal: * mostrar **como classes e objetos são combinados** para formar estruturas maiores; * garantir **flexibilidade e reutilização** dessas estruturas. Exemplos de padrões estruturais: **Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy**. Analisando as alternativas: * **a)** ❌ Muito genérica, não caracteriza especificamente os estruturais. * **b)** ❌ Refere-se aos padrões **criacionais**. * **c)** ✅ **Correta** — descreve exatamente a finalidade dos padrões estruturais. * **d)** ❌ Refere-se aos padrões **comportamentais**. * **e)** ❌ Também está ligada aos **comportamentais**. 📌 **Resposta final: letra C.**

Answer 27

✅ **Alternativa correta: letra a)** **Justificativa:** A questão pede a **opção correta** sobre **padrões de projeto orientados a objetos (GoF)**. Vamos analisar: --- **a) Facade** ✅ **Correta** O **Facade**: * **provê uma interface simples** para um **subsistema complexo**; * reduz o **acoplamento** entre clientes e as diversas classes internas do subsistema; * é indicado justamente quando há **muitas dependências** entre clientes e classes internas. 👉 A descrição está **perfeitamente alinhada** com o padrão **Facade**. --- **b) Decorator** ❌ Incorreta A descrição corresponde ao **Abstract Factory**, que lida com **famílias de produtos relacionados**, e não ao Decorator. --- **c) Adapter** ❌ Incorreta A descrição é do **Mediator**, que reduz interdependências complexas entre objetos. O **Adapter** serve para **converter interfaces incompatíveis**, não para resolver comunicação complexa entre muitos objetos. --- **d) Builder** ❌ Incorreta A descrição corresponde ao **State**, que trata de **mudança de comportamento conforme o estado do objeto**, e não ao Builder. --- 📌 **Resposta final: letra A.**

Answer 28

✅ **Verdadeira.** A afirmação está correta. **Padrões de projeto (design patterns)** são, justamente, **soluções reutilizáveis, já testadas e consolidadas**, para problemas recorrentes no **projeto de software**, especialmente no contexto da programação orientada a objetos. Eles **não são código pronto**, mas **modelos de solução** que ajudam a: * melhorar a qualidade do design, * facilitar manutenção e evolução, * promover boas práticas reconhecidas pela comunidade. 👉 Essa definição está totalmente alinhada com a clássica descrição dos padrões de projeto (como os do *Gang of Four*), o que torna a assertiva **correta segundo o CESPE**.

Answer 29

❌ **Falsa.** A assertiva está **incorreta**. Embora os **padrões de projeto** sejam **mais conhecidos e difundidos** no contexto da **programação orientada a objetos** (especialmente após o GoF), **eles não se limitam exclusivamente a esse paradigma**. 👉 Existem padrões aplicáveis a outros paradigmas, como: * **Arquiteturais** (MVC, Camadas, Pipe-and-Filter), * **Funcionais** (ex.: padrões de composição, imutabilidade), * **Concorrentes**, * **Distribuídos**, * **Enterprise / integração**. 📌 O que muda é **a forma de implementação**, não o conceito do padrão em si. Como o CESPE adora termos absolutos, o uso da palavra **“somente”** torna a afirmação automaticamente falsa. ✅ **Gabarito: FALSA.**

Answer 30

❌ **Falsa.** A assertiva está **incorreta** porque **confunde padrões de projeto diferentes**. Vamos por partes: 🔴 Erro principal da questão O enunciado afirma que o **Factory Method**: * evita o acoplamento entre remetente e receptor de uma solicitação; * permite que **mais de um objeto** tenha a oportunidade de tratar a solicitação; * funciona mesmo quando o conjunto de objetos é **desconhecido a priori** ou definido dinamicamente. 👉 **Essa descrição NÃO é do Factory Method.** ✅ Qual padrão corresponde à descrição? A descrição é **claramente** do padrão **Chain of Responsibility**, que: * desacopla quem faz a requisição de quem a processa; * permite que múltiplos objetos possam tratar a requisição; * decide dinamicamente quem irá atender a solicitação. 🔍 O que faz o Factory Method? O **Factory Method** é um **padrão criacional**, cujo objetivo é: * definir uma interface para criação de objetos, * delegando às subclasses a decisão de qual classe instanciar. 📌 Ele **não trata fluxo de requisições**, nem múltiplos receptores. 🧠 Conclusão (estilo CESPE) * Forte acoplamento → **Factory Method não resolve esse problema** * Descrição corresponde a **outro padrão** * Logo, a assertiva é **falsa** ✅ **Gabarito: FALSA.**

Answer 31

❌ **Falsa.** A assertiva está **incorreta** por **misturar conceitos de padrões diferentes** e por indicar **o padrão errado** para o problema descrito. Vamos destrinchar no estilo CESPE 👇 --- 🔴 Erro conceitual central O enunciado descreve um cenário em que: * o sistema é estruturado em **subsistemas**; * busca-se **facilitar o acesso** e **reduzir dependências e comunicação** entre eles. 👉 **Esse problema NÃO é resolvido por Factory Method.** --- ❌ Descrição incorreta do Factory Method A questão afirma que o **Factory Method**: > “fornece uma interface para a criação de **famílias de objetos relacionados ou dependentes** sem especificar suas classes concretas”. 🚫 **Essa definição NÃO é do Factory Method.** Essa é, na verdade, a definição clássica do **Abstract Factory**. 📌 **Factory Method**: * cria **um tipo de objeto por hierarquia**; * delega às subclasses qual classe concreta instanciar; * **não trabalha com famílias de objetos**. --- ❌ Comparação inadequada com Prototype O **Prototype**: * cria novos objetos por **clonagem**; * é útil quando a criação é custosa ou complexa; * **não é voltado à organização de subsistemas** nem ao controle de dependências entre eles. Ou seja, a comparação **Factory Method × Prototype**, nesse contexto, **não faz sentido**. --- 🧠 Qual padrão seria mais adequado? Para: * estruturar subsistemas, * reduzir dependências, * facilitar o acesso a um conjunto complexo, 👉 o padrão correto seria o **Facade**, **não citado** no enunciado. --- ✅ Conclusão (padrão CESPE) * Definição atribuída ao Factory Method está errada * Confunde Factory Method com Abstract Factory * Nenhum dos padrões citados resolve o problema descrito ✅ **Gabarito: FALSA.**

Answer 32

✅ **Alternativa correta: b)** Vamos direto ao ponto, no estilo prova da **FGV** 👇 📌 GRASP – Polimorfismo Nos padrões **GRASP (General Responsibility Assignment Software Patterns)**, o **Polimorfismo** orienta a atribuição de responsabilidades **a diferentes classes que implementam uma mesma interface**, permitindo que o sistema trate **vários tipos de forma uniforme**, sem depender de condicionais. 👉 A responsabilidade deve ser atribuída a **classes abstratas ou interfaces**, e o comportamento específico fica nas **classes concretas**. --- 🧠 Análise das alternativas **a)** ❌ Classes artificiais → isso remete a *Pure Fabrication*, não a Polimorfismo. **b)** ✅ **Correta** > “classes abstratas que representem o comportamento de classes concretas para permitir ao sistema lidar com vários tipos de maneira homogênea.” ✔ Essa é exatamente a ideia de **polimorfismo no GRASP**. **c)** ❌ Classe controladora global → isso é erro clássico (acoplamento excessivo) e não tem relação com polimorfismo. **d)** ❌ GRASP busca **baixo acoplamento**, não alto. **e)** ❌ Classes estáticas não exploram polimorfismo (não há sobrescrita dinâmica). --- 🏁 Gabarito final ✅ **b)**

Answer 33

✅ **Alternativa correta: a) controller.** Vamos direto ao conceito 👇 📌 Situação descrita na questão Pedro criou a classe **Manage Schedules Handler**, que: * é uma **classe artificial** (não representa entidade do domínio); * atua como **tratador de eventos do sistema**; * está associada a um **caso de uso específico** (*Gerenciar Horários*). 👉 Esse é exatamente o cenário do **GRASP Controller**. --- 🧠 GRASP – Controller O princípio **Controller** recomenda atribuir a responsabilidade de: * receber eventos do sistema, * coordenar a execução de um caso de uso, a uma classe: * específica do caso de uso (*use case controller*), ou * que represente o sistema como um todo. 📌 *Handlers*, *Managers* e *Controllers* artificiais são exemplos clássicos em prova. --- ❌ Análise das demais alternativas **b) creator** ❌ Trata da responsabilidade de **criar objetos**, não de tratar eventos. **c) inheritance** ❌ Não é um princípio GRASP. **d) flyweight** ❌ É um **padrão de projeto GoF**, não um GRASP. **e) template method** ❌ Outro **padrão GoF**, não relacionado à atribuição de responsabilidades. --- 🏁 Gabarito final ✅ **a) controller.** FGV adora esse padrão: sempre que aparecer **classe artificial + eventos do sistema + caso de uso**, pode marcar **Controller sem medo**.

Answer 34

✅ **Alternativa correta: e) Segregação de interface.** Vamos conferir com calma 👇 📌 Princípios GRASP Os **GRASP (General Responsibility Assignment Software Patterns)** são **9 princípios** clássicos para atribuição de responsabilidades em OO. Entre eles, estão: * **Criador (Creator)** * **Especialista de Informação (Information Expert)** * **Baixo Acoplamento (Low Coupling)** * **Alta Coesão (High Cohesion)** * **Controlador (Controller)** * **Polimorfismo** * **Fabricação Pura (Pure Fabrication)** * **Indireção (Indirection)** * **Variações Protegidas (Protected Variations)** --- 🧠 Análise das alternativas **a) Polimorfismo** ✅ → É um princípio GRASP. **b) Fabricação pura** ✅ → Também é GRASP. **c) Indireção** ✅ → Princípio GRASP clássico. **d) Variações protegidas** ✅ → Outro princípio GRASP. **e) Segregação de interface** ❌ → **Não é GRASP**. ✔ Esse princípio pertence ao conjunto **SOLID** (*Interface Segregation Principle – ISP*). --- 🏁 Gabarito final ✅ **e) Segregação de interface.** 📌 Dica de prova: * **GRASP** → atribuição de responsabilidades * **SOLID** → qualidade do design e princípios de arquitetura Quando misturam os dois na lista, a FGV/FUNDATEC quase sempre quer te pegar 😉

Answer 35

✅ **Alternativa correta: a) especialista na informação (information expert).** Vamos ligar diretamente o enunciado ao conceito 👇 --- 📌 O que a questão pergunta? No contexto de um **sistema escolar**, deseja-se: 1. **Saber qual princípio orienta a escolha da classe adequada** para receber a responsabilidade de calcular a média do aluno; 2. **Identificar a classe que possui a informação necessária** para determinar essa média. 👉 Ambos os questionamentos apontam para o **mesmo princípio GRASP**. --- 🧠 GRASP – Information Expert O princípio **Especialista da Informação (Information Expert)** afirma: > Atribua uma responsabilidade à classe que **possui a maior quantidade de informações necessárias** para cumprir essa responsabilidade. 📌 No exemplo: * Quem tem notas, avaliações, pesos, resultados? * A própria classe relacionada ao **Aluno**, **Boletim**, ou **Histórico**, e não uma classe externa. --- ❌ Por que as outras estão erradas? **b) Baixo acoplamento** ❌ → Trata da redução de dependências, não da escolha baseada em dados. **c) Alta coesão** ❌ → Refere-se à organização interna das responsabilidades. **d) Controlador** ❌ → Atua no recebimento de eventos do sistema. **e) Criador** ❌ → Define quem deve criar objetos. --- 🏁 Gabarito final ✅ **a) especialista na informação (information expert).** 📌 Regra de ouro em prova: Se a pergunta for **“quem deve fazer?”** baseada em **quem tem os dados**, a resposta quase sempre é **Information Expert**.

Answer 36

✅ **Alternativa correta: a) Indireção.** Vamos direto ao conceito cobrado 👇 --- 📌 Problema descrito no enunciado A questão pergunta: * Como **evitar o acoplamento direto** entre objetos? * Como **desacoplar** objetos para manter **baixo acoplamento** e **alto potencial de reúso**? 👉 Essa descrição bate **literalmente** com um princípio GRASP específico. --- 🧠 GRASP – Indireção (Indirection) O princípio **Indireção** recomenda: > Atribuir a responsabilidade a um **objeto intermediário**, de forma que dois (ou mais) objetos **não se comuniquem diretamente**. 📌 Benefícios: * Reduz o acoplamento; * Facilita mudanças; * Aumenta o reúso; * Isola dependências. Exemplos clássicos: * Camadas, * Interfaces, * Serviços intermediários, * Adaptadores. --- ❌ Análise das alternativas **b) Invenção Pura** ❌ → Cria classes artificiais para melhorar coesão/acoplamento, mas não foca diretamente na **mediação entre dois objetos**. **c) Especialista na Informação** ❌ → Relacionado a quem possui os dados. **d) Variações Protegidas** ❌ → Protege pontos de variação contra mudanças, conceito próximo, mas **não é o foco do enunciado**. **e) Acoplamento** ❌ → “Acoplamento” não é o nome de um padrão GRASP (o correto seria *Baixo Acoplamento*). --- 🏁 Gabarito final ✅ **a) Indireção.** 📌 Dica de prova: Sempre que aparecer **“objeto intermediário”, “evitar dependência direta”, “desacoplar”**, pense imediatamente em **GRASP – Indireção**.

Engenharia de Software Flashcards

(60 cards)