Os projetistas de software devem introduzir restrições e limitações para simplificar a implementação da interface, pois se deixar por conta dos desejos do usuário, a implementação pode ficar muito complexa.

A interface deve ser projetada para reduzir a exigência de recordações, entradas e resultados passados, pois quanto mais um usuário tiver de se lembrar, mais sujeita a erros será a interação com o sistema.

Se modelos interativos anteriores tiverem criado expectativas nos usuários, porém são de difícil implementação, redefina esses modelos de forma a tornar a implementação mais fácil.

Proporcione apenas um tipo de interação e treine os usuários para ele. Dê preferência pela interação com o uso do mouse e bloqueie outras formas de interação para simplificar o trabalho de suporte ao usuário.

As informações sobre uma tarefa, um produto ou algum comportamento que você quer que o usuário saiba devem ser apresentadas todas de uma única vez, mesmo que o usuário não demonstre interesse imediato por elas.

I, II, III e IV.

I e IV, apenas.

II e III, apenas.

I, II e III, apenas.

III e IV, apenas.

Todos os métodos em um tipo interface tem um nome, parâmetros, um tipo de retorno e uma implementação.

Um tipo interface pode ter apenas campos de instância (atributos) públicos ou protegidos.

É possível converter um tipo classe para um tipo interface, desde que a classe implemente a interface.

Apesar de permitir a reutilização de métodos mudando apenas sua implementação, as interfaces não podem reduzir o acoplamento entre classes.

Os métodos em tipo interface podem ser públicos ou protegidos.

no MVC, as classes que fazem conexão com banco de dados e executam instruções SQL são representadas no componente Model. Já no modelo three-tier, essas classes são representadas na camada de Dados (também conhecida como camada de Persistência).

o fluxo de comunicação entre os componentes View e Model do padrão MVC deve passar obrigatoriamente pelo componente Controller, pois o fluxo de comunicação é sequencial.

no modelo three-tier a camada de Apresentação deve se comunicar diretamente com a camada de Dados, sem passar pela camada de Negócios.

em uma aplicação web desenvolvida com Java EE, arquivos JSP são representados no componente Controller do MVC, pois esses arquivos são convertidos em servlet quando a aplicação é compilada e implantada.

classes que implementam as regras de negócio podem ser representadas tanto no componente Controller quanto no componente Model do MVC.

a instrução para receber no método processRequest da servlet os dados selecionados no formulário é String[3] interesses = request.getParameter("interesses");.

ao submeter os dados selecionados no formulário HTML, esses dados serão recebidos no método doGet da servlet, pois esse é o método padrão para requisições HTTP em uma aplicação web.

os pacotes javax.servlet e javax.servlet.http oferecem interfaces e classes para escrever servlets. A classe javax.servlet.http.HttpServlet fornece métodos, tais como o doGet e o doPost que foram sobrescritos na servlet Controle.java.

o código que deve ser utilizado no método processRequest da servlet para receber e exibir os dados selecionados no formulário é String[] interesses = request.getParameterValues ("interesses"); for (int i=0; i <= interesses.size(); i++) { out.println(interesses[i]); }.

os métodos doPost e doGet devem ser excluídos, pois os dados recebidos por esses métodos no objeto request são passados para o método processRequest, logo, basta o método processRequest para receber os dados das requisições.

É uma linguagem de uso livre baseada em XML que, apesar de ser utilizada para descrever serviços web, não é uma recomendação da W3C.

É uma linguagem baseada em XML para descrever web services, porém, não especififica como acessá-los.

É um protocolo baseado em XML que é utilizado para acessar um web service, permitindo a troca de informações entre aplicações na web utilizando HTTP.

Um documento WSDL especifica a localização do serviço e as operações (ou métodos) que o serviço expõe.