Atividade:  

Criar um Protótipo da Interface do

Usuário
Finalidade

Criar um protótipo da interface do usuário.

Passos

Para cada protótipo da encenação de caso de uso a ser criado na iteração

atual, siga estes passos:

Projetar um Protótipo da Interface do Usuário

Implementar um Protótipo da Interface do Usuário
Obter Feedback sobre o Protótipo da Interface do Usuário

Esses passos estão apresentados aqui em uma ordem lógica, mas é

provável que você precise alterná-los e executá-los em paralelo.
Inicialmente, você leva mais tempo criando o protótipo. Depois, quando já
o conhece melhor, leva menos tempo para implementá-lo e obter feedback
sobre ele.
Artefatos Informados: Artefatos Resultantes:

Guia de Interface do Usuário Protótipo da Interface do

Classe de Fronteira Usuário
Especificações Suplementares
Encenação de Caso de Uso
Ator

Papel: Designer de Interface de Usuário

Detalhamentos do Fluxo de Trabalho:

Requisitos
o Refinar a Definição do Sistema

Projetar um Protótipo da Interface do Usuário

Estes são diversos aspectos envolvidos no design do protótipo da interface do usuário:

 Identificar as Janelas Principais

 Projetar a Visualização das Janelas Principais
 Projetar as Operações das Janelas Principais
 Projetar as Janelas de Propriedades
 Projetar as Operações que Envolvem Diversos Objetos
 Projetar Características Diversas
Esses aspectos serão apresentados a seguir. No entanto, um projeto não precisa
considerar todos esses aspectos no protótipo. Freqüentemente, alguns aspectos podem
ficar por conta dos implementadores e, portanto, não os inclua no protótipo. Nesse caso,
recomenda-se deixar de lado os últimos aspectos listados e concentrar-se nos primeiros.

Ao projetar o protótipo, você deve:

 implementar seu design continuamente (consulte o passo Implementar um

Protótipo da Interface do Usuário abaixo) e expô-lo a outras pessoas (consulte o
passo Obter Feedback sobre o Protótipo da Interface do Usuário abaixo);
 considerar especificações de Artefato: Guia de Interface do Usuário.

Identificar as Janelas Principais

Cada agregação de classe de fronteira oferece uma sugestão para a janela principal da
interface do usuário. Entretanto, lembre-se de que uma das metas durante a criação do
modelo de objetos é identificar as hierarquias de agregação mais superficiais. A
finalidade é, essencialmente, minimizar o número de janelas principais e, portanto, os
caminhos de navegação entre elas. Além de representarem uma carga de interação
desnecessária, os caminhos de navegação muito longos entre as janelas aumentam a
probabilidade de o usuário "se perder" no sistema. Idealmente, todas as janelas devem
ser abertas a partir de uma janela principal, o que resulta em uma navegação máxima
entre duas janelas. Tente evitar a navegação entre mais de três janelas.

A janela principal deve ser aquela que é aberta quando o usuário inicia o aplicativo.
Normalmente, ela permanece aberta durante a execução do aplicativo e é onde o usuário
passa uma considerável parte de seu "tempo". Como ela está sempre aberta e constitui o
primeiro contato do usuário com o sistema, ela é o veículo principal para impor o
modelo mental que o usuário tem do sistema.

A sugestão mais óbvia para a janela principal é definida pela classe de fronteira superior
na hierarquia de agregação. Por exemplo, a classe Documento em um editor de
documentos. Para obter detalhes, consulte Diretrizes: Classe de Fronteira. Se houver
várias hierarquias de agregação, escolha a que é mais importante para o usuário, ou seja,
onde ele passa a maior parte de seu tempo.

Quando a janela principal for identificada, considere as outras classes agregadas que
fazem parte das hierarquias de agregação e decida se elas devem ser as janelas
principais. A recomendação padrão é que elas devem ser janelas compostas, e não
janelas principais propriamente, se possível. Mais uma vez, o objetivo é minimizar o
número de janelas principais e, dessa forma, diminuir também os caminhos de
navegação entre elas. Além do mais, uma janela composta é, com freqüência, justificada
pelo fato de que seus componentes precisam aparecer juntos e manter uma relação
espacial com os componentes de outros compostos. Lembre-se de que o acesso é difícil
se forem usadas janelas (principais).

Exemplo:

A agregação Parágrafo em um editor de documentos é projetada como uma

janela composta e não como uma janela principal própria. Isso ocorre
 parcialmente porque os componentes de um Parágrafo, ou seja, os
Caracteres, devem aparecer juntos e em relação espacial com os Caracteres
de outros Parágrafos.

Como uma alternativa de design, imagine a usabilidade de um editor de

documentos em que o usuário tenha que navegar para uma janela (principal)
separada, toda vez que o conteúdo de determinado parágrafo tiver que ser
visualizado.

Entretanto, freqüentemente, as agregações não podem ser todas projetadas como janelas
compostas devido às limitações de área da tela. Se não houver espaço para projetar
todas as agregações como compostas, tente ao menos projetar as seguintes agregações
como compostas:

 As agregações centrais ao modelo mental que o usuário tem do sistema.

 As agregações com as quais o usuário gastará mais tempo.
 As agregações que permitem a iniciação dos casos de uso.

Lembre-se de que, nesse passo, a informação sobre o volume médio de objetos é

importante, pois indica quantos objetos precisam ser exibidos de uma vez. Excesso de
objetos pode sugerir que eles não podem ser projetados como objetos compostos. Em
vez disso, podem ter uma representação compacta na janela principal em que residem e
definir suas próprias janelas principais.

Projetar a Visualização das Janelas Principais

A visualização das janelas principais e de sua janela principal em particular causarão

um impacto significativo sobre a usabilidade do sistema. O design dessa visualização
envolve a determinação de quais partes (atributos) dos objetos contidos devem ser
visualizados. As descrições do fluxo de eventos e da encenação ajudam a priorizar os
atributos a serem exibidos. Se o usuário precisa ver diversos atributos diferentes dos
objetos, você pode implementar várias visualizações de uma janela principal, cada qual
com um conjunto distinto de atributos. O design dessa visualização também significa
que você tem que verificar como as partes (atributos) dos objetos contidos devem ser
visualizadas, por meio de todas as dimensões visuais. Para obter detalhes, consulte a
seção "Dimensões Visuais" em Diretrizes: Interface do Usuário (Geral).

Se uma janela principal contiver objetos de várias classes, será importante identificar os
"denominadores comuns" para essas classes, como, por exemplo, os tipos de atributo
contidos em todas as classes ou na maioria delas. Com a visualização de denominadores
comuns em alguma dimensão, o usuário pode relacionar objetos de diversas classes
entre si e verificar a existência de padrões. Dessa forma, a "largura de banda" da
interface do usuário aumenta bastante.

Exemplo:

Suponha que você tenha um sistema de atendimento ao cliente, no qual

deseja mostrar aspectos como:

 Reivindicações e questões levantadas pelos clientes ao longo do tempo.

  Produtos que o cliente adquiriu até hoje.
 Valor total de todas faturas do cliente até o momento.

Aqui, o denominador comum é "tempo". Sendo assim, a exibição de

reivindicações/questões, aquisições e faturas lado a lado no mesmo eixo temporal
horizontal permitirá ao usuário verificar os padrões de relacionamento entre esses itens
(se houver algum).

Projetar as Operações da Janelas Principais

As responsabilidades das classes de fronteira especificam as operações necessárias às

respectivas janelas. Comumente, as operações das janelas principais e os objetos que
elas contêm são oferecidos como itens em uma barra de menus e como alternativa e
complemento em menus de atalho e barras de ferramentas. Se uma janela principal
contém objetos de várias classes e se elas executam várias operações, você poderá
atribuir um menu a cada classe ou um menu a cada grupo de operações coesas.

Exemplo:

Em um editor de documentos, há um menu Editar, que agrupa operações

coesas como Recortar, Copiar e outras.

Algumas operações podem precisar de uma interação complexa com o usuário e, por
isso, justificar uma segunda janela para suas próprias atividades.

Exemplo:

Em um editor de documentos, há uma operação Imprimir em um Documento

que, devido à complexidade da interação, justifica uma janela de diálogo
separada.

Projetar as Janelas de Propriedade

As janelas de propriedades precisam ser projetadas para todas as classes de fronteira e,

dessa forma, disponibilizar todos os seus atributos para o usuário. Lembre-se de que
alguns objetos só podem ser parcialmente visualizados quando estão em uma janela
principal (consulte a seção "Projetar a Visualização das Janelas Principais" acima). Suas
janelas de propriedades, por outro lado, visualizarão todos os respectivos atributos.
Nesse passo, os valores médios dos atributos são informações importantes, pois ajudam
a escolher a visualização ideal de um atributo específico.

Algumas responsabilidades simples das classes de fronteira, como a definição do valor

de determinado atributo, são freqüentemente fornecidas como operações pela janela de
propriedades. Uma operação desse tipo não é disponibilizada na janela principal na qual
reside o objeto ou pode funcionar como alternativa ou complemento de uma operação
semelhante na janela principal.

Se fizer parte de uma associação (inclusive os objetos associados), a classe de fronteira

será visualizada na janela de propriedades.
Projetar as Operações que Envolvem Diversos Objetos

Se uma classe de fronteira definir a visualização de um grande número de objetos na

interface do usuário, o design das operações que envolvem esses objetos será delicado.
Estas são diversas variantes dessas operações:

 As operações que fornecem um mecanismo para pesquisa entre diversos objetos.

 As operações que fornecem um mecanismo para classificação de diversos
objetos.
 As operações que fornecem um mecanismo para a herança controlada pelo
usuário entre diversos objetos.
 As operações que fornecem um mecanismo para gerenciar a navegação em
hierarquias de diversos objetos.
 As operações que fornecem um mecanismo para seleção de diversos objetos.

Consulte Diretrizes: Interface do Usuário (Geral) para obter mais detalhes.

Projetar Características Diversas

Acrescente o comportamento dinâmico necessário à interface do usuário. A maioria das

dinâmicas são oferecidas pela plataforma-alvo, como o paradigma selecionar-operar, e
abertas com um clique duplo, menus pop-up do botão direito do mouse e outros. Apesar
disso, algumas decisões devem ser tomadas:

 Como suportar o gerenciamento de janelas.

 As informações que devem ser armazenadas entre as sessões, como a posição de
entrada do cursor, a posição da barra de ferramentas, as janelas abertas, o tamanho
das janelas, a posição relativa das janelas etc.
 Suportar interfaces de documento únicas ou múltiplas (SDI ou MDI) para as
janelas principais.

Avaliar também outras características comuns que melhoram a usabilidade, inclusive:

 Deve ser incluída uma "ajuda on-line", com "assistentes".

 Deve ser incluída uma operação de "desfazer" para que o sistema possa ser
explorado com segurança.
 Devem ser incluídos "agentes" para monitorar eventos do usuário e sugerir ações
ativamente.
 Deve ser incluído um "destaque dinâmico" para a visualização das associações.
 Devem ser suportadas "macros" definidas pelo usuário.
 Deve haver áreas específicas a serem configuradas pelo usuário.

Consulte Diretrizes: Interface do Usuário (Geral) para obter mais detalhes.

Implementar um Protótipo da Interface do Usuário

Esses são basicamente os três tipos de implementação de um protótipo da interface do

usuário:
 Desenhos: criados com lápis e papel.
 Bitmaps: criados com um editor de bitmap.
 Executáveis: aplicativos simulados que podem "executar" e interagir com
usuários.

Na maioria dos projetos, você deve usar todos os três tipos de implementação na ordem
listada acima. Essa ordem permite a incorporação de mudanças iniciais, pois o tempo de
implementação de cada um difere bastante (desenhos são bem mais rápidos de serem
criados e modificados do que executáveis). Entretanto, os desenhos não refletem
corretamente a área de tela limitada, eles podem conter mais detalhes do que o espaço
da tela.

Por fim, a melhor maneira de especificar a interface do usuário é através da combinação

de bitmaps e executáveis. Isso deve ser feito assim que você precisar expor o protótipo a
outras pessoas além dos designers da interface do usuário. Um bitmap pode especificar
a aparência exata das janelas principais, enquanto os executáveis podem mostrar a
aparência aproximada das janelas principais e do suporte às suas operações, assim como
a aparência e o comportamento das janelas secundárias. Naturalmente, será melhor se,
com um esforço razoável, você puder implementar a aparência exata das janelas
principais no executável do que combinar o executável e um bitmap. Se não tiver
recursos suficientes para produzir um executável, você poderá usar bitmaps como a
implementação final do protótipo. Nesse caso, pode ser útil complementá-los com
encenações de casos de uso que descrevam sua dinâmica. Caso contrário, é provável
que os implementadores da interface do usuário usem a dinâmica incorreta.

Concentre-se não em obter uma boa estrutura e modularização do código-fonte para o

protótipo do executável, mas sim na criação de um protótipo temporário que visualize
os aspectos importantes da interface do usuário e ofereça algumas de suas operações
mais significativas. De mais a mais, um protótipo está sujeito a várias mudanças quando
é projetado e exposto a outras pessoas. Essas mudanças são geralmente efetuadas como
patches de baixo custo. Como conseqüência, o valor do código-fonte do protótipo é
limitado, além de não poder "evoluir" quando a interface real do usuário é
implementada.

Em geral, é aconselhável manter a implementação de um protótipo executável mais

barata do que a implementação de uma interface real do usuário. Estas são algumas
diferenças entre o protótipo e a verdadeira interface do usuário:

 O protótipo não precisa suportar todos os casos de uso e cenários. Somente

poucos casos de uso e/ou cenários podem ser priorizados e suportados pelo
protótipo.
 As janelas principais, em geral, são a parte mais complicada de implementar. Se
você criar uma interface do usuário avançada, que realmente tire proveito do
potencial de visualização, poderá ser difícil encontrar componentes já prontos. Em
vez de implementar novos componentes, você pode usar componentes primitivos,
como botões de ação, de alternância ou de opção, para dar uma idéia aproximada da
aparência da interface do usuário para determinado conjunto de dados. Se possível,
crie vários protótipos, mostrando diversos conjuntos de dados que abranjam valores
médios e volumes de objetos.
 Simule ou ignore todas as operações realizadas em janelas de difícil
implementação.
 Simule ou ignore os elementos mais internos do sistema, como lógica de
negócios, armazenamento secundário, processos múltiplos e interação com outros
sistemas.

Obter Feedback sobre o Protótipo da Interface do Usuário