Provas

O JSON foi baseado em um subconjunto da sintaxe de objetos do JavaScript. Hoje é um formato textual independente de linguagem, com bibliotecas em praticamente todas elas, e é muito usado para troca de dados.

REST é um estilo arquitetural com restrições: cliente-servidor, stateless, cache, interface uniforme (identificação de recursos, HATEOAS), sistema em camadas. Usar GET, POST, PUT e DELETE é insuficiente por si só para ser RESTful.

Uma API define uma interface de comunicação independente da linguagem, e é comum expô-la por HTTP com JSON ou XML. Ela permite integrar sistemas escritos em linguagens diferentes. O "exclusivamente" torna o item falso.

Os padrões buscam interoperabilidade entre plataformas diferentes. O UDDI é um registro para publicar e descobrir serviços, não para definir as mensagens. A descrição formal do serviço, com operações e mensagens, é função do WSDL. Por isso o item está errado.

No XHTML, a declaração é recomendada, mas não obrigatória. Sua ausência é aceita quando a codificação é UTF-8 ou UTF-16, e ela pode até causar o modo quirks em navegadores antigos. Quando usada, vem antes do DOCTYPE, mas a obrigatoriedade afirmada no item é falsa.

O HTML5 introduziu elementos semânticos como

SGBDs como SQL Server, Oracle, PostgreSQL e DB2 têm tipo de dado XML nativo. Eles permitem consultar esses dados com XPath e XQuery (por exemplo, XMLQUERY e xpath()), conforme o SQL/XML.

O eMAG exige alternativas para conteúdo multimídia. Isso inclui legendas ou transcrição textual do áudio para pessoas surdas ou com deficiência auditiva. A descrição textual apenas da imagem não supre a falta de alternativa para o áudio, então há desconformidade.

O eMAG (Modelo de Acessibilidade em Governo Eletrônico) padroniza a acessibilidade dos sítios e portais do governo federal brasileiro, para todas as pessoas, incluindo as com deficiência. Ele é compatível com as recomendações internacionais, em especial as WCAG do W3C.

O teste de release verifica se o sistema está pronto para uso externo e atende aos requisitos. Ele não se limita às novas funcionalidades, porque é preciso garantir que as já existentes continuem funcionando, o que exige reexecução de testes (regressão).

O modelo em cascata tem fases discretas (requisitos, projeto, implementação, testes, manutenção), planejadas por completo no início. Cada fase só começa depois que a anterior é concluída e aprovada, formalmente, por meio de documentos. O fluxo é considerado unidirecional.

Em POO, o objeto reúne dados e comportamentos e expõe apenas uma interface. Os detalhes internos ficam ocultos, de modo que a implementação pode mudar sem impactar quem usa o objeto, desde que a interface seja mantida.

No desenvolvimento incremental, as mudanças constantes tendem a corromper a estrutura do sistema. Sem refatoração sistemática, o código e a arquitetura se degradam e perdem coerência. Por isso a refatoração é recomendada ao longo dos incrementos.

O modelo em cascata é mais adequado quando os requisitos são bem compreendidos e estáveis, como em sistemas críticos e embarcados. Isso não o torna exclusivo desses casos. Ele também é usado em grandes projetos de engenharia de sistemas e em outros contextos de requisitos estáveis. O termo "exclusivamente" torna o item errado.