Diretrizes:
|
 Classe de Fronteira |
|
As classes de fronteira são usadas para modelar a interação entre um sistema e o ambiente em que se encontra, ou seja, seus atores. Os seguintes aspectos da interação são capturados em classes de fronteira:
As classes de fronteira podem, portanto, ser usadas para capturar os requisitos em uma interface do usuário. Normalmente, fazer um modelo de objetos da interface do usuário traz várias vantagens, já que muitas dessas interfaces criadas atualmente são orientadas a objetos e a tendência é que o uso desse tipo de orientação seja cada vez maior. Embora muitas das decisões de design da interface do usuário sejam melhor tomadas durante a criação de protótipo e o rápido desenvolvimento da própria interface do usuário, é normal pensar na estrutura e nos requisitos de usabilidade da interface do usuário em termos de um modelo de objetos.
Para compreender o restante dessas diretrizes, consulte a seção "Conceitos sobre Janelas: Definição do
Contexto", em Diretrizes: Interface do Usuário (Geral).
Uma interface do usuário baseada em janelas pode ser modelada por classes de fronteira. Isso pode ser descrito em alto nível nos seguintes pontos:
A partir das janelas e objetos dos exemplos acima, identificamos as seguintes classes de fronteira, responsabilidades, atributos, relacionamentos e requisitos especiais.
As classes de fronteira a seguir podem ser identificadas para um editor de documentos:
Observe que Caractere está incluído somente porque é essencial para exibir um caractere como um objeto próprio neste aplicativo específico, ou seja, no editor de documentos. É claro que as classes Caractere não devem ser usadas se não forem consideradas essenciais no aplicativo que esteja sendo modelado. Nesses casos, é provável que Caractere possua uma granularidade muito fina.
As classes de fronteira a seguir podem ser identificadas para um aplicativo de correio:
As classes de fronteira a seguir podem ser identificadas para manipulação de arquivos:
As responsabilidades a seguir podem ser identificadas para um editor de documentos:
A responsabilidade Dividir serve para dividir um Documento em duas (sub)janelas. A responsabilidade Localizar(Texto) serve para localizar algum Texto no Documento.
As responsabilidades a seguir podem ser identificadas para um aplicativo de correio:
A responsabilidade Organizar(Critérios) serve para organizar as Mensagens Eletrônicas de uma Caixa de Correio de acordo com vários critérios, como remetente, assunto, hora de recebimento, etc.
As responsabilidades a seguir podem ser identificadas para manipulação de arquivos:
Os atributos a seguir podem ser identificados para um editor de documentos:
Observe que este tipos de atributo são exibidos aqui conceitualmente e podem ser realizados na interface real do usuário em várias unidades de medida, como centímetros, polegadas, etc.
Os atributos a seguir podem ser identificados para um aplicativo de correio:
Os relacionamentos de agregação a seguir podem ser identificados para um editor de documentos:
Observe que a janela principal, neste caso o Documento, costuma ser um agregado, já que contém um número arbitrário de outros objetos. No entanto, agregados (como o Parágrafo) também existem dentro de outros agregados e não representam necessariamente janelas principais.
Os relacionamentos de agregação a seguir podem ser identificados para um aplicativo de correio.
Com relação aos arquivos, o relacionamento entre Pasta e Arquivo também poderia ser modelado como um agregado:
Os relacionamentos de associação a seguir podem ser identificados para um editor de documentos:
Uma Nota de Rodapé deve estar sempre ancorada a um Caractere. Por outro lado, um Caractere pode se associar a uma ou várias Notas de Rodapé.
Observe a diferença entre agregações e associações (comuns). Geralmente, as agregações são usadas para modelar hierarquias de confinamento, enquanto as associações modelam relacionamentos e caminhos de navegação alternativos entre diferentes hierarquias de confinamento.
Um uso das associações ligeiramente mais avançado é a modelagem de herança controlada por usuário. Por isso, uma associação deve ficar entre o objeto herdado e o objeto herdante. Um exemplo é quando um Parágrafo herda um Estilo:
O relacionamento de generalização a seguir pode ser identificado para um editor de documentos:
Um Documento também é um Arquivo, ou seja, ele herda todas as responsabilidades e atributos deste.
Os relacionamentos de generalização podem ser identificados para um aplicativo de correio:
Os requisitos especiais em classes de fronteira podem ser:
Um requisito de usabilidade relacionado à classe Caractere poderia ser:
Um Caractere deve permitir a navegação para qualquer Nota de Rodapé associada com um único movimento do mouse.
Um requisito de usabilidade relacionado à classe Mensagem Eletrônica poderia ser:
O Usuário de E-mail não deve se deixar distrair pelas Mensagens Eletrônicas de entrada enquanto estiver lendo as Mensagens Eletrônicas existentes.
Um requisito de usabilidade relacionado à classe Caixa de Correio poderia ser:
O Usuário de E-mail deve ser capaz de organizar as Mensagens Eletrônicas simplesmente clicando o mouse.
Outros requisitos de usabilidade têm a ver com valores de atributo e volumes de objeto. Isso ocorre porque a interface do usuário geralmente possui um requisito para fornecer uma interface legível relacionada a um intervalo específico de um valor de atributo ou para fornecer um gerenciamento usável do intervalo de um volume específico de objetos. Portanto, tais intervalos devem representar os casos normais e cobrir até 90% deles. Por sua vez, a interface do usuário vai cobrir todos os valores, incluindo aqueles que excederem os intervalos, mas pode ser otimizada para valores nos intervalos normais.
Um requisito de usabilidade relacionado a volumes de objetos contidos na classe Documento poderia ser:
Um Documento deve ser capaz de gerenciar 1.000 Parágrafos sem atrasar o mecanismo de rolagem.
Um requisito de usabilidade relacionado a valores de atributo da classe Mensagem Eletrônica poderia ser:
Um Sujeito deve ser capaz de incluir 40 caracteres, sem hifens.
Como as classes de fronteira modelam interações entre os atores e o sistema, esclarecemos isso ao associar cada ator às classes de fronteira que gerenciam a interação com o ator.
Para o editor de documentos, identificamos um ator Escritor que interage com Documentos.
Um Escritor pode trabalhar com vários Documentos diferentes. Um Documento pode ser criado por vários Escritores diferentes. Observe que, provavelmente, isso fará com que um Documento precise ser capaz de distinguir Escritores diferentes.
Além disso, nesse caso, deixamos que se depreenda do contexto o fato de que um Escritor interage com todos os objetos contidos na hierarquia de agregação em Documento.
Para o aplicativo de correio, identificamos um ator Usuário de E-mail que interage com Caixas de Correio.
Também nesse caso, deixamos que se depreenda do contexto o fato de que um Usuário de E-mail interage com todos os objetos contidos na hierarquia de agregação em Caixa de Correio.
Um problema com muitas interfaces do usuário é que elas possuem janelas demais e caminhos de navegação de janelas demasiado longos. Além de adicionar uma carga desnecessária de interações, esses caminhos de navegação aumentam a probabilidade de o usuário se "perder" no sistema. O ideal é que todas as janelas sejam abertas a partir de uma única janela primária, geralmente chamada de janela principal. Portanto, o comprimento máximo de navegação deve ser de dois. Evite comprimentos de navegação maiores que três.
Uma meta importante durante a criação da interface do usuário é ter somente uma janela principal por ator, se possível com todos os objetos que ele precise acessar. Se isso não for possível, a janela deve fornecer navegação para todos os objetos que o ator precise acessar. É importante que o ator passe uma parte considerável de seu "tempo de uso" interagindo com essa janela principal.
Conseqüentemente, esse fato tem o seguinte impacto no modelo de objetos da interface do usuário:
Os critérios de satisfação apresentados acima estão em um nível bem detalhado. Em um nível mais alto, podemos listar os seguintes critérios, que podem não fornecer tantos detalhes mas que pelo menos demonstram a intenção das classes de fronteira:
|
Rational Unified Process
|
