Diretrizes: Encenação de Caso de Uso
Encenação de Caso de Uso |
Uma encenação de caso de uso é uma descrição lógica e conceitual de como um caso de uso é fornecido pela interface do usuário, incluindo a interação necessária entre os atores e o sistema.
|
Mais Informações: Conceitos: Design Centrado no Usuário
Tópicos
Explicação 
As encenações de caso de uso são utilizadas para ajudar a compreender e raciocinar sobre os requisitos da interface do usuário, incluindo os requisitos de usabilidade. Elas representam uma compreensão de alto nível da interface do usuário e são muito mais rápidas de desenvolver do que a interface real do usuário. Desse modo, as encenações de caso de uso podem ser utilizadas para ajudar a criar e raciocinar sobre várias versões da interface do usuário antes que seu protótipo seja criado e ela seja projetada e implementada.
Uma encenação de caso de uso é descrita assim como as classes de fronteira e seus relacionamentos estáticos e dinâmicos (como, por exemplo, agregações, associações e vínculos). Cada classe de fronteira é, por sua vez, uma representação de alto nível de uma janela ou construção similar da interface do usuário. Veja a seguir as vantagens dessa abordagem:
- Ela oferece uma visão de alto nível dos relacionamentos estáticos entre janelas, como hierarquias de confinamento de janelas e outras associações entre objetos na interface do usuário.
- Ela oferece uma visão de alto nível dos relacionamentos dinâmicos entre janelas, como caminhos de navegação de janelas e outros caminhos de navegação entre objetos na interface do usuário.
- Ela oferece uma forma de capturar os requisitos de cada janela ou construção similar na interface do usuário, descrevendo uma classe de fronteira correspondente. Isso acontece porque cada classe de fronteira define responsabilidades, atributos, relacionamentos, etc. que apresentam um mapeamento direto para a construção correspondente na interface do usuário.
- Ela fornece rastreamento para um caso de uso específico, proporcionando assim uma integração contínua com uma abordagem orientada a caso de uso para engenharia de software. Conseqüentemente, a interface do usuário será orientada pelos casos de uso que o sistema é solicitado a fornecer e pelos papéis dos atores (usuários) - e suas expectativas - nesses casos de uso.
Uma encenação de caso de uso do modelo de análise é rastreada (um-para-um) para um caso no modelo de casos de uso.
Descrição do Fluxo de Eventos - Encenação
Veja a seguir diretrizes sobre como descrever um fluxo de eventos - encenação:
- Comece esclarecendo o próprio caso de uso, e não a interface do usuário. Faça a descrição sem considerar a interface do usuário, especialmente se o caso de uso ainda não foi explorado. Isso ajudará a captar a essência do caso de uso, assim como acontece nos "casos de uso essenciais" descritos em Conceitos: Design Centrado no Usuário. Mais tarde, quando o caso de uso for compreendido, o fluxo de eventos - encenação poderá ser ampliado, passando a incluir a interface do usuário e os aspectos de usabilidade.
- Mantenha as sentenças de ação curtas. A descrição não precisa ser necessariamente objetiva, pois ela só precisará ser compreensível para os designers da interface do usuário. As sentenças de ação que consistem em passos breves proporcionam uma visão geral melhor, pois encurtam as descrições de caso de uso. Por exemplo, quando você descreve a troca de dados entre o caso de uso e um ator, deve manter essa descrição curta mas abrangente. Você pode listar os dados trocados no final da linha, colocando-os entre parênteses: "criar pessoa (nome, endereço, telefone)."
- Evite seqüências e modos. Em geral, os atores humanos podem executar as ações do caso de uso em diferentes seqüências, principalmente em sistemas intensivos de interface de usuário onde o usuário assume o controle. As seqüências costumam implicar em modos da interface do usuário. Você deve evitar os modos, se possível. Sendo assim, especifique somente as seqüências obrigatórias no caso de uso. Por exemplo, especifique que o usuário deve identificar-se para que possa retirar dinheiro de um caixa automático ou que o sistema deve mostrar as faturas ao usuário para que ele possa aceitá-las ou recusá-las.
- Mantenha a consistência no caso de uso. Como a encenação de caso de uso pode ser descrita quase que paralelamente ao caso de uso correspondente, esses dois artefatos devem estar consistentes e dar feedback um ao outro. Mantenha principalmente a consistência do fluxo de eventos - encenação de um caso de uso em relação ao fluxo de eventos do caso de uso correspondente. Observe que isso geralmente requer uma comunicação extensiva e um loop de feedback entre o autor de caso de uso responsável pelo caso de uso e o designer da interface do usuário responsável pela encenação de caso de uso.
Exemplo:
Este é um exemplo do fluxo inicial de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, antes que ele seja ampliado com os aspectos de usabilidade.
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe.
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto.
d) Ler o texto de uma mensagem eletrônica.
e) Salvar uma mensagem eletrônica como um arquivo.
f) Salvar um anexo de mensagem eletrônica como um arquivo.
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas.
Observe que esse fluxo inicial de eventos - encenação é semelhante a uma descrição passo a passo do caso de uso correspondente, conforme descrito em Atividade: Localizar Atores e Casos de Uso. Por isso, use a descrição passo a passo do caso de uso correspondente como base ao criar a descrição do fluxo inicial de eventos - encenação.
Essa descrição será então ampliada com os diversos aspectos de usabilidade, como orientação desejada, média dos valores de atributos e volumes de objetos e média do uso de ações (consulte a seguir).
Orientação Desejada
Um sistema com boa usabilidade não somente ajuda o usuário automatizando tarefas simples e repetitivas, como também dá uma orientação, normalmente oferecendo (implicitamente) informações referentes às tarefas que não podem ser automatizadas. Essa orientação pode ser fornecida, por exemplo, através de "ajuda por balão" ou ajuda contextual na tela.
Essa importante contribuição para o design da interface do usuário deve ser representada por meio da identificação da necessidade dessa orientação desejada em pontos específicos do fluxo de eventos do caso de uso.
O designer da interface do usuário deve percorrer o fluxo de eventos e considerar as seguintes questões em cada passo:
- Que orientação o usuário pode precisar?
- Que orientação o sistema pode fornecer?
- O que deve e o que não deve ser representado como orientação desejada?
No fluxo de eventos, a funcionalidade básica do sistema pode ser identificada. Na orientação desejada, você deve ser capaz de identificar a funcionalidade "opcional" que não é fundamental para que o usuário desempenhe seu trabalho, mas que poderia ser útil caso as informações de que ele necessita fossem (implicitamente) fornecidas. Desse modo, quaisquer informações que possam ajudar a localizar essa funcionalidade opcional devem ser representadas como orientação desejada. Você não deve, porém, representar a orientação desejada que somente identifique a funcionalidade que encontraríamos usando simplesmente uma boa prática de modelagem de interface do usuário. Não represente, por exemplo, que o sistema deve dar feedback do usuário em suas operações ou mostrar ao usuário as diferentes opções que ele tem à sua disposição.
A orientação desejada também pode ser usada para informar o que não deve ser mostrado, permitindo que a interface do usuário seja modelada para que o usuário não fique sobrecarregado com informações irrelevantes.
Ela não é considerada como "requisitos", a exemplo do fluxo de eventos. Pode-se dizer que ela se assemelha mais a "desejos" ou "caprichos". Ao identificar e descrever a orientação desejada, você não deve pensar no que o sistema pode oferecer, mas sim no que o usuário pode precisar além disso. Caso contrário, você estará restringindo nosso pensamento. Portanto, lembre-se de que a orientação desejada não é absolutamente necessária. Ela é simplesmente um meio de aumentar a usabilidade.
Exemplo:
Este é um exemplo do fluxo de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, ampliado com a orientação desejada (o texto que aparece entre colchetes []).
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe. [O usuário deve ser capaz de fazer a distinção entre mensagens novas, lidas e não lidas. Além disso, o emissor, o assunto e a prioridade de cada mensagem devem estar visíveis para o usuário.]
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto.
d) Ler o texto de uma mensagem eletrônica.
e) Salvar uma mensagem eletrônica como um arquivo.
f) Salvar um anexo de mensagem eletrônica como um arquivo. [O usuário deve poder ver os tipos de arquivo dos anexos.]
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas.
Geralmente, a orientação desejada é necessária em ações nas quais o usuário precisa tomar uma decisão. Os pontos a seguir quase sempre se aplicam a essas decisões:
- Elas não são triviais para o usuário.
- Elas impactam a vida de pessoas ou negócios referentes ao sistema (pessoas ou negócios que afetam o sistema usualmente significam negócios, usuários e tarefas que o usuário está tentando executar).
- Elas fazem a diferença depois que o caso de uso é encerrado.
Exemplo:
No fluxo de eventos - encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas (passo f), salvar um anexo é uma decisão óbvia tomada pelo usuário. Essa decisão, portanto, requer uma certa orientação.
Média dos Valores de Atributos e Volumes de Objetos
Geralmente, é importante capturar a média dos valores de atributos e volumes de objetos que precisam ser gerenciados ou apresentados pelo usuário. A interface do usuário pode ser otimizada para calcular essa média de valores e volumes.
Exemplo:
Este é um exemplo do fluxo de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, ampliado com a média dos valores de atributos e volumes (o texto que aparece entre chaves { }).
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe. {Uma média de 100 mensagens eletrônicas não lidas são mostradas simultaneamente. Em 90% dos casos, a linha de assunto de uma mensagem tem menos de 40 caracteres.}
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto.
d) Ler o texto de uma mensagem eletrônica. {O texto da mensagem contém uma média de 100 caracteres.}
e) Salvar uma mensagem eletrônica como um arquivo.
f) Salvar um anexo de mensagem eletrônica como um arquivo.{Em 95% dos casos, há menos que dois anexos.}
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas.
Média do Uso de Ações
A média do uso de ações é capturada para localizar ações bastante utilizadas em oposição a ações raramente utilizadas. Conseqüentemente, encontraremos tanto seqüências (fluxos) comuns como incomuns no decorrer do caso de uso. Essas são informações importantes que podem ser usadas para priorizar e destacar as partes da interface do usuário mais utilizadas e suas hierarquias de navegação (por exemplo, fornecendo atalhos ou barras de ferramentas adicionais na interface para executar ações comuns).
Exemplo:
Este é um exemplo do fluxo de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, ampliado com a média do uso de ações (o texto que aparece entre parênteses ()).
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe.
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto. (Isso acontece em mais de 60% dos casos.)
d) Ler o texto de uma mensagem eletrônica. (Isso acontece em mais de 75% dos casos.)
e) Salvar uma mensagem eletrônica como um arquivo. (Isso acontece em menos de 5% dos casos.)
f) Salvar um anexo de mensagem eletrônica como um arquivo.
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas.
A conclusão desta descrição é a seguinte: os passos c) e d) precisam de um suporte completo da interface do usuário.
Sumário: Fluxo de Eventos - Encenação
Exemplo:
Este é um exemplo do fluxo final de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, ampliado com os diversos aspectos de usabilidade.
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe. [O usuário deve ser capaz de fazer a distinção entre mensagens novas, lidas e não lidas. Além disso, o emissor, o assunto e a prioridade de cada mensagem devem estar visíveis para o usuário.] {Uma média de 100 mensagens eletrônicas não lidas são mostradas simultaneamente. Em 90% dos casos, a linha de assunto de uma mensagem tem menos de 40 caracteres.}
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto. (Isso acontece em mais de 60% dos casos.)
d) Ler o texto de uma mensagem eletrônica. {O texto da mensagem contém uma média de 100 caracteres.} (Isso acontece em mais de 75% dos casos.)
e) Salvar uma mensagem eletrônica como um arquivo. (Isso acontece em menos de 5% dos casos.)
f) Salvar um anexo de mensagem eletrônica como um arquivo. [O usuário deve poder ver os tipos de arquivo dos anexos.] {Em 95% dos casos, há menos que dois anexos.}
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas.
Desse modo, a idéia básica do fluxo de eventos - encenação é ampliar a descrição do fluxo de eventos com os diversos aspectos de usabilidade. Essas informações serão utilizadas posteriormente para projetar uma interface de usuário com usabilidade. Observe também que os aspectos de usabilidade mostrados no exemplo acima podem ser modificados ou ampliados com outros aspectos, dependendo das necessidades do tipo de aplicação ou da tecnologia de interface de usuário em uso.
Criação dos Diagramas de Classes de Fronteira
Uma encenação de caso de uso é realizada pelas classes de fronteira e por seus objetos de interação. Para ilustrar as classes de fronteira que participam da encenação de caso de uso, juntamente com seus relacionamentos, criamos os diagramas de classes e os incluímos como parte da encenação de caso de uso.
Exemplo:
Este é um diagrama de classes da encenação correspondente ao caso de uso Gerenciar Entrada de Mensagens Eletrônicas:
Diagrama de classes incluindo o ator Usuário de E-mail e as classes de fronteira Caixa de Correio, Mensagem Eletrônica e Anexo, que participam de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas. Ele pode ser entendido a partir do seguinte contexto: um Usuário de E-mail interage com todos os objetos contidos na hierarquia de agregação abaixo de Caixa de Correio.
Para obter mais informações sobre as classes de fronteira e seus relacionamentos, consulte Diretrizes: Classe de Fronteira (Modelagem da Interface do Usuário).
Criação dos Diagramas de Interação do Objeto de Fronteira
Para ilustrar os objetos de fronteira que participam da encenação de caso de uso e suas interações com o usuário, usamos diagramas de colaboração ou de seqüência. Isso é útil para casos de uso que apresentam seqüências ou fluxos de eventos complexos.
Exemplo:
Este é um diagrama de colaboração da encenação correspondente ao caso de uso Gerenciar Entrada de Mensagens Eletrônicas.
Diagrama de colaboração incluindo o ator Usuário de E-mail e os objetos de fronteira de Caixa de Correio, Mensagem Eletrônica e Anexo, que participam de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas.
Complementação dos Diagramas de uma Encenação de Caso de Uso
Se necessário, os diagramas de uma encenação de caso de uso podem ser esclarecidos posteriormente através do fluxo de eventos - encenação como uma descrição textual complementar. Isso pode ser feito através da ampliação do fluxo de eventos - encenação com as classes de fronteira envolvidas.
Exemplo:
Este é um exemplo do fluxo de eventos - encenação de uma encenação do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, ampliado com as classes de fronteira (o texto que aparece entre "").
a) O caso de uso inicia quando o usuário de e-mail solicita o gerenciamento das mensagens eletrônicas e o sistema as exibe. [O usuário deve ser capaz de fazer a distinção entre mensagens novas, lidas e não lidas. Além disso, o emissor, o assunto e a prioridade de cada mensagem devem estar visíveis para o usuário.] {Uma média de 100 mensagens não lidas são mostradas simultaneamente. Em 90% dos casos, a linha de assunto de uma mensagem tem menos de 40 caracteres.} "Caixa de Correio"
b) O usuário de e-mail poderá então seguir um ou mais destes passos:
c) Organizar as mensagens eletrônicas de acordo com o emissor ou o assunto. (Isso acontece em mais de 60% dos casos.) "Caixa de Correio"
d) Ler o texto de uma mensagem eletrônica. {O texto da mensagem contém uma média de 100 caracteres.} (Isso acontece em mais de 75% dos casos.) "Mensagem Eletrônica"
e) Salvar uma mensagem eletrônica como um arquivo. (Isso acontece em menos de 5% dos casos.) "Mensagem Eletrônica"
f) Salvar um anexo de mensagem eletrônica como um arquivo. [O usuário deve poder ver os tipos de arquivo dos anexos.] {Em 95% dos casos, há menos que dois anexos.} "Mensagem Eletrônica" "Anexo"
g) O caso de uso termina quando o usuário de e-mail solicita o encerramento do gerenciamento da entrada de mensagens eletrônicas. "Caixa de Correio"
Captura dos Requisitos de Usabilidade na Encenação de Caso de Uso
Os requisitos de usabilidade podem definir o nível máximo de usabilidade da interface do usuário. Esses requisitos podem ser encontrados, por exemplo, em Artefato: Especificações Suplementares. Isso significa que os requisitos de usabilidade não devem ser definidos para o nível que você acredita ser o máximo oferecido pelo sistema, mas para o menor nível de usabilidade que ele deve atingir para que possa ser utilizado.
Na maioria das vezes, esse nível depende das alternativas de uso do sistema. É razoável exigir que o sistema tenha significativamente mais usabilidade que as alternativas. As alternativas podem servir para utilizar:
- Procedimentos manuais existentes.
- Sistemas legados.
- Produtos concorrentes.
- Versões anteriores do sistema.
Os requisitos de usabilidade também podem estar baseados na necessidade de justificar economicamente o novo sistema: se o cliente tiver de pagar R$ 3 milhões pelo novo sistema, pode ser que ele prefira impor requisitos de usabilidade que talvez o levem a economizar R$ 1 milhão por ano devido à menor carga de trabalho de seus recursos humanos.
Os requisitos de usabilidade de uma encenação de caso de uso geralmente especificam:
- Tempo máximo de execução - quanto tempo deve levar para que um usuário treinado execute um cenário comum do caso de uso.
- Taxa máxima de erro - quantos erros um usuário treinado produzirá em média para um cenário comum do caso de uso.
Os únicos erros relevantes a serem medidos são aqueles irrecuperáveis e que terão efeitos negativos na organização, como perder o negócio ou causar danos ao hardware monitorado. Se a única conseqüência de um erro for a demora para corrigi-lo, isso afetará o tempo de execução medido.
O tempo de aprendizagem deve ser medido como o tempo decorrido até que o usuário possa executar um cenário mais rápido que o tempo máximo de execução especificado.
Observe que os requisitos de usabilidade não devem funcionar como um alvo, ou seja, como um limite superior. Eles devem definir o nível de usabilidade absoluto mais baixo aceitável para o sistema. Desse modo, você não precisa parar de fazer melhorias na usabilidade quando os requisitos de usabilidade forem cumpridos.
Exemplo:
Este é um exemplo dos requisitos de usabilidade do caso de uso Gerenciar Entrada de Mensagens Eletrônicas, conforme capturado na encenação de caso de uso correspondente.
-
O Usuário de E-mail deve ser capaz de organizar as Mensagens Eletrônicas simplesmente clicando o mouse.
-
O Usuário de E-mail deve ser capaz de percorrer os textos da Mensagem Eletrônica simplesmente pressionando as teclas.
-
O Usuário de E-mail não deve se deixar distrair pela entrada de Mensagens Eletrônicas enquanto estiver lendo as Mensagens Eletrônicas existentes.
Referência ao Protótipo da Interface do Usuário na Encenação de Caso de Uso
Para esclarecer mais a encenação de caso de uso, é possível fazer referência às partes do protótipo da interface do usuário (janelas, por exemplo) correspondentes às suas classes de fronteira participantes. Isso pode ser útil se as partes desse protótipo já existirem quando a encenação for descrita.
Uso
As encenações de caso de uso são basicamente utilizadas nos estágios iniciais de desenvolvimento, antes que o protótipo da interface do usuário seja criado, como uma ferramenta de "raciocínio" para capturar os requisitos da interface do usuário.
As encenações de caso de uso geralmente são consideradas artefatos transientes e podem ficar sem manutenção depois que o projeto estiver pronto para acelerar a criação do protótipo da interface do usuário ou a implementação dessa interface. Em alguns casos, porém, pode ser importante manter as encenações de caso de uso através de uma série de iterações; por exemplo, se houver requisitos complexos na interface do usuário que demorem (por várias iterações) para serem entendidos.
As encenações de caso de uso não precisam ser descritas tendo em mente qualquer outro tipo de leitor que não os designers de caso de uso, pois elas são conceituais e de alto nível e podem parecer ambíguas para outras pessoas. Em vez disso, sua manifestação concreta (ou seja, a própria interface do usuário ou um protótipo dela) é que será abordada, revisada e testada com outros envolvidos, como os usuários finais. As encenações de caso de uso podem ser utilizadas pelo designer da interface do usuário como referência durante o teste de uso a fim de destacar corretamente as questões a serem testadas (por exemplo, seqüências de interação complexas).
Existe um comprometimento na recomendação acima: se for significativamente mais barato desenvolver encenações em vez do protótipo real da interface do usuário, talvez seja melhor que os usuários revisem as encenações diretamente antes que o protótipo seja implementado. O custo disso é que as descrições das encenações precisam ser claras e objetivas, para que possam ser entendidas pelos usuários. A criação dessas descrições pode requerer recursos de desenvolvimento consideráveis.
Quando as encenações de caso de uso são descritas na disciplina de requisitos e um protótipo da interface do usuário é criado, as classes de fronteira correspondentes são uma ótima base para as atividades de análise. Às vezes, porém, também é necessário criar encenações de caso de uso durante a análise para reforçar o design correspondente da interface do usuário e as atividades de implementação, pois:
- Alguns projetos não criam um protótipo da interface do usuário. Em vez disso, eles projetam e implementam a interface do usuário diretamente, sem nenhum protótipo como base.
- Alguns projetos criam um protótipo da interface do usuário, mas somente para poucos casos de uso. O restante dos casos de uso não tem protótipo da interface do usuário.
Copyright
(c) 1987 - 2001 Rational Software Corporation
| 
