ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DA...

INPE-9621-TDI/844

ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DAINTERFACE HUMANO-COMPUTADOR DE SISTEMAS

BASEADOS NA ARQUITETURA SOFTBOARD

Eunice Gomes de Siqueira

Dissertação de Mestrado em computação Aplicada, orientada pelo Dr. João BoscoSchumann Cunha, aprovada em 01 de outubro de 2001.

INPESão José dos Campos

2003

681.3.02

SIQUEIRA, E. G. Estratégias e padrões para a modelagem da interface humano-computador de sistemas baseados na arquitetura softboard / E. G. Siqueira. – São José dos Campos: INPE, 2001. 171p. – (INPE-9621-TDI/844).

1.Interface humano-computador. 2.Engenharia de software. 3.Reutilização de software. 4.Estratégia. 5.Pa- drões. 6.Programação orientada a objetos. 7. Softboard. I.Título

Para minha mãe, Maria.

AGRADECIMENTOS

Agradeço a Deus.

Ao professor Dr. João Bosco pela orientação.

À Faculdade de Administração e Informática e ao Instituto Nacional de Pesquisas

Espaciais pela oportunidade de estudo.

À minha família e ao Afonso pela motivação e ajuda.

E a todos que, direta ou indiretamente, contribuíram para a realização deste trabalho.

RESUMO

O uso de computadores pela sociedade cresce continuamente. Contudo, para que esse

uso seja eficaz e eficiente, há de se considerar a interface humano-computador dos

sistemas computacionais. A interface influencia na satisfação e na eficiência dos

usuários, nos custos de treinamento, suporte técnico e operação, e em alguns casos, na

própria segurança das pessoas. Visando a melhoria da qualidade dos sistemas de

software, e mais especificamente, na interface humano-computador, neste trabalho é

apresentado um conjunto de estratégias e padrões para a modelagem da interface

humano-computador dos sistemas baseados na arquitetura SOFTBOARD. Buscando a

melhoria da produtividade das equipes de desenvolvimento, também se define um

modelo dos metadados necessários para o Componente Interface Humano-Computador

dessa arquitetura, para que o mesmo possa ser configurado a fim de atender a diferentes

aplicações.

STRATEGIES AND PATTERNS FOR SOFTBOARD-BASED SYSTEMS

HUMAN-COMPUTER INTERFACE MODELLING

ABSTRACT

The use of the computers by society is growing. However, for this use to be efficient

and effective, it is necessary to consider the computer system’s human-computer

interface. The interface influences the user’s satisfaction and productivity, the training,

then technical suport and the operation costs, and in some cases, even people’s safety.

Aiming at better software systems’ quality, more especifically for human-computer

interface, this research is presented as a set of strategies and patterns for

SOFTBOARD-based systems’ human-computer interface modelling. In order for

developers to achieve better productivity, this research also defines a metadata model

which is necessary to the Human-Computer Interface Component of SOFTBOARD.

This allows it to be configured for use in different applications.

SUMÁRIO

Pág.

LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS

CAPÍTULO 1 - INTRODUÇÃO................................................................................. 23

1.1 - Estrutura da Dissertação......................................................................................... 25

CAPÍTULO 2 - FUNDAMENTAÇÃO....................................................................... 27

2.1 - Interface e Interação ............................................................................................... 27

2.1.1 - Estilo de Interação............................................................................................... 28

2.1.1.1 - Linguagem de Comando .................................................................................. 28

2.1.1.2 - Linguagem Natural........................................................................................... 29

2.1.1.3 - Menu ................................................................................................................ 29

2.1.1.4 - Preenchimento de Formulário .......................................................................... 30

2.1.1.5 - Manipulação Direta .......................................................................................... 31

2.1.1.6 - Fatores Favoráveis e Desfavoráveis de cada Estilo ......................................... 31

2.1.2 - Interface Gráfica de Usuário ............................................................................... 33

2.1.2.1 - Sistema de Janelamento ................................................................................... 33

2.1.2.2 - Dispositivo Virtual ........................................................................................... 34

2.2 - Usabilidade............................................................................................................. 36

2.2.1 - Especificação de Usabilidade.............................................................................. 38

2.2.2 - Avaliação de Usabilidade.................................................................................... 40

2.2.2.1 - Ensaio de Interação .......................................................................................... 40

2.2.2.2 - Modelo de Usabilidade..................................................................................... 43

2.3 - Uma Abordagem de Desenvolvimento de Software para a Melhoria da Qualidade e

da Produtividade .................................................................................................... 51

2.3.1 - O Processo de Desenvolvimento......................................................................... 52

2.3.1.1 - Processo de Desenvolvimento Unificado......................................................... 55

2.3.2 - A Arquitetura Configurável de Sistemas de Software Orientado a Objetos ....... 59

2.3.3 - Estratégia e Padrão.............................................................................................. 62

2.3.3.1 - Modelo para a Apresentação das Estratégias e Padrões................................... 63

CAPÍTULO 3 - ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DA

INTERFACE HUMANO-COMPUTADOR DE SISTEMAS DE

SOFTWARE BASEADOS EM SOFTBOARD.............................. 65

3.1 - Abordagem Inicial.................................................................................................. 65

3.2 - Modelagem do Sistema de Software...................................................................... 65

3.2.1 - Modelagem de Negócio ...................................................................................... 68

3.2.1.1 - Contexto do Modelo de Negócio ..................................................................... 68

3.2.2 - Modelagem Conceitual ....................................................................................... 69

3.2.2.1 - Contexto do Modelo Ambiental....................................................................... 70

3.2.2.2 - Estratégias para Modelagem da IH .................................................................. 74

3.2.2.3 - Contexto do Modelo Comportamental............................................................. 81

3.2.3 - Modelagem Operacional ..................................................................................... 84

3.2.3.1 - Contexto do Modelo de Implementação .......................................................... 84

3.2.3.2 - Estratégias para a Modelagem da IH................................................................ 84

3.2.3.3 - Contexto do Modelo de Implantação ............................................................. 110

3.2.4 - Modelagem Física ............................................................................................. 111

3.3 - Alocação das Estratégias da IH no Processo de Desenvolvimento Unificado..... 111

CAPÍTULO 4 - MODELO DOS METADADOS DO CIH E ESTRATÉGIAS

PARA A ALIMENTAÇÃO NO BDEC......................................... 113

4.1 - Abordagem Inicial................................................................................................ 113

4.2 - Modelo dos Metadados do CIH ........................................................................... 114

4.2.1 - Os Requisitos para o CIH.................................................................................. 114

4.2.2 - Modelo Conceitual ............................................................................................ 115

4.2.2.1 - Modelo Ambiental ......................................................................................... 115

4.2.2.2 - Modelo Comportamental................................................................................ 115

4.2.3 - Modelo Operacional.......................................................................................... 119

4.2.3.1 - Modelo de Implementação ............................................................................. 119

4.3 - Estratégias para a Alimentação do BDEC............................................................ 121

4.3.1 - Revisão das Estratégias para a Alimentação do BDEC com os Metadados do

CDP ................................................................................................................... 121

4.3.2 - Extensão das Estratégias para a Alimentação do BDEC com os Metadados do

CDP ................................................................................................................... 125

4.3.3 - Estratégias para a Alimentação do BDEC com os Metadados do CIH............. 126

4.4 - A Prototipação do CIH......................................................................................... 138

4.4.1 - Resultados da Prototipação ............................................................................... 139

CAPÍTULO 5 - CONCLUSÃO ................................................................................. 141

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................... 143

APÊNDICE A - BIBLIOGRAFIA COMPLEMENTAR........................................ 147

APÊNDICE B - PROTÓTIPO .................................................................................. 149

APÊNDICE C - DIAGRAMAS DA UML................................................................ 159

APÊNDICE D - DIAGRAMAS DO SISTEMA SIMPLIFICADO DE

BIBLIOTECA ................................................................................. 165

APÊNDICE E - NOTAÇÃO CASE*METHOD...................................................... 169

APÊNDICE F - DIFERENÇAS ENTRE COMBINAÇÕES DE CORES............. 171

LISTA DE FIGURAS

Pág.

2.1 - Interação usuário-sistema....................................................................................... 28 2.2 - Estilo de interação por linguagem de comando. .................................................... 29 2.3 - Estilo de interação por menus. ............................................................................... 30 2.4 - Estilo de interação por preenchimento de formulário. ........................................... 31 2.5 - Dispositivos virtuais de uma interface gráfica. ...................................................... 35 2.6 - Questão com escala numérica. ............................................................................... 41 2.7 - Questão com escala de preferência. ....................................................................... 42 2.8 - Níveis de abstração durante o desenvolvimento. ................................................... 54 2.9- Estimativa de esforços nas fases do Processo de Desenvolvimento Unificado57 2.10 - SOFTBOARD. ..................................................................................................... 61 3.1 - Estratégias para a modelagem da interface humano-computador.......................... 66 3.2 - Construção do Modelo de Negócio........................................................................ 68 3.3 - Construção do Modelo Conceitual......................................................................... 69 3.4 - Diagrama de casos de uso para o Sistema Simplificado de Biblioteca.................. 71 3.5 - Exemplo de questões aplicadas para o conhecimento do usuário.......................... 77 3.6 - Exemplo de interação. ............................................................................................ 78 3.7 - Diagrama de classes para um Sistema Simplificado de Biblioteca........................ 81 3.8 - Diagrama de colaboração para um Sistema Simplificado de Biblioteca. .............. 82 3.9 - Notas com o conteúdo de uma classe de fronteira. ................................................ 83 3.10 - Construção do Modelo Operacional..................................................................... 84 3.11 - Exemplo para a seqüencialização de itens de menu............................................ 92 3.12 - Exemplo de relatórios. ......................................................................................... 95 3.13 - Exemplo de alinhamento e agrupamento. ............................................................ 95 3.14 - Fontes : (a) com serifa (b) sem serifa................................................................. 96 3.15 - Cenário da interface. .......................................................................................... 100 3.16 - Parte estrutural da colaboração. ......................................................................... 101 3.17 - Diagrama de seqüência....................................................................................... 102 3.18 - Diagrama de gráfico de estado. .......................................................................... 102 3.19 - Diagrama de implantação para um sistema baseado em SOFTBOARD. .......... 110 3.20 - Construção do Modelo Físico. ........................................................................... 111 3.21 - Alocação das estratégias nas fases e fluxos do Processo Unificado. ................. 112 4.3 - Metáforas da interface.......................................................................................... 134 B.1 - Mapa de menus com os metadados do CDP. ...................................................... 150 B.2 - Mapa de menus com os metadados do CIH. ....................................................... 151 B.3 - Alimentação dos metadados Modelo OO e Componente_SB............................. 151 B.4 - Alimentação dos metadados Classe, Atributo e Operação. ................................. 152 B.5 - Alimentação dos metadados Colaboração e Objeto. ........................................... 152 B.6 - Alimentação dos metadados Metafora_IH. ......................................................... 153 B.7 - Alimentação dos metadados Propriedade da Metáfora. ...................................... 153 B.8 - Alimentação dos metadados Evento_Capturado. ................................................ 154 B.9 - Alimentação dos metadados Atribuição e Evento Gerado. ................................. 154 B.10 - Geração do Catálogo. ........................................................................................ 155

B.11 - Escolha da aplicação e identificação do usuário. .............................................. 156 B.12 - Consulta ao acervo. ........................................................................................... 156 B.13 - Recurso Mover elemento................................................................................... 157 B.14 - Movimentação do elemento............................................................................... 157 B.15 - Recurso Redimensionar elemento. .................................................................... 158 B.16 - Redimensionamento do elemento...................................................................... 158 C.1 - Notação para o diagrama de casos de uso. .......................................................... 159 C.2 - Notação para o diagrama de classes. ................................................................... 160 C.3 - Notação para o diagrama de colaboração. ........................................................... 161 C.4 - Notação para o diagrama de seqüência................................................................ 162 C.5 - Notação para o diagrama de gráfico de estado. ................................................... 163 C.6 - Notação para o diagrama de componente............................................................ 163 C.7 - Notação para o diagrama de implantação............................................................ 164 C.8 - Notação da colaboração....................................................................................... 164 D.1 - Diagrama de casos de uso. .................................................................................. 165 D.2 - Diagrama de classes. ........................................................................................... 165 D.3 - Realização do caso de uso Consultar acervo....................................................... 166 D.4 - Diagrama de seqüência para a colaboração........................................................ 166 D.5 - Diagrama de gráfico de estado para a colaboração. ............................................ 167 E.1 - Notação simplificada do diagrama Case*Method. .............................................. 169

LISTA DE TABELAS

Pág.

2.1 - FATORES FAVORÁVEIS E DESFAVORÁVEIS DE CINCO ESTILOS DE

INTERAÇÃO......................................................................................................... 32

2.2 - INSTRUÇÕES PARA DEFINIÇÃO DA CLASSE E CRIAÇÃO DE DOIS

DISPOSITIVOS VIRTUAIS ................................................................................. 35

2.3 - EXEMPLO DE UMA TABELA DE ESPECIFICAÇÃO DE USABILIDADE ... 38

2.4 - OPERADORES KLM............................................................................................ 44

2.5 - OPERADORES NGOMSL.................................................................................... 48

3.1 - ESTRATÉGIAS PROPOSTAS ............................................................................. 67

3.2 - FREQÜÊNCIA DE EXECUÇÃO DOS CASOS DE USO POR ATOR .............. 73

3.3 - ESPECIFICAÇÃO DE USABILIDADE............................................................... 80

3.4 - SUPLEMENTO DO DIAGRAMA DE GRÁFICO DE ESTADOS ................... 103

3.5 - DOCUMENTAÇÃO DA INTERFACE .............................................................. 103

3.6 - ALOCAÇÃO DAS ESTRATÉGIAS NAS FASES E FLUXOS DO PROCESSO

UNIFICADO........................................................................................................ 112

4.1 - ESTRATÉGIAS REVISADAS ........................................................................... 121

4.2 - RELAÇÃO RELMODELO_OO ......................................................................... 122

4.3 - RELAÇÃO RELCOMPONENTE_SB ................................................................ 122

4.4 - RELAÇÃO RELCLASSE ................................................................................... 123

4.5 - RELAÇÃO RELATRIBUTO .............................................................................. 123

4.6 - RELAÇÃO RELOPERAÇÃO............................................................................. 123

4.7 - RELAÇÃO RELOPER-ATRIB........................................................................... 124

4.8 - RELAÇÃO RELCONEXÃO............................................................................... 124

4.9 - RELAÇÃO RELASS_REGULAR ...................................................................... 124

4.10 - RELAÇÃO RELAGREGAÇÃO ....................................................................... 124

4.11 - RELAÇÃO RELCLASSE-CONEXÃO............................................................. 125

4.12 - RELAÇÃO RELGEN_ESP ............................................................................... 125

4.13 - RELAÇÃO RELCLASSE-GEN_ESP ............................................................... 125

4.14 - RELAÇÃO RELCASODEUSO ........................................................................ 126

4.15 - ESTRATÉGIAS PROPOSTAS ......................................................................... 126

4.16 - RELAÇÃO RELCOMPONENTE_SB .............................................................. 127

4.17 - RELAÇÃO RELTIPO_METAFORA_IH ......................................................... 128

4.18 - RELAÇÃO RELELEMENTO........................................................................... 128

4.19 - RELAÇÃO RELPROPRIEDADE_TM............................................................. 128

4.20 - RELAÇÃO RELPROPRIEDADE_TM_WN .................................................... 129

4.21 - RELAÇÃO RELCOMPOSIÇÃO ...................................................................... 129

4.22 - RELAÇÃO RELSUBSTITUIÇÃO.................................................................... 130

4.23 - RELAÇÃO RELEVENTO ................................................................................ 130

4.24 - RELAÇÃO RELEVENTO_WN........................................................................ 130

4.25 - RELAÇÃO RELEVENTO_WN........................................................................ 130

4.26 - RELAÇÃO RELCLASSE_USUÁRIO.............................................................. 131

4.27 - RELAÇÃO RELRECURSO_IH........................................................................ 131

4.28 - RELAÇÃO RELCLASSE_RECURSO_IH....................................................... 131

4.29 - RELAÇÃO RELGRUPO_FUNCIONAL.......................................................... 132

4.30 - RELAÇÃO RELUSUÁRIO............................................................................... 132

4.31 - RELAÇÃO RELCOLABORAÇÃO.................................................................. 133

4.32 - RELAÇÃO RELOBJETO.................................................................................. 133

4.33 - RELAÇÃO RELMETAFORA_IH .................................................................... 134

4.34 - RELAÇÃO RELMETAF_PROP_IH................................................................. 134

4.35 - RELAÇÃO RELGRUPO_FUNCIONAL.......................................................... 135

4.36 - RELAÇÃO RELGRUPO_FUN_METAFORA_IH........................................... 135

4.37 - RELAÇÃO RELEVENTO_CAPTURADO...................................................... 136

4.38 - RELAÇÃO RELGRUPO_AÇÃO...................................................................... 136

4.39 - RELAÇÃO RELEVENTO_CAPTURADO...................................................... 136

4.40 - RELAÇÃO RELATRIBUIÇÃO........................................................................ 137

4.41 - RELAÇÃO RELEVENTO_GERADO.............................................................. 138

4.42 - RELAÇÃO RELCOMPLEMENTO_WN ......................................................... 138

F.1 - DIFERENÇAS NOS VALORES DE CINZA EM UMA PALETA VGA PARA

WINDOWS.......................................................................................................... 171

LISTA DE SIGLAS E ABREVIATURAS

ACM SIGHI - Association for Computing Machinery Special Interest Group in

Human-Computer Interaction

BDEC - Banco de Dados de Elementos Controlados

CDP - Componente Domínio do Problema

CIH - Componente Interface Humano-Computador

CGC - Componente Gerenciador de Cenários

CGD - Componente Gerenciador de Dados

CIS - Componente Interação Entre Sistemas

CMOOS - Componente Gerenciador de Configuração de Sistema Orientado

a Objetos

GOMS - Goals, Operators, Methods and Selection Rules (Metas,

Operadores, Métodos e Regras de Seleção)

IGU - Interface Gráfica de Usuário

IHC - Interação Humano-Computador

KLM - Keystroke-Level Model

LABIUTIL - Laboratório de Utilizabilidade

NGOMSL - Natural GOMS Language

OWL - Object Window Library

SOFTBOARD - Arquitetura Configurável de Sistema de Software Orientado a

Objetos

SEI - Software Engineering Institute

UML - Unified Modeling Language (Linguagem de Modelagem

Unificada)

VCL - Visual Component Library

VGA - Video Graphics Array

WIMP - Windows, Icons, Menus and Pointers (Janelas, Ícones, Menus e

Ponteiros)

23

CAPÍTULO 1

INTRODUÇÃO

Quando os computadores surgiram, os usuários eram, em sua maior parte, técnicos

especializados em programação. Muitos estavam à vontade para investir grande

quantidade de tempo para descobrir o que era necessário para usá-los, assim como a

passar qualquer tipo de inconveniente, para conseguir módicos tempos de máquina para

executar seus programas.

Embora os técnicos ainda formam um grande segmento dos usuários de computadores,

hoje em dia, a maioria dos usuários são pessoas que possuem as mais diversas

habilidades, características e experiências e que usam os computadores como um meio

para inumeráveis fins: trabalho, educação, entretenimento, comunicação, entre outros.

Segundo Preece et al. (1994), o principal fator que permitiu o tão amplo acesso aos

computadores, foi a redução dos preços de hardware. Esses, comparados hoje com o

trabalho humano (isto é, o tempo das pessoas), são inexpressivos.

O custo de hardware e software de um sistema computacional é pago apenas uma vez,

mas o custo de seu uso é pago todos os dias (Hix e Hartson, 1993; Paula, 2001). Isto se

manifesta na grande necessidade de treinamentos, com o consumo de tempo na

operação inadequada, ou ainda, na correção de erros, freqüentemente, cometidos pelos

usuários. Quanto mais difícil de aprender, mais oneroso é o treinamento e quanto mais

difícil de usar, menor é o desempenho dos usuários pela existência de erros e lentidão de

operação. Esta situação pode ser agravada pela frustração dos usuários e da própria

organização que fez a aquisição do sistema.

Neste ponto, observa-se a necessidade da qualidade de interação entre o usuário e o

sistema computacional e no que viabiliza essa reciprocidade, a interface humano-

computador. A qualidade se apresenta quando se maximiza os efeitos desejáveis da

interação e minimiza seus efeitos desagradáveis. Isto se consegue com aplicação de uma

modelagem sistemática para a interface e na eliminação de julgamentos pessoais.

A abordagem de desenvolvimento de sistemas de software para a melhoria da qualidade

e da produtividade, estabelecida por Cunha (1997), propõe a utilização de uma

24

arquitetura voltada para a reutilização e define a SOFTBOARD – Arquitetura

Configurável de Sistemas de Software Orientado a Objetos.

Essa arquitetura está calcada no paradigma orientado a objetos e no Modelo

Multicomponentes de Coad e Yourdon (1993), onde cada componente possui uma

responsabilidade específica provida por um conjunto de classes reutilizáveis. Entretanto,

Cunha introduziu um conceito particular de reutilização de classes, na forma em que

sugere que cada componente da SOFTBOARD deva ser configurado. São eles:

• Componente Domínio do Problema (CDP).

• Componente Interface Humano-Computador (CIH).

• Componente Gerenciador de Dados (CGD).

• Componente Interação entre Sistemas (CIS).

• Componente Gerenciador de Cenários (CGC).

• Componente Gerenciador de Configuração de Sistema Orientado a Objetos

(CMOOS).

A SOFTBOARD pode ser vista como uma placa de software, numa alusão à

“motherboard”, onde o CDP se comporta como um “chip” que pode ser trocado,

havendo a necessidade apenas de se alterar as informações (metadados) sobre os

componentes, localizadas em um Catálogo e mantidas pelo CMOOS.

O Catálogo é um subconjunto do Banco de Dados de Elementos Controlados (BDEC)

que contém descrições de elementos produzidos no desenvolvimento de sistemas de

software, tais como classes, diagramas e documentos.

Na busca pela melhoria da qualidade dos sistemas de software e na produtividade das

equipes de desenvolvimento, observa-se também a importância dos conceitos de

estratégias e padrões. Estes conceitos expressam exemplos de boas práticas, aqueles

que podem ser usados pelos desenvolvedores para resolverem problemas comuns,

encontrados no desenvolvimento de sistemas de software.

25

Dentro da abordagem de desenvolvimento de sistemas de software proposta em Cunha

(1997), encontra-se os objetivos desta dissertação: contribuir para a concretização da

Arquitetura Configurável de Sistemas de Software Orientados a Objetos –

SOFTBOARD, no tocante à interface humano-computador:

a) estabelecendo um conjunto de estratégias e padrões para modelagem da

interface humano-computador dos sistemas a serem desenvolvidos baseados

na arquitetura SOFTBOARD;

b) estabelecendo um modelo para os metadados do CIH e um conjunto de

estratégias para a sua alimentação no BDEC, de forma a permitir que esse

componente possa ser configurado a fim de atender a diferentes aplicações e

usuários.

Quanto ao objetivo a), a SOFTBOARD permite a reutilização completa das classes de

seus componentes (excetuando o CDP) e, dessa forma, consegue-se melhorar a

qualidade dos sistemas. Porém, no desenvolvimento desses, não se pode deixar de se

preocupar com a modelagem da interface humano-computador, pois a interface

influencia na satisfação e na eficiência dos usuários, nos custos de treinamento, suporte

técnico e operação, e em alguns casos, na própria segurança das pessoas (Preece et al.,

1994; Shneiderman, 1998; Lucena e Liesenberg, 1999).

Quanto ao objetivo b), no trabalho de pesquisa Interface Configurável (Souza, 1997), as

classes do CIH foram projetadas, e um modelo inicial dos metadados necessários para

que a interface seja configurável foi apresentado. Esta pesquisa procurou detalhar o

modelo de metadados do CIH e descrever as estratégias para a alimentação desses

metadados no BDEC.

1.1 - Estrutura da Dissertação

Este trabalho de pesquisa apresenta, em seus próximos capítulos, os conteúdos

descritos a seguir.

No Capítulo 2, são introduzidos os conceitos básicos de interface humano-computador,

interação e usabilidade. Também se descreve a abordagem de desenvolvimento de

Cunha (1997) para a melhoria da qualidade dos sistemas de software produzidos e da

26

produtividade das equipes de desenvolvimento.

No Capítulo 3, apresentam-se as estratégias e padrões para a modelagem da interface

humano-computador de sistemas baseados na arquitetura SOFTBOARD.

No Capítulo 4, apresenta-se um modelo dos metadados necessários para a configuração

do CIH. Também se descreve um conjunto de estratégias para a alimentação do BDEC

com esses metadados.

No Capítulo 5, encontram-se as conclusões do trabalho, ressaltando as suas

contribuições.

No Apêndice A, apresenta-se a bibliografia sugerida para complementar este trabalho de

pesquisa.

Nos Apêndice B, encontra-se a descrição dos protótipos operacionais construídos para

verificar o modelo de metadados apresentados no Capítulo 4 e para validar a sua

adequação aos requisitos de um CIH configurável.

No Apêndice C, encontram-se as notações utilizadas para se construir os diversos

diagramas de modelagem definidos pela UML.

No Apêndice D, são agrupados os diagramas construídos para exemplificação das

estratégias apresentadas nos Capítulos 3 e 4.

No Apêndice E, é apresentada a notação simplificada do Case*Method, utilizada para

representar a modelo relacional dos metadados do CIH, descrito no Capítulo 4.

Finalmente, no Apêndice F encontra-se uma tabela com as diferenças, em valores de

cinza, entre as cores de uma paleta específica.

27

CAPÍTULO 2

FUNDAMENTAÇÃO

Neste capítulo são descritos os principais conceitos que serviram como base para o

desenvolvimento desta pesquisa.

Inicialmente, apresentam-se os conceitos básicos de interface e interação humano-

computador, assim como a tecnologia envolvida.

Em seguida, observa-se que a qualidade da interação usuário-sistema deve ser buscada

e apresenta-se o conceito de usabilidade e os seus desdobramentos.

Posteriormente, é apresentada a abordagem de Cunha (1997) para a melhoria da

qualidade dos sistemas de software e na produtividade das equipes de desenvolvimento,

enfocando dois de seus aspectos: o processo de desenvolvimento e os níveis de

abstração, e a arquitetura SOFTBOARD.

Finalizando, descrevem-se os conceitos de estratégias e padrões, mostrando a

importância de ambos na busca pela melhoria da qualidade e produtividade.

2.1 - Interface e Interação

O termo interface é aplicado normalmente àquilo que interliga dois sistemas. Uma

interface humano-computador é uma parte do sistema computacional, composta por

uma coleção de dispositivos, por meio dos quais o usuário pode trocar informações com

o sistema. Esses dispositivos são sensíveis às ações do usuário e são capazes de

estimular a sua percepção para que ele possa avaliar e controlar o funcionamento do

sistema (Leite, 1998).

A interface possui componentes de hardware e software. Os componentes de hardware

compreendem os dispositivos com os quais o usuário realiza as atividades motoras e

perceptivas. Entre eles estão a tela, o teclado, o mouse e vários outros. Os componentes

de software são responsáveis por controlar os dispositivos de hardware, construir os

dispositivos virtuais, com os quais o usuário também pode interagir, gerar os diversos

símbolos e mensagens que representam as informações do sistema e interpretar os

comandos do usuário (Souza et al., 1999).

28

Na Figura 2.1, observa-se que a interface é a parte do sistema responsável por traduzir

ações do usuário em ativações das funcionalidades (aplicação) e pela apresentação dos

resultados produzidos. A interação é um processo de comunicação entre o usuário e o

sistema, que engloba as ações do usuário sobre a interface e as suas interpretações sobre

as respostas reveladas por essa interface (Leite, 1998). Portanto, a interface é o

combinado de hardware e software que viabiliza a interação.

Fig. 2.1 - Interação usuário-sistema. FONTE: adaptada de Souza et al. (1999, p. 429).

A seguir são apresentados os estilos por meio dos quais acontece a interação. Em geral,

vários estilos estão presentes em uma mesma interface, como o caso da Interface

Gráfica de Usuário.

2.1.1 - Estilo de Interação

Estilo de interação é um termo genérico usado para referenciar o meio pelo qual o

usuário se comunica ou interage com o sistema (Preece et al. ,1994).

2.1.1.1 - Linguagem de Comando

No estilo de interação por linguagem de comando, as instruções são enviadas ao sistema

na forma de uma descrição textual.

Os comandos podem ser compostos por teclas de função, por um único caracter, por

palavras inteiras ou abreviações, ou por uma combinação de teclas e caracteres.

Geralmente, as sentenças possuem a sintaxe na forma de instrução mais complementos

(parâmetros e opções). Estruturas de controle também podem ser adicionadas às

sentenças para criação de novos comandos.

Dependendo do sistema, a entrada do comando pode acontecer por diferentes meios. Por

interpretação

Sistema

Interface Aplicação

ação

Usuário

ativação

resultado

29

exemplo, o usuário pode ter que digitá-lo por completo (Figura 2.2) ou de maneira mais

flexível, informar somente os complementos necessários, sendo os demais preenchidos

com valores padrões. Outro meio é por indagação onde, dado o comando, o sistema

apresenta os complementos a serem preenchidos.

Fig. 2.2 - Estilo de interação por linguagem de comando.

2.1.1.2 - Linguagem Natural

O uso da língua falada e escrita pelas pessoas como estilo de interação tem sido

considerado altamente desejável, em razão de sua naturalidade.

Uma interface baseada em linguagem natural tenta aproximar a aplicação do usuário,

pois privilegia a forma de comunicação deste último. Contudo, o sistema precisa lidar

com construções vagas, ambíguas e até mesmo gramaticalmente incorretas (na fala ou

na escrita) (Preece et al., 1994).

Ainda não é possível desenvolver sistemas que compreendam qualquer expressão da

linguagem natural, mas diversos tipos de sistemas especialistas utilizam com sucesso

algum subconjunto da língua. O usuário deve aprender como usar tal subconjunto, para

construir sentenças passíveis de interpretação (Souza et al., 1999).

2.1.1.3 - Menu

Um menu é uma lista de opções dispostas em uma coluna, em que a seleção de um ou

mais itens resulta em uma mudança do estado atual da interface. Usualmente, o

conjunto total de opções é distribuído de forma hierárquica por uma série de menus

30

(Paap e Cooke, 1997).

Este estilo é uma estrutura clara para tomada de decisão, uma vez que todas as

alternativas possíveis no momento são mostradas (Figura 2.3).

Uma das características mais bem estabelecidas sobre a memória humana é que se pode

reconhecer algo mais facilmente do que se lembrar dele. O uso de menus é adequado

para tal característica humana, pois o usuário passa por uma série de itens e reconhece

aquele que representa a sua necessidade. Contudo, para que este estilo seja eficaz, as

opções devem ser auto-explicativas (Preece et al., 1994).

Fig. 2.3 - Estilo de interação por menus.

2.1.1.4 - Preenchimento de Formulário

Este estilo é a representação informatizada de um formulário de papel, com informações

explicativas e campos para entrada e modificação de diferentes tipos de dados (Figura

2.4).

Usualmente, quando o preenchimento do campo está completo, o sistema realiza algum

tipo de consistência para garantir a entrada correta. Posteriormente, o cursor move para

a posição do próximo item que deve ser informado. Em geral, o usuário indica que o

formulário está completo por meio de um comando explícito.

31

Fig. 2.4 - Estilo de interação por preenchimento de formulário.

2.1.1.5 - Manipulação Direta

Na interface com o estilo de manipulação direta, o usuário pode agir diretamente sobre

as representações visuais apresentadas na tela, não sendo necessário conhecer comandos

em linguagens específicas. De acordo com Shneiderman (1998) as interfaces de

manipulação direta são definidas pelas seguintes características:

• representação visual de um objeto: por exemplo, uma planilha;

• ações rápidas e reversíveis: por exemplo, as ações de arrastar e soltar;

• visualização imediata do resultado: por exemplo, o objeto move na tela ao ser

arrastado;

• substituição da linguagem de comando pela manipulação do objeto de interesse: por

exemplo, o comando “Move” é substituído pelas ações arrastar e soltar.

2.1.1.6 - Fatores Favoráveis e Desfavoráveis de cada Estilo

Na Tabela 2.1 são apresentados alguns fatores favoráveis e desfavoráveis para o uso de

cada estilo de interação descrito.

32

TABELA 2.1 - FATORES FAVORÁVEIS E DESFAVORÁVEIS DE CINCO ESTILOS DE INTERAÇÃO

Estilo de Interação Fatores Favoráveis (F) e Desfavoráveis (D)

F É considerada poderosa por fornecer acesso direto à funcionalidade. Para o usuário mais experiente representa um ganho de eficiência.

Linguagem de comando

D

Conhecer a sintaxe dos comandos implica em uma substancial necessidade de treinamento e memorização. Os erros de digitação são freqüentes, mesmo entre os usuários mais experientes. A falta de padronização entre os sistemas é um fator importante na dificuldade de utilização desse estilo.

F Aproxima a aplicação do usuário, pois privilegia a forma de comunicação deste último. Beneficia os usuários com necessidades especiais.

Linguagem natural

D Atualmente, as aplicações possuem um dicionário de palavras e significados restritos ao domínio, exigindo o estabelecimento de diálogos precisos.

F Fornece um formato familiar e um conjunto claro de opções para executar as funcionalidades. Exige pouco treinamento, memorização e entradas via teclado. Menu

D O excesso de menus pode levar à lentidão da operação. Consome espaços de tela.

F É útil quando diferentes categorias de dados devem ser fornecidos ao sistema, principalmente, quando são digitadas repetidamente (ex. cadastros). São, em geral, fáceis de aprender. Preenchimento de

formulário D Consome espaços de tela.

F

Apresenta visualmente o conceito de tarefa (ex. copiar os arquivos de uma pasta para outra) e encoraja a exploração. O usuário pode imediatamente ver se sua ação está sendo aceita, do contrário, pode simplesmente alterá-la.

Manipulação direta

D

Nem sempre uma representação visual é compreendida pelo usuário. Um ícone gráfico pode ser significativo, mas pode requerer muito mais tempo para ser aprendido do que uma palavra. Algumas ações podem ser ineficazes (por exemplo, quando se deseja dimensionar precisamente um objeto).

FONTE: adaptada de Shneiderman (1998, p. 72).

33

2.1.2 - Interface Gráfica de Usuário

A primeira geração de interfaces (décadas de 50 e 60) foi marcada pela ausência

praticamente total de interação do usuário com o computador. A entrada de dados

ocorria por meio de cartões perfurados e a saída era impressa em papel. A interação

acontecia por meio de chaves e luzes indicando o estado da máquina.

A segunda geração (a partir da década de 60) foi caracterizada pela apresentação de

caracteres alfanuméricos e no uso da linguagem de comandos.

A partir da década de 80, as interfaces gráficas baseadas no estilo WIMP (Windows,

Icons, Menus and Pointers) transformaram o que era parecido com processos de

programação para um ambiente mais fácil de ser entendido no contexto humano.

Em geral, uma Interface Gráfica de Usuário (IGU) possui as seguintes características

(Souza, 1997):

• janelas que mostram as aplicações sendo executadas;

• ícones gráficos (representação simbólica de um objeto ou entidade);

• dispositivos secundários de entrada, normalmente um dispositivo indicador e

tipicamente um mouse;

• dispositivos virtuais de interação como os botões, caixas de texto, caixas de

verificação, barras de rolagem, escalas, entre outros;

• estilo de interação por menus e manipulação direta.

2.1.2.1 - Sistema de Janelamento

Segundo Myers (2000), o Sistema de Janelamento é um pacote de software que ajuda o

usuário a monitorar e controlar diferentes contextos de trabalho, por meio da divisão da

tela em regiões retangulares, chamadas de janelas.

Pode ser dividido em uma camada básica, chamada de Sistema de Janelas, que é

formada por um conjunto de rotinas. Essas são usadas para obter as entradas realizadas

a partir de um teclado ou dispositivo de apontamento e para desenhar gráficos,

ajustando-os à área da janela. Também é responsabilidade da camada atualizar a tela

34

quando as aplicações mudam seus dados e garantir a independência das aplicações em

relação aos diversos dispositivos de hardware usados.

Os Sistemas de Janelas atuais são dirigidos a eventos, o que permite ações de

manipulação direta na interface e múltiplas possibilidades de entrada. O usuário pode

decidir se faz a escolha de um item de menu, seleciona um ícone, usa o teclado para

digitação, entre outros. Cada registro de evento, normalmente, contém o tipo do evento,

o valor (como que tecla foi pressionada, a localização do ponteiro do mouse) e a janela

que o recebeu. Os eventos são colocados em uma fila e a aplicação, proprietária da

janela, deve retirá-los para processá-los ou descartá-los.

A outra camada, chamada de Gerenciador de Janelas, controla todos os aspectos que são

visíveis ao usuário. Ela é responsável por fornecer uma interface que permite o

redimensionamento e movimento de janelas, o estabelecimento de fontes e cores para a

área de trabalho, entre outros.

Alguns Sistemas de Janelamento são implementados como parte integrante do sistema

operacional, por exemplo, no Microsoft Windows e no Apple Macintosh (“kernel-

based”); outros são iniciados como processos, como o caso do X Window, presente em

muitas versões de Unix (Quercia e O’Reilly, 1991; Myers, 2000).

2.1.2.2 - Dispositivo Virtual

Um dispositivo virtual é um elemento gráfico presente na interface, por exemplo, um

botão, barra de rolagem, caixa de texto, entre outros, que permite a interação com o

usuário (Figura 2.5).

Cada dispositivo virtual pertence a uma classe que define sua aparência e

comportamento. A aparência descreve as propriedades visuais essenciais que lhe dá a

forma que o distingue dos outros. O comportamento determina aspectos dinâmicos que

são utilizados, por exemplo, para estímulo à percepção (Leite, 1998).

Para manter a consistência visual e funcional entre as aplicações baseadas em um

determinado padrão de interface, o desenvolvedor deve seguir diretrizes que orientam o

uso individual e combinado dos dispositivos virtuais. Alguns exemplos de diretrizes são

encontrados em “Macintosh human interface guidelines” (Apple Computer, 1993) para

35

o padrão de interface Macintosh, “The Windows interface: an application design guide”

(Microsoft, 1992) para o padrão de interface Windows e “Motif style guide” (OSF,

1990) para o padrão de interface Motif/X Window.

Fig. 2.5 - Dispositivos virtuais de uma interface gráfica.

O Sistema de Janelas oferece estruturas de dados para a definição das classes, a partir

dos quais os dispositivos virtuais são criados. Essas estruturas guardam endereços das

rotinas manipuladoras dos eventos ocorridos sobre o elemento e também, os valores das

propriedades, como tipo de ícone, cursor, cor e padrão de preenchimento.

A seguir um exemplo para a definição de uma classe e para a criação de dois

dispositivos virtuais no Microsoft Windows (Tabela 2.2).

TABELA 2.2 - INSTRUÇÕES PARA DEFINIÇÃO DA CLASSE E CRIAÇÃO DE DOIS DISPOSITIVOS VIRTUAIS

Instruções para a definição Comentário

WNDCLASSEX wcx Estrutura básica

Wcx.lpszClassName="MeuBotao" Nome da classe

Wcx.style = CS_HREDRAW | CS_VREDRAW Redesenhar se for redimensionado.

wcx.lpfnWndProc= TrataBotao Endereço da rotina que manipula os eventos

Continua.

36

TABELA 2.2 – (Conclusão)

Instruções para a definição Comentário

wcx.hInstance = hinstance Identificador da aplicação que a está criando.

wcx.hIcon= NULL Tipo de ícone.

wcx.hCursor=LoadCursor(NULL, IDC_ARROW) Tipo da seta do dispositivo de apontamento

wcx.hbrBackground=GetStockObject(GRAY_BRUSH) Cor de fundo e padrão de preenchimento.

wcx.lpszMenuName = NULL Menu padrão

RegisterClassEx(&wcx) Registro da classe, o que permite o seu uso

Instruções para criação Comentário

Botao1=CreateWindow(“MeuBotao”,”Ok”,...)

Botao2=CreateWindow(“MeuBotao”,”Cancelar”,...)

Cria dois dispositivos virtuais da classe MeuBotao

Os fabricantes de linguagens de programação orientadas a objeto criaram bibliotecas de

classes que encapsulam as rotinas e as estruturas fornecidas pelo Sistema de Janelas. A

Visual Component Library (VCL) e a Object Window Library (OWL), ambas da

Borland, são exemplos de bibliotecas baseadas no padrão de interface Windows.

2.2 - Usabilidade

Embora a tecnologia permita a construção de poderosos sistemas, isto não significa que

ela sozinha possa propiciar a interação mais adequada entre os usuários e os sistemas.

Por exemplo, a tecnologia de menus para a invocação de comandos pode aumentar a

eficácia (realização dos objetivos perseguidos) de alguns usuários, ainda que diminua

eficiência (alocação de poucos recursos - tempo, ações) de outros. Para um digitador

preocupado somente com a entrada de textos, a eficiência é severamente prejudicada se

certas funções forem alcançadas, unicamente, por acesso a menus (Software

Engineering Institute-SEI, 1987).

37

A propriedade da interface que permite quantificá-la como adequada ou não é conhecida

como Usabilidade, definida, tradicionalmente, como a combinação de cinco atributos

orientados ao usuário (Hix e Hartson, 1993; Preece et al., 1994; Snheiderman, 1998):

• facilidade de aprendizado: o usuário deve aprender a executar as tarefas no tempo

mais curto possível;

• alto desempenho na realização das tarefas;

• baixa taxa de erros na realização das tarefas;

• retenção após o uso (ou recordação): o quanto de conhecimento do sistema o

usuário retém, após um determinado período (uma hora, um dia, uma semana etc.);

• satisfação: o quão bem o usuário gosta e se sente confortável em trabalhar com o

sistema;

Portanto, a usabilidade está relacionada à eficácia e a eficiência do usuário ao usar a

interface e a sua satisfação para com ela.

Escolher os atributos de usabilidade prioritários para um sistema, requer o entendimento

de seus potenciais usuários, das tarefas por eles executadas e do ambiente em que estão

inseridos (LabIUtil, 2000).

Uma vez escolhidos é preciso, fundamentalmente, contar com colaboração da área de

Interação Seres Humanos e Sistemas Computacionais1 (IHC) para atingí-los. Os estudos

da IHC tentam fornecer aos pesquisadores e aos desenvolvedores de sistemas,

explicações e previsões para fenômenos da interação e resultados práticos para o projeto

da interface de usuário (ACM SIGHI, 1992).

Essa área esforça-se, primeiramente, para entender os fatores (psicológicos,

ergonômicos, organizacionais e sociais) que determinam como as pessoas fazem uso do

computador, de forma eficiente, e depois tentam traduzir esses entendimentos em

técnicas que podem ser empregadas pelos desenvolvedores para produzir sistemas com

usabilidade (Preece et al., 1994).

1 Tradução sugerida para o termo em inglês Human-Computer Interaction. A sigla IHC vem da tradução literal, para o português, desse termo em inglês. Outros termos sinônimos são interação pessoa-computador e interação usuário-sistema.

38

Dessa forma, as subseções seguintes deste tópico e a maioria das estratégias

apresentadas no Capítulo 3 têm como referência obras de pesquisadores da área de

IHC. Entre elas estão Human-computer interaction (Preece et al., 1994), Designing the

user interface (Shneiderman, 1998) e Ergonomia de interfaces humano-computador

(LabIUtil, 2000).

2.2.1 - Especificação de Usabilidade

A Especificação de Usabilidade define quais são os atributos de usabilidade prioritários

e seus objetivos quantitativos. Durante o desenvolvimento, em sessões de avaliação,

esses atributos são medidos e os valores obtidos são confrontados com os estabelecidos

na Especificação de Usabilidade, permitindo descobrir se a interface está adequada para

seus usuários ou se precisa ser melhorada (Hix e Hartson, 1993; Souza et al., 1999).

O objetivo da Especificação de Usabilidade é definir qual é o desempenho do usuário

aceitável, baseado nos usuários pretendidos para o sistema e nas tarefas mais

representativas executadas por eles (Hix e Hartson, 1993).

A Tabela 2.3 apresenta um exemplo em que a Especificação de Usabilidade é feita em

um formato tabular. Cada coluna é explicada após a tabela.

TABELA 2.3 - EXEMPLO DE UMA TABELA DE ESPECIFICAÇÃO DE USABILIDADE

Atributo Instrumento de medida

Valor a ser medido Nível atual

Nível mínimo

Nível almejado

Melhornível

Desempenho inicial

Incluir uma anotação de reunião.

Tempo para fazer uma inclusão na primeira tentativa em segundos

15

30

20 10

Desempenho inicial

Excluir uma anotação de reunião.

Número de erros na primeira tentativa

0

4

3

0

Primeira impressão

Questionário Média de pontos (escala de -2 a 2)

-

0

0,5

1,25

FONTE: adaptada de Hix e Hartson (1993, p. 223).

39

• Atributo: é o atributo da usabilidade a ser medido. Entre os mais comuns estão a

facilidade de aprendizado, o desempenho inicial (performance durante o primeiro

uso da interface), a retenção após o uso, a primeira impressão (opinião inicial) e

satisfação (opinião após o uso prolongado do sistema).

• Instrumento de medida: refere-se à técnica que fornece os valores para um dado

atributo de usabilidade. Um instrumento de medida gera dados numéricos e pode ser

objetivo (baseado no desempenho do usuário ao executar uma tarefa) ou subjetivo

(baseado na opinião ou preferência do usuário).

• Valor a ser medido: representa o dado específico a ser coletado durante a sessão de

avaliação. Pode ser o tempo para completar uma tarefa, o número de erros

cometidos, a percentagem de cumprimento da tarefa em um dado período, a

freqüência de acesso ao sistema de ajuda e à documentação, o número de

comandos/ações realizadas, entre outros.

• Nível atual: representa o valor obtido quando o atributo é medido no sistema

atualmente em uso (manual, automatizado ou em uma aplicação concorrente).

• Nível mínimo: é o mínimo desempenho aceitável. Ele pode estar, quando possível,

perto do nível atual e deve ser maior, se o nível atual não é satisfatório. Contudo,

para os atributos que marcam o uso inicial do sistema, este nível é, possivelmente,

menor, uma vez que os usuários estão mais familiarizados com o sistema atualmente

em uso.

• Nível almejado: representa a meta de usabilidade para o atributo. Quando esse nível

ainda não está alcançado, significa que a interface ainda precisa de melhorias em

relação ao atributo.

• Melhor nível: é o melhor desempenho esperado (nível ótimo). Pode ser definido a

partir do desempenho dos usuários experientes ou daqueles que são profundos

conhecedores da interface (como os próprios desenvolvedores).

40

2.2.2 - Avaliação de Usabilidade

A avaliação de usabilidade tem como objetivos gerais validar a eficácia da interação

humano-computador, face a efetiva realização das tarefas por parte dos usuários,

verificar a eficiência desta interação, face aos recursos empregados (tempo, quantidade

de erros, passos desnecessários, busca de ajuda, etc.) e obter indícios de satisfação

subjetiva ou insatisfação que ela possa trazer ao usuário (LabIUtil, 2000).

Durante a avaliação, também se deve tentar detectar problemas de usabilidade, ou seja,

aspectos da interface que acabam por retardar, prejudicar ou mesmo inviabilizar a

realização de uma tarefa pelo usuário. Segundo LabIUtil (2000), embora um problema

de usabilidade se revele durante a interação, ele tem a sua origem em decisões tomadas

de modo equivocado, durante o desenvolvimento.

Neste trabalho, a avaliação está direcionada para verificar se a interface está

convergindo para as metas especificadas e para conhecer quais são os seus problemas,

de forma que os desenvolvedores possam corrigí-los. Portanto, acontece durante o

desenvolvimento e não após o sistema terminado.

Com esse propósito, diferentes avaliações de usabilidade podem ser realizadas, sendo

algumas delas apresentadas a seguir. Contudo, deve-se ressaltar que elas possuem

limitações e que existem outras abordagens que podem ser usadas para o mesmo

objetivo.

2.2.2.1 - Ensaio de Interação

Baseado na participação direta dos usuários, em campo (ambiente de trabalho normal)

ou em laboratório, onde realizam atividades com versões ou protótipos operacionais da

interface.

Durante o ensaio podem ser gerados os seguintes tipos de dados (Hix e Hartson, 1993):

• quantitativos: são dados numéricos, obtidos a partir da medição de algum tipo de

desempenho humano (enquanto executam determinadas tarefas) ou da opinião dos

usuários sobre a interface. A análise desses dados permite descobrir se as metas de

usabilidade, conforme estabelecidas na Especificação de Usabilidade, estão sendo

atingidas;

41

• qualitativos: são dados não numéricos, tais como listas de sugestões e de problemas

encontrados durante o ensaio. A análise desses dados permite determinar que

informações e/ou conhecimentos faltam aos usuários para que possam

adequadamente usar a interface e fornece explicações para os dados quantitativos

obtidos.

Técnicas para a geração de dados quantitativos

Execução de tarefas

Consiste em medir diretamente o desempenho do usuário enquanto realiza uma tarefa

com a interface. De acordo com o objetivo da avaliação, o valor obtido pode ser o

tempo que o usuário leva para completar a tarefa, o número de erros cometidos, o

número de acesso ao sistema de ajuda ou à documentação, a percentagem cumprida da

tarefa em um dado período, o número de comandos/ações realizadas, entre outros.

Questionário

O usuário responde a uma série de questões fechadas (escolhe entre duas ou mais

alternativas) cujas perguntas estão direcionadas para aspectos de satisfação em relação a

interface e sua operação.

As questões possuem associadas alguma escala numérica ou com intensidade de

preferência para classificação, conforme apresentado nas Figuras 2.6 e 2.7. As respostas

obtidas são convertidas para valores numéricos para que possam passar por uma análise

estatística.

Fig. 2.6 - Questão com escala numérica.

Facilidade de localizar as informações, na escala seguinte:

Difícil Fácil

1 2 3 4 5 6

42

Fig. 2.7 - Questão com escala de preferência.

Técnicas para a geração de dados qualitativos

Verbalização simultânea (pensar alto)

É uma técnica em que é solicitado ao usuário para que comente o que pensa enquanto

realiza a tarefa, indicando o que está tentando fazer, a razão de uma dificuldade ou o

que gostaria que acontecesse naquele momento. Perguntas do tipo ‘O que você está

pensando?’, ‘Por que você fez isso?’ ou ‘O que você espera que aconteça?’ são

empregadas para estimular o diálogo com o usuário.

Pela fala é possível conhecer a forma como o usuário planeja fazer uma determinada

tarefa; suas reações diante de algum problema; o seu entendimento sobre as mensagens

de erro; como reconhece os ícones e os nomes dos itens de menu, etc. (Preece et al.,

1994).

Verbalização consecutiva

Alternativamente, a verbalização pode acontecer após a realização do ensaio.

Geralmente, assistindo a uma filmagem da interação, o usuário comenta sobre suas

ações e reações diante da interface, refletindo sobre a experiência.

Entrevista

A entrevista explora o entendimento do usuário sobre a interface e/ou a sua preferência

ou opinião sobre alguns de seus aspectos.

Pela sua flexibilidade na construção das perguntas, diferentes dados podem ser obtidos.

Por exemplo, perguntas como ‘Quais são as três informações mais importantes que o

Classificação do sistema X nas seguintes dimensões:

Muito Bem Um pouco

Neutro Um pouco

Bem Muito

Fácil

Claro

Flexível

Difícil

Confuso

Rígido

43

usuário deve saber para usar a interface?’ ou ‘O que você mais/menos gostou na

interface?’ mostram-se bastante pertinentes e podem revelar, entre outros, dificuldades,

rupturas de consistência e indícios de satisfação/insatisfação.

Técnicas para o registro dos dados

Anotação manual

Para registrar observações ou o desempenho dos usuários, o avaliador pode usar lápis e

formulários em papel ou ferramentas de software, como as planilhas e processadores

de texto.

Gravação com câmeras de vídeo

A gravação em vídeo pode ser usada como alternativa ou complemento à anotação. É

uma técnica que permite registrar vários tipos de dados, tendo o potencial de fornecer

uma completa descrição da interação (Preece et al., 1994).

Vários aspectos das atividades do usuário podem ser monitorados por diferentes

câmeras de vídeo. Por exemplo, uma câmera pode ser focada no teclado e monitor

enquanto a outra é direcionada para o usuário. O registro de seu comportamento,

expressões e atitudes podem fornecer informações importantes sobre o processo de

interação (Preece et al., 1994).

Gravação do áudio

A filmagem geralmente é acompanhada de alguma forma de registro de áudio. Este

também pode acontecer durante a verbalização simultânea ou consecutiva (Preece et al.,

1994).

2.2.2.2 - Modelo de Usabilidade

Uma abordagem que pode antecipar resultados dos ensaios de interação e assim

diminuir um pouco do tempo gasto para com eles, consiste na construção de modelos

que conseguem produzir previsões quantitativas, de o quão bem os usuários serão

capazes de executar tarefas com uma determinada interface (Kieras, 1997).

Conhecendo essas previsões, o desenvolvedor pode melhorar ou corrigir a especificação

da interface, avaliando-a antes de implementá-la (Kieras, 1997).

44

A seguir são apresentados dois modelos de análise, o “Keystroke-Level Model” (KLM)

e o “Goals, Operators, Methods, and Selection Rules” (GOMS). Ambos foram

propostos por Card, Moran e Newell (1983).

Modelo “Keystroke-Level”

O modelo KLM permite prever o tempo para execução de uma tarefa, a partir da soma

dos tempos das ações que devem ser executadas para realizá-la. Não é necessário que a

interface esteja implementada, basta que ela esteja especificada em detalhe suficiente

para determinar as seqüências de ações das tarefas de interesse (Kieras, 2001).

As ações modeladas estão em um nível muito elementar, como, pressionar uma tecla,

mover o mouse, soltar um botão e assim por adiante.

O KLM possui um conjunto padrão de ações, chamadas de operadores, cujos tempos

para execução foram estimados a partir de dados experimentais.

A Tabela 2.4 apresenta os operadores e os tempos associados.

TABELA 2.4 - OPERADORES KLM

Operador Tempo estimado em segundos K – pressionar uma tecla Varia com o nível de experiência do usuário:

Digitador experiente = 0,12 seg. Digitador mediano = 0,20 seg. Usuário médio = 0,28 seg. Usuário sem nenhuma experiência = 1,20 seg.

T(n) – digitar uma seqüência de teclas K * n

P – apontar o ponteiro do mouse em um determinado local da tela.

Média de 1,10 seg.

B – pressionar ou soltar o botão do mouse

0,10 seg.

BB – pressionar e soltar o botão do mouse.

0,20 seg.

Continua.

45


Operador Tempo estimado em segundos

H – movimentar as mãos para o teclado ou para o mouse

0,40 seg.

M – Ação mental rotineira Média de 1,20 seg.

W(t) – tempo de espera pela resposta do sistema.

t seg.

FONTE: adaptada de Kieras (2001).

A seguir, um exemplo do uso do KLM para avaliação de duas especificações de

interface construídas para a tarefa de exclusão de um arquivo.

Primeira especificação: excluir o arquivo arrastando-o para a Lixeira.

1) Apontar para o ícone do arquivo. P

2) Pressionar e reter o botão do mouse. B

3) Arrastar o ícone do arquivo para o ícone da Lixeira. P

4) Soltar o botão do mouse. B

5) Apontar para a janela original. P

Tempo total = 3P + 2B = 3, 50 seg.

Segunda especificação: excluir o arquivo selecionando uma opção no menu.


2) Clicar com o botão do mouse. BB

3) Apontar para o item de menu ‘Arquivo’. P


5) Apontar para o subitem de menu ‘Excluir’. P



46

Tempo total = 4P + 4B = 5, 20 seg.

A diferença entre as especificações é que a segunda requer um movimento adicional do

mouse. Uma melhoria seria colocar uma tecla aceleradora para o opção ‘Excluir’.

Operador mental

O operador M é baseado no fato de que, quando um usuário está empenhado em um uso

rotineiro do computador, existem pausas entres suas ações, como para lembrar um nome

de arquivo. Esse operador pretende representar o pensamento rotineiro, não aquele

complexo usado na resolução de problemas ou meditações criativas. Após

experimentos, verificou-se que os tempos para essas pausas são aproximados, o que

justificou a sua suposição em torno de um segundo (Kieras, 2001).

O operador M é usado para modelar as ações do usuário para iniciar uma tarefa (o

usuário pára e faz a decisão do que deseja fazer); procurar por algum item na tela;

verificar se uma especificação ou ação está correta antes de prosseguir; e para recuperar

um bloco da memória (um bloco é uma unidade familiar, tal como um nome de arquivo,

uma sentença de comando ou uma abreviação).

A seguir um exemplo com o uso do operador mental M.

1) Iniciar a exclusão (decidir fazer a tarefa). M

2) Procurar pelo ícone do arquivo. M



5) Arrastar o ícone do arquivo para o ícone da Lixeira. P



Modelo GOMS

O modelo GOMS é uma descrição do conhecimento que o usuário precisa ter para

conseguir executar tarefas em um dispositivo ou sistema.

Ele representa o conhecimento “como fazer esta tarefa no sistema”, usando três

47

subsistemas humanos: o perceptual (visual), o motor (movimento braço-mão-dedo e

cabeça-olho) e cognitivo (acesso à memória e tomada de decisão) (Souza et al., 1999).

Para construir um modelo GOMS para uma tarefa, precisa-se de elaborar os seguintes

componentes:

• metas (“goals”): algo que se deseja obter com o sistema, um objetivo a ser

alcançado;

• operadores (“operators”): ações perceptivas, motoras ou cognitivas que os usuários

devem executar;

• métodos (“methods”): conjunto de passos, constituídos por operadores, para se

atingir uma meta;

• regras de seleção (“selection rules”): expressões do tipo condição-ação que devem

ser usadas para selecionar um método, quando existe mais de um para se alcançar

uma meta.

Resumidamente, um modelo GOMS consiste de descrições de métodos que são

necessários para alcançar uma meta. Os métodos são uma série de passos consistindo de

ações que o usuário executa. Um método pode invocar a execução de submetas, logo se

caracteriza por ter uma estrutura hierárquica. Se existe mais de um método para

alcançar uma meta, então regras de seleção escolhem aquele que é mais apropriado no

contexto (Kieras, 1997).

O modelo NGOMSL (Natural GOMS Language), proposto por Kieras (1997), é uma

tentativa de definir uma linguagem natural para representar as metas, métodos e as

regras de seleção do modelo GOMS.

O modelo permite representar o conhecimento “como fazer isto” na forma de como

ele pode na verdade ser obtido. O desenvolvedor pode caminhar pelos métodos,

executando as ações descritas e sentir o impacto de suas decisões, quanto ao

desempenho e carga de memória imposta (Kieras, 1997).

A NGOMSL tem a seguinte notação:

Método para a meta: <descrição da meta>

48

Passo 1) <operador>

Passo 2) <operador>

Passo n) Retornar com a meta alcançada.

Alguns operadores encontrados nas sentenças são assim constituídos:

TABELA 2.5 - OPERADORES NGOMSL

Operadores externos primitivos do NGOMSL Equivalente KLM Pressionar <nome da tecla> K Digitar <seqüência> T Movimentar as mãos para o mouse ou teclado P Pressionar ou soltar o botão do mouse B Clicar BB

Operadores externos primitivos do NGOMSL Equivalente KLM Mover o cursor para <alvo> P Apontar o ponteiro do mouse para <alvo> P Localizar um objeto na tela <nome do objeto> M Verificar que <descrição> M Esperar por <descrição> W

Operadores mentais primitivos do NGOMSL Lembrar que <descrição> Guardar que <descrição> Esquecer que <descrição>

Alguns operadores definidos pelo desenvolvedor Ler <descrição> da tela Pensar em <descrição>

FONTE: adaptada de Kieras (1997).e

A seguir, um exemplo simplificado da aplicação do modelo GOMS, usando a notação

NGOMSL.

1) Sistema com estilo de interação que permite manipulação direta.

Método para a meta: excluir um arquivo.

Passo 1) Alcançar a meta: arrastar o arquivo para a Lixeira.

Passo 2) Retornar com a meta alcançada.

49

Para especificar a meta ‘Arrastar o arquivo para a Lixeira’, existe uma submeta

correspondente:

Método para a meta: arrastar o arquivo para a Lixeira.

Passo 1) Localizar o ícone do arquivo na tela.

Passo 2) Apontar para o ícone.

Passo 3) Pressionar e reter o botão do mouse.

Passo 4) Localizar o ícone da Lixeira.

Passo 5) Apontar para o ícone da Lixeira.

Passo 6) Verificar se o ícone da Lixeira está em vídeo reverso.

Passo 7) Soltar o botão do mouse.


2) Sistema com estilo de interação por linguagem de comando:

Método para a meta: excluir um arquivo.

Passo 1) Lembrar que o comando é “Erase”.

Passo 2) Pensar no nome do diretório e no nome do arquivo.

Passo 3) Alcançar a meta: digitar o comando.


Para especificar a meta ‘Digitar o comando’, existe uma submeta correspondente:

Método para a meta: digitar o comando

Passo 1) Digitar o comando ‘Erase’.

Passo 2) Digitar ‘ ‘.

Passo 3) Digitar o nome do diretório.

Passo 4) Digitar ‘\’.

Passo 5) Digitar o nome do arquivo.

50

Passo 6) Verificar o comando.

Passo 7) Digitar ‘<enter>’.


Com a construção de modelos NGOMSL consegue-se:

• prever o tempo para aprender e o tempo para execução das tarefas pelo usuário:

o tempo para aprender um conjunto de métodos é, basicamente, determinado pelo

seu tamanho (dado pelo número total de sentenças NGOMSL construídas). Esta é a

quantidade de conhecimento procedimental que o usuário tem que adquirir, para

saber como usar o sistema;

o tempo de execução de cada tarefa é dado pela soma de tempos fíxos de cada

sentença mais o tempo estimado para cada operador dentro da mesma.

Tempo de execução = (número de sentenças NGOMSL * 0,1 seg) +

Tempo dos operadores externos primitivos +

Tempo dos operadores definidos pelo desenvolvedor.

Para o primeiro exemplo, tem-se que:

Tempo de execução = (12* 0,10) + ( (3* 1,2) + (2 * 1,1) + (2 * 0,1) ) = 8, 4 seg.

o uso explícito dos operadores mentais é uma maneira de identificar onde o sistema

está impondo uma forte carga de memorização ao usuário.

• avaliar a qualidade da especificação quanto à:

naturalidade: existem metas e submetas que fazem sentido para um novo usuário,

ou para que isso aconteça, ele tem que pensar de uma forma diferente para realizar a

tarefa;

clareza: se existe mais de um método para alcançar uma meta, deve haver uma

regra clara para a escolha do mais apropriado. Caso não, alguns desses métodos

podem ser desnecessários;

consistência: o usuário não deve se perguntar se diferentes palavras, símbolos ou

ações significam a mesma coisa. Consistência se refere a observação das mesmas

51

convenções e regras entre os elementos de uma interface e entre outras aplicações.

Dessa forma, existem metas similares que são alcançadas por métodos similares? A

mesma idéia se aplica para consistência entre aplicações: um método que funciona

em uma outra aplicação também funciona nesta?

eficiência : as mais importantes e mais freqüentes metas são alcançadas para

métodos curtos ou de execução rápida?

2.3 - Uma Abordagem de Desenvolvimento de Software para a Melhoria da

Qualidade e da Produtividade

Com o cenário de transformação constante do mercado mundial, a temática prioritária

no campo empresarial passou a ser a competitividade. Diante desse contexto, a

qualidade assume cada vez mais importância e sua evidência é mostrada como fator

diferenciador nos produtos disponíveis comercialmente. Por outro lado, minimizar os

custos de investimento no produto e o tempo para a sua liberação para o mercado, não

somente são desejáveis, mas absolutamente essenciais para a sobrevivência da empresa.

O principal foco de qualquer definição de qualidade de software deve estar no

atendimento às necessidades dos usuários. As questões chaves são: quem são os

usuários, o que é importante para eles e como fazer para incorporar suas prioridades no

sistema (Humphrey, 2001).

Dessa forma, um grande desafio que a Engenharia de Software tem encontrado é o de

como desenvolver sistemas de software com qualidade, com elevada produtividade,

dentro do prazo estabelecido, utilizando o mínimo de recursos possível (Fiorini et al.,

1998).

As pesquisas por soluções para esse desafio vêm acontecendo nos últimos anos. Uma

delas, é a abordagem de Cunha (1997) para a melhoria da qualidade dos sistemas de

software e na produtividade das equipes de desenvolvimento. Esta abordagem descreve

que os desenvolvedores devem:

• utilizar o paradigma de desenvolvimento de software orientado a objetos;

• estabelecer uma arquitetura para o sistema de software a ser desenvolvido,

propiciando o máximo de reutilização;

52

• estabelecer um ambiente de desenvolvimento, de acordo com a cultura da

organização e voltado para a arquitetura de sistema estabelecida. Tal ambiente deve

ser formado pela integração de três elementos básicos:

processos: conjunto de atividades técnicas e gerenciais realizadas para o

desenvolvimento de sistemas de software;

pessoas: responsáveis pela execução das atividades do processo;

infraestrutura: recursos de hardware e software disponíveis para o

desenvolvimento;

• controlar os aspectos técnicos, gerenciais, humanos e organizacionais do

desenvolvimento.

Dois aspectos dessa abordagem são detalhados a seguir: o processo de desenvolvimento

e uma arquitetura com ênfase na reutilização.

2.3.1 - O Processo de Desenvolvimento

Para propósitos deste trabalho, um processo de desenvolvimento consiste em um

conjunto de atividades técnicas (direcionadas para construção) e gerenciais

(direcionadas para planejamento, acompanhamento e controle da qualidade) bem

definidas e organizadas, cujo objetivo é guiar, eficientemente, o desenvolvimento de um

sistema de software de forma que este satisfaça as necessidades de seus usuários.

Contudo, as necessidades dos usuários não são fáceis de discernir, o que requer alguma

forma de, claramente, comunicá-las e apurá-las. Posteriormente, é preciso projetar e

implementar uma solução que as satisfaçam e finalmente, deve-se verificar se as

mesmas foram alcançadas, testando o sistema (Jacobson et al., 1999).

Para tratar tal complexidade, a abstração é um princípio fundamental, pois permite

selecionar aspectos importantes de um problema, deixando de lado outros. A abstração

é a capacidade de olhar apenas uma parte de um todo, ou seja, retirar da realidade

apenas as entidades e fenômenos considerados essenciais, excluindo-se todos os

aspectos secundários. Através do mecanismo de abstração, o ser humano pode entender

formas complexas, ao dividi-las em partes e analisar cada parte separadamente

53

(Rumbaugh et al., 1991; Coad e Yourdon, 1992; Booch, 1994).

Modelos são abstrações do sistema de software. Dessa forma, muitas das atividades de

um processo referem-se à construção de modelos em determinados níveis de abstração e

com aspectos relevantes distintos.

Conforme apresentado, um processo de desenvolvimento bem definido está dentro da

abordagem de Cunha (1997), para a melhoria da qualidade dos sistemas de software e

na produtividade dos desenvolvedores. Dando continuidade à pesquisa de Cunha

(1997), em Dias (1999), é apresentado um processo de desenvolvimento voltado para a

construção de modelos para o sistema de software. Este processo é embasado nos

trabalhos de Yourdon (1990) e Setzer (1995).

Dentro desse processo, o primeiro nível de abstração é a própria visão do desenvolvedor

em relação ao mundo real, constituído por um conjunto de objetos reconhecidos como

organismos sociais, seres, lugares, coisas e eventos. Pode-se considerar o mundo real

como sendo o domínio de negócios e o conjunto de necessidades dentro desse domínio

(Setzer, 1995; Dias, 1999).

O segundo nível de abstração, denominado Nível Descritivo, corresponde ao domínio

do problema e ao subconjunto de necessidades abrangidas. Para melhor compreendê-

los, o Modelo de Negócio descreve os processos de negócio envolvidos assim como as

competências requeridas para cada um: as pessoas, suas responsabilidades e as tarefas

por elas realizadas.

O terceiro nível de abstração, denominado Nível Conceitual, corresponde ao sistema e

suas responsabilidades. O Modelo Conceitual enfoca o que o sistema deve fazer para

apoiar os processos de negócio e satisfazer as necessidades identificadas. Consiste de

duas partes principais: o Modelo Ambiental que mostra o seu ambiente externo e os

comportamentos observáveis, e o Modelo Comportamental onde esses

comportamentos são alocados para um conjunto de objetos internos do sistema

(Yourdon, 1990; Dias, 1999).

O quarto nível de abstração, denominado Nível Operacional, corresponde à construção

do sistema. O Modelo Operacional enfoca como o sistema será construído e

54

implantado, face às tecnologias escolhidas. Consiste de duas partes principais: o

Modelo de Implementação que refina o Modelo Conceitual, adicionando estruturas e

comportamentos necessários para a implementação, e o Modelo de Implantação que

descreve como o sistema será distribuído entre os recursos computacionais disponíveis

(Dias, 1999).

O Nível Físico é último nível de abstração e corresponde ao sistema de software

implementado e implantado. O Modelo Físico mostra os diversos componentes de

códigos fontes, executáveis e demais artefatos construídos e alocados em recursos

computacionais (Dias, 1999).

A Figura 2.8 apresenta os diversos níveis de abstração que acontecem ao longo do

desenvolvimento de sistemas de software.

Fig. 2.8 - Níveis de abstração durante o desenvolvimento. FONTE: adaptada de Dias (1999). Tem-se que o processo de desenvolvimento deve ser escolhido e adaptado para a cultura

de cada organização (Cunha, 1997). Sendo assim, para mostrar a coerência entre este

Mundo

Real

Nível Descritivo

Processo

Nível Conceitual

Nível Físico

Nível Operacional

55

processo de desenvolvimento e os demais processos, a seguir descreve-se o Processo

de Desenvolvimento Unificado, proposto por Jacobson, Booch e Rumbaugh (1999).

Ao final da próxima seção, é realizada uma comparação entre os resultados produzidos

pelas atividades técnicas do Processo Desenvolvimento Unificado e os modelos

propostos por Dias (1999).

2.3.1.1 - Processo de Desenvolvimento Unificado

O Processo de Desenvolvimento Unificado é o resultado da união dos trabalhos de

Jacobson, Booch e Rumbaugh (1999). Suas principais características são o

desenvolvimento iterativo e incremental, orientado a objetos, com foco na construção de

uma arquitetura robusta, análise de riscos e utilização de casos de uso para o

desenvolvimento. Também utiliza a Linguagem de Modelagem Unificada (UML) para

especificar, construir e documentar seus modelos.

O processo divide as atividades técnicas em subprocessos, chamados de fluxos de

trabalho – Requisitos, Análise, Desenho2, Implementação e Testes; e as atividades

gerenciais em subprocessos, chamados de fases – Concepção, Elaboração, Construção e

Transição.

Fases do Processo

Uma fase é o período de tempo, entre dois importantes marcos do progresso do

processo, em que um conjunto de objetivos é alcançado, artefatos são concluídos e

decisões são tomadas em relação à passagem para a fase seguinte.

Fase de Concepção

Fase em que se procura delimitar o escopo do sistema, capturar seus principais

requisitos, identificar os riscos de desenvolvimento e fazer uma estimativa de recursos

(financeiros, de tempo e humanos). O objetivo é justificar a execução de um projeto

para o desenvolvimento de software, tanto do ponto de vista econômico, quanto do

ponto de vista do negócio do cliente, ou seja, se o cliente possui necessidades

suficientes a serem tratadas por um sistema de software.

2 Palavra usada como sinônimo de design, e não na acepção de desenho pictórico. O termo projeto é usado na acepção de unidade gerencial.

56

Fase de Elaboração

Fase na qual a maioria dos requisitos restantes é levantada e detalhada (Análise e

Desenho) permitindo construir uma arquitetura para o sistema. Ao seu final a gerência

está na posição de planejar a construção e estimar os recursos requeridos para o término

do projeto.

Fase de Construção

Fase durante a qual é desenvolvida (implementada e testada), de maneira incremental,

uma versão completamente operacional do sistema de software. Tal versão deve atender

aos requisitos acordados e estar pronta para ser operada pelos seus usuários reais.

Fase de Transição

Cobre o período em que uma versão do sistema de software é disponibilizada à sua

comunidade de usuários. Tipicamente, é iniciada com a realização de testes alfa (uso do

sistema dentro do ambiente de desenvolvimento), evoluindo para testes beta (realizada

no ambiente operacional) e terminando com o sistema em produção. Durante essa fase,

os defeitos e deficiências encontradas pelos usuários são corrigidos. No final da

Transição pode ser iniciado um novo ciclo de desenvolvimento, o que envolveria todas

as fases novamente.

O Processo de Desenvolvimento Unificado é iterativo, o que significa que se podem

repetir os cinco fluxos várias vezes ao longo de sua execução. Cada seqüência dos

fluxos é chamada de iteração. Portanto, dentro de cada iteração podem ser executadas

atividades paralelas relacionadas a levantamento de Requisitos, Análise, Desenho,

Implementação e Testes.

Uma fase comporta uma ou mais iterações, sendo que estas possuem diferentes ênfases

de acordo com a fase. Nas iterações iniciais a maioria dos esforços é direcionada para o

levantamento de Requisitos e Análise do problema, posteriormente a ênfase muda para

o Desenho, Implementação e Testes, como mostra a Figura 2.9.

57

Fig. 2.9 - Estimativa de esforços nas fases do Processo de Desenvolvimento Unificado. FONTE: Jacobson et al. (1999, p. 11). Cada iteração libera resultados tangíveis na forma de artefatos. As iterações

subseqüentes realizam melhorias ou complementos dos artefatos anteriores e

demonstram uma redução dos riscos com a qual a iteração estava preocupada. São

exemplos usuais de áreas de riscos, que são postas à prova nas primeiras iterações: os

requisitos funcionais mais importantes; as interfaces de usuário; novos equipamentos e

sistemas com os quais a equipe de desenvolvimento não está familiarizada, entre outros

(Jacobson et al., 1999; Paula, 2001).

Dessa forma, o processo é incremental, pois seus artefatos são aperfeiçoados

sucessivamente, a partir da avaliação da equipe de desenvolvimento.

Fluxos do Processo

Cada fluxo detalha o que é feito (atividades), por quem (responsáveis), os artefatos que

consome e os artefatos que produz. Esses artefatos estão sujeitos a critérios de

aprovação. Para propósitos deste trabalho, a seguir são apresentados somente os fluxos

e algumas das atividades realizadas dentro de cada um.

Fluxo de Requisitos

Fases Fluxos Concepção Elaboração Construção Transição

Requisitos

Análise

Desenho

Implementação

Testes

Iter. 1

Iter. 2

... ... ... ... ... Iter. n-1

Iter. n

Iterações

58

O valor de um produto vem de suas características. Tratando-se de sistemas de software,

costuma-se dividir as características em: funcionais, que representam os

comportamentos que o sistema deve apresentar diante de certas ações dos usuários; e

não funcionais, que quantificam determinados aspectos do comportamento

(Sommerville, 1995; Paula, 2001).

No fluxo de Requisitos procura-se entender o contexto em que o sistema deve operar e

capturar as características para os quais ele deve estar conforme.

Fluxo de Análise

No fluxo de Análise, analisam-se os requisitos capturados de forma a detalhá-los e

estruturá-los, em termos de elementos internos ao sistema.

Fluxo de Desenho

O fluxo de Desenho visa construir uma estrutura implementável para o sistema de

software que atenda aos requisitos especificados para este. Neste fluxo se escolhe as

soluções tecnológicas mais adequadas (linguagens de programação, banco de dados,

entre outros) e identificam-se os elementos a serem reutilizados.

Fluxo de Implementação

O fluxo de Implementação transforma os resultados do Desenho em diversos

componentes de pseudocódigo, código fonte e binário, o que permite obter uma versão

executável do sistema de software.

Fluxo de Testes

No fluxo de Testes são especificados os procedimentos (ações a serem realizadas) e os

casos de teste (valores de entrada e saída). Com base na especificação, os testes são

realizados para a validação, frente aos requisitos especificados e verificação dos

resultados da implementação.

Fluxos e Modelos

Pode-se entender que no fluxo de Requisitos, o enfoque está em, primeiramente,

entender o domínio do problema e posteriormente definir as responsabilidades do

sistema dentro dele. Desenvolve-se uma compreensão do contexto, quando se procura

59

representar os diversos papéis das pessoas envolvidas no negócio e as tarefas por elas

realizadas, criando o Modelo de Negócio. Também no fluxo de Requisitos é definido o

que o sistema deve fazer para atender às necessidades de seus usuários. Dessa forma,

compreende-se que se obtém o Modelo Ambiental, no sentido de que se tem o

ambiente em que o sistema está inserido e o que ele provém para o seu uso.

No fluxo de Análise, os conceitos do domínio do problema são modelados internamente

ao sistema. Dessa forma, compreende-se que se obtém o Modelo Comportamental do

sistema.

No fluxo de Desenho, o enfoque está em como os requisitos levantados devem ser

materializados. Para isso, é considerado o ambiente de implementação (linguagem de

programação, banco de dados, sistema operacional, entre outros), assim como o

ambiente de execução (recursos computacionais). Compreende-se que se obtém

Modelo de Implementação, detalhado em nível suficiente para resolver todos as

questões de implementação. O Modelo de Implantação também resulta desse fluxo,

quando se considera a alocação do sistema de software nos recursos computacionais

necessários para o atendimento dos requisitos.

No Fluxo de Implementação, o sistema é implementado e é gerada uma série de

artefatos como bibliotecas, códigos executáveis, esquemas para bancos de dados, entre

outros. Entende-se que esse conjunto de artefatos e os demais documentos elaborados

representam o Modelo Físico do Sistema de Software.

2.3.2 - A Arquitetura Configurável de Sistemas de Software Orientado a Objetos

Quando uma organização começa a usar processos bem definidos para o

desenvolvimento, os maiores ganhos iniciais resultam na redução de defeitos no sistema

de software e consequentemente, na redução do desperdício de tempo e dinheiro. A

partir daí, ganhos significativos de produtividade só são conseguidos através da

reutilização. A automação de algumas tarefas de desenvolvimento, por meio de

ferramentas bem escolhidas, contribui para redução de defeitos, mas não resulta em

ganho de produtividade comparável com a reutilização.

O fator reutilização significa a possibilidade de aproveitar o que foi desenvolvido em

60

um sistema de software para a construção de outros sistemas. A produtividade é

alcançada pois os artefatos já construídos podem ser reusados, economizando os

recursos que seriam usados para desenvolvê-lo. A qualidade do sistema também é

melhorada, uma vez que esses artefatos já serviram aos seus propósitos uma ou

inúmeras vezes, o que traz segurança quanto a sua correção (Sommerville, 1995; Cunha,

1997; Paula, 2001).

A motivação de Cunha para o estabelecimento de uma arquitetura que propicie o

máximo de reutilização, surgiu de suas observações quando da orientação de projetos

acadêmicos para o desenvolvimento de sistemas de software. Ficou claro para Cunha

que não existem dois sistemas de software exatamente iguais, mas não existem dois

sistemas de software totalmente diferentes. A única parte em que se diferenciam é na

essência da aplicação ou no domínio do problema, sendo que, a gestão de dados, a

interface e a interação com outros sistemas possuem características comuns entre as

aplicações.

Para evitar o trabalho de construir os componentes comuns a cada novo

desenvolvimento, Cunha começou a explorar a reutilização de código, evoluindo para

códigos configuráveis, e finalmente, para a adoção de uma arquitetura configurável de

sistemas de software orientada a objetos, denominada SOFTBOARD.

A SOFTBOARD é uma arquitetura dividida em seis componentes, sendo que cada um

possui uma responsabilidade bem definida dentro do sistema. São eles: Componente

Gerenciador de Cenários (CGC), Componente Interface Humano-Computador (CIH),

Componente Domínio do Problema (CDP), Componente Gerenciador de Dados (CGD),

Componente Interação Entre Sistemas (CIS) e o Componente Gerenciador de

Configuração de Sistema Orientado a Objetos (CMOOS), como esquematizado na

Figura 2.10.

Esta arquitetura é uma extensão do Modelo Multicomponentes proposto por Coad e

Yourdon (1993), pois sugere que cada componente pode ser configurado para atender

ao CDP de qualquer aplicação. Dessa forma, consegue-se uma reutilização total das

classes construídas para atender às responsabilidades do CIH, CIS, CGD e CGC.

61

Fig. 2.10 - SOFTBOARD. FONTE: adaptada de Cunha (1997, p. 72). O Componente Domínio do Problema (CDP) contém as classes da essência da

aplicação, que refletem os conceitos do domínio do problema e responsabilidades dentro

desse domínio. Para cada nova aplicação, um novo CDP deve ser modelado e

implementado e as informações necessárias para os demais componentes devem ser

armazenadas em um repositório de metadados, chamado de Catálogo. O CDP foi

detalhado no trabalho de pesquisa de Dias (1999).

O Componente Interface Humano-Computador (CIH) contém as classes necessárias

para o estabelecimento de uma interface de usuário para a aplicação. O CIH, além de

fornecer as classes para a composição da interface, deve permitir que a mesma seja

configurada de modo que:

1) seja apresentada segundo as características e habilidades de seus usuários;

2) possa ser modificada ou reorganizada para atender às necessidades

particulares de cada usuário. Esta configuração deve ficar retida para

posterior uso e deve ser realizada sem a presença do ambiente de

configuração original. Dessa forma, o usuário possui uma liberdade pessoal e

um certo controle sobre a interface, o que pode torná-lo mais eficiente na

CIH

CDP CDP

Outro Sistema

Catálogo

CMOOS

CIS

Banco de

Dados

CGD

CGC

62

realização de suas tarefas.

O Componente de Interação Entre Sistemas (CIS) contém as classes que possibilitam

que objetos do CDP interajam com objetos do CDP de outra aplicação, sendo que esses,

podem estar numa mesma máquina ou em máquinas distintas. Para isso, utilizam de

tecnologias disponíveis de comunicação e distribuição de objetos.

O Componente Gerenciador de Dados (CGD) contém as classes necessárias para o

armazenamento e a recuperação dos objetos persistentes da aplicação. Pode-se utilizar

três tecnologias de armazenamento: Arquivo, Banco de Dados Relacional ou Banco de

Dados Orientado a Objetos. O CGD foi detalhado no trabalho de pesquisa de Cottini

(1999).

O Componente Gerenciador de Cenários (CGC) contém as classes necessárias para

agrupar os objetos dos outros componentes, para instanciá-los e gerenciá-los,

disponibilizando assim, a funcionalidade da aplicação. Considera-se um cenário como

um conjunto de objetos que expressam, em um determinado momento ou circunstância,

um comportamento do sistema.

O Componente Gerenciador de Configuração de Sistema Orientado a Objetos

(CMOOS) é que permite dar à arquitetura a característica de configurável. O CMOOS

contém classes responsáveis pelo armazenamento e recuperação de um conjunto de

metadados, que são as informações de cada componente necessárias para fazer a

interface com o CDP. Portanto, para que se alcance uma aplicação completamente

funcional, baseada na arquitetura SOFTBOARD, os metadados de cada componente

devem estar armazenados no Catálogo.

O Catálogo é um subconjunto do Banco de Dados de Elementos Controlados

(BDEC). O BDEC também contém descrições e controla as versões de cada elemento

produzido ao longo do desenvolvimento do sistema, tais como classes, modelos e

documentos.

2.3.3 - Estratégia e Padrão

Outro ponto importante na busca pela melhoria da qualidade e da produtividade é a

utilização dos conceitos de Estratégias e Padrões. Esses conceitos expressam exemplos

63

de boa prática, aqueles que podem ser usados para ajudar desenvolvedores a alcançar

resultados mais efetivos (Coad et al., 1995).

Um padrão pode ser definido como um esquema ou molde a ser utilizado na construção

de algo. Apresenta-se como uma solução geral para um problema ou questão comum

(Coad et al., 1995; Gamma et al., 1995).

Segundo Martin (1998), padrões consistem em um meio para capturar bons princípios

de desenvolvimento. Eles podem ser úteis para os desenvolvedores que procuram

soluções potenciais para problemas particulares, assim como consistem de um meio

efetivo para comunicar problemas e soluções.

Uma estratégia é um plano de ação que descreve os passos a serem seguidos a fim de

se alcançar um objetivo específico (Coad et al., 1995). Por meio desse conceito é

possível especificar, de maneira bem definida, o que deve ser feito para atingir um

propósito.

A questão da eficiência sempre surge, desde que haja mais de um modo para se realizar

uma tarefa e, particularmente, quando se tem uma tarefa complexa. O conhecimento

desses modos alternativos e da maneira como escolher dentre eles, pode ser referido

como conhecimento estratégico (Cottini, 1999).

Em Coad e Yourdon (1992), como exemplo, são apresentados um conjunto de

estratégias para a localização de classes do domínio do problema (o que é, como

nomear, onde procurar, o que procurar, o que considerar e o que recusar), utilizando os

padrões de Transação, Agregação e Generalização-Especialização.

Uma implicação importante da utilização desses conceitos é a de que, por

documentarem soluções para problemas comuns encontrados durante o

desenvolvimento de sistemas de software, permitem a reutilização de esforços de

desenvolvimento e conseqüentemente, no aumento da produtividade das equipes e na

qualidade dos artefatos produzidos.

2.3.3.1 - Modelo para a Apresentação das Estratégias e Padrões

Neste trabalho, Estratégias e Padrões são utilizados para descrever um conjunto de

ações e diretrizes a serem seguidas para se desenvolver a interface humano-computador

64

do sistema de software baseados na arquitetura SOFTBOARD.

As estratégias são apresentadas da seguinte forma:

• um identificador da estratégia: para o Capítulo 3, consiste da letra M (modelagem),

de duas letras referentes ao modelo abordado e de uma numeração seqüencial

indicando a ordem em que a estratégia aparece no texto. Por exemplo, #MAM1

(estratégia número 1 do Modelo Ambiental). Para o Capítulo 4, consiste da letra A

(alimentação) seguida do componente da SOFTBOARD cujos metadados estão

sendo alimentados e da numeração seqüencial. Por exemplo, #ACIH1 (estratégia

número 1 para a alimentação dos metadados do CIH);

• um título: descreve o propósito da estratégia;

• um tópico de descrição: descreve o conteúdo da estratégia;

• um tópico de comentário: descreve algumas informações adicionais;

• um tópico de exemplo: descreve um ou mais exemplos que ilustram a aplicação da

estratégia.

Os padrões são apresentados da seguinte forma:

• um identificador do padrão: uma letra referente ao padrão e uma numeração

seqüencial. Por exemplo, #I1 (padrão de interação número 1);

• um título: descreve o padrão identificado;

• um tópico de descrição: representa o conteúdo do padrão.

65

CAPÍTULO 3

ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DA INTERFACE

HUMANO-COMPUTADOR DE SISTEMAS DE SOFTWARE BASEADOS EM

SOFTBOARD

Este capítulo trata da descrição das estratégias e dos padrões a serem utilizados para a

modelagem da interface humano-computador para os sistemas de software baseados na

arquitetura SOFTBOARD.

3.1 - Abordagem Inicial

O trabalho de Dias (1999) apresentou estratégias e padrões para a modelagem do

Componente Domínio do Problema da SOFTBOARD. Dias se preocupou com a

funcionalidade, ou seja, a característica que retrata as funções do sistema de software

que satisfazem as necessidades de um domínio específico.

Neste trabalho, apresentam-se estratégias e padrões para a modelagem da interface

humano-computador, cujos resultados permitem a configuração do CIH.

Contudo, o conhecimento necessário para o usuário adquirir competência para utilizar o

sistema, chamado por Norman (1986) de modelo conceitual do usuário, envolve tudo

aquilo o que se pode fazer – a funcionalidade – e as maneiras de como se pode interagir

– a interatividade. Portanto, no processo de interação usuário-sistema, ambas são

indissociáveis (Leite, 1998).

Dado o estreito relacionamento entre a funcionalidade e a interface, algumas estratégias

aqui propostas influenciam a modelagem do CDP (núcleo funcional), mas também se

utilizam, inevitavelmente, de seus resultados.

Deve-se observar que, em termos de arquitetura, pesquisas ressaltam a importância de

se ter o componente de software que implementa a funcionalidade independente do

componente de software que implementa a interface (Souza, 1997; Leite, 1998). Na

SOFTBOARD, esses componentes se referem, respectivamente, ao CDP e ao CIH.

3.2 - Modelagem do Sistema de Software

Conforme apresentado no Capítulo 2, o processo de desenvolvimento consiste em um

66

conjunto de atividades técnicas e gerenciais, cujo objetivo é transformar as necessidades

dos usuários em um sistema de software. Na execução dessas atividades, vários modelos

do sistema são construídos em níveis de abstração e aspectos relevantes distintos.

Partindo da Figura 2.8, a Figura 3.1 apresenta onde as estratégias aqui propostas

complementam os modelos dos sistemas de software baseados em SOFTBOARD. Nota-

se que, a modelagem da interface humano-computador (IH) acontece em paralelo à do

Componente Domínio do Problema. Acrescentando as estratégias para a modelagem

dos demais componentes, obtém-se os modelos completos para um sistema de software

baseado em SOFTBOARD.

Fig. 3.1 - Estratégias para a modelagem da interface humano-computador.

Modelagem da IH - envolver os usuários; - classificar os usuários;

...

Seção 3.2.2.2

Mundo real

Modelo de Negócio - representar os eventos

externos; - construir os casos de uso;

...

Modelo Operacional

- reutilizar classes de prateleira; - refinar relacionamentos;

...

- escolher os estilos de interação; - construir cenários;

...

Seção 3.2.3.2

Modelo Conceitual

Modelo Físico

- implementar as classes; - documentar as classes;

...

Modelagem do CDP - ouvir os especialistas; - construir um glossário

...

Sistema de Software

Processo

Modelo Comportamental

Modelo Ambiental

Modelo de lmplantação

Modelo de lmplementação

67

A Tabela 3.1 apresenta um resumo das estratégias para a modelagem da interface

humano-computador, alocadas segundo os modelos que ajudam a construir.

TABELA 3.1 - ESTRATÉGIAS PROPOSTAS

Modelo Estratégia

Modelo

Ambiental

#MAM1 - Envolver os usuários no desenvolvimento.

#MAM2 - Conhecer a comunidade de usuários.

#MAM3 - Conhecer as experiências dos usuários quanto ao uso de

computadores.

#MAM4 - Classificar os usuários.

#MAM5 - Construir a Especificação de Usabilidade.

Para a interação

#MIE1 - Escolher os estilos de interação.

#MIE2 - Minimizar a ocorrência e o efeito dos erros

humanos.

#MIE3 - Evitar construções antropomórficas.

#MIE4 - Organizar os menus.

#MIE5 - Considerar o projeto gráfico.

#MIE6 - Usar cores de forma cuidadosa.

#MIE7 - Considerar a eficiência na entrada de dados.

Para a

especificação

da interface

#MIE8 - Construir o cenário para a interface.

#MIE9 - Refinar as classes de fronteira.

#MIE10 -Documentar os objetos de interface.

Modelo de

Implementação

Para a avaliação

da interface

#MIE11 - Avaliar o cenário da interface.

#MIE12 - Construir modelos de usabilidade.

#MIE13 - Realizar ensaios de interação.

68

Dado que para os sistemas baseados em SOFTBOARD, somente o CDP é

implementado e os demais componentes são configurados, neste trabalho, doravante, o

responsável pela modelagem da interface humano-computador é chamado de

modelador, sendo a palavra desenvolvedor usada quando se referir ao responsável pela

modelagem do sistema como um todo.

Considerando também o relacionamento entre o CDP e a interface, antes de se

apresentar as estratégias propostas para modelagem desta última, descreve-se um

contexto da modelagem do CDP, depois, apresentam-se as informações do CDP

necessárias para a interface e finalmente, seguem as estratégias.

3.2.1 - Modelagem de Negócio

Fig. 3.2 - Construção do Modelo de Negócio.

3.2.1.1 - Contexto do Modelo de Negócio

A Modelagem de Negócio estabelece um modelo simplificado e útil dos processos de

negócio situados em um dado contexto e que devem ser apoiados por um sistema de

software. O contexto pode ser uma divisão, um conjunto relacionado de departamentos

ou até uma empresa inteira.

O Modelo de Negócio descreve importantes conceitos do contexto e estabelece as

competências requeridas para cada processo de negócio: os trabalhadores, suas

responsabilidades e as tarefas que executam.

Para obter essa descrição detalhada, o desenvolvedor precisa empregar várias técnicas

de coleta de dados (entrevistas, questionários, observação do ambiente de trabalho) e

Mundo

real

Modelo de Negócio

69

discutir intensamente seu entendimento. Dessa forma, o modelo permite que clientes,

usuários e desenvolvedores possuam a mesma compreensão sobre os processos de

negócio a serem apoiados pelo sistema de software.

Informações importantes do Modelo de Negócio para a IH

• Glossário com os termos e abreviações empregadas.

• Dados requeridos para iniciar e completar as tarefas.

• Dados gerados pelas tarefas.

• Seqüência e dependência entre as tarefas.

• Freqüência e importância das tarefas.

• Velocidade e precisão com as quais os responsáveis devem completar as tarefas.

3.2.2 - Modelagem Conceitual

Fig. 3.3 - Construção do Modelo Conceitual.

Durante o estudo do domínio de negócios, o desenvolvedor toma conhecimento de

muitas tarefas, regras, responsabilidades e recursos que existem dentro da organização.

Esse conhecimento é acompanhado de uma série de necessidades e desejos, tanto das

pessoas que executam as tarefas, quanto dos próprios gestores do negócio (proprietários

ou acionistas).

A Modelagem Conceitual define o que o sistema deve fazer para apoiar as tarefas dos

processos de negócio e satisfazer as necessidades identificadas. Esse modelo possui

Modelo de Negócio

Modelo Conceitual

Modelo Comportamental

Modelo Ambiental

Estratégias para a IH

70

duas partes principais: o Modelo Ambiental e o Modelo Comportamental.

3.2.2.1 - Contexto do Modelo Ambiental

O Modelo Ambiental define qual é o ambiente externo do sistema de software e quais

comportamentos serão usados ou observados por esse ambiente.

O modelo de casos de uso é usado aqui para especificar esses comportamentos, assim

como para representar o ambiente em que o sistema está inserido.

Um caso de uso é uma interação típica entre o ambiente e o sistema. Dessa forma,

importantes elementos da modelagem são as entidades que possuem interesse em

interagir com o sistema. Essas entidades podem ser (Eriksson e Penker, 1998; Jacobson

et al. 1999; Booch et al., 2000):

Atores humanos: quem usa as principais funções disponíveis, quem usa as funções

para fazer suas tarefas diárias, quem mantém ou administra o sistema, quem tem

interesse nos resultados produzidos pelo sistema.

Outros atores: dispositivos de hardware ou outros sistemas de software.

O conceito de ator refere-se a um papel que uma pessoa ou outro sistema desempenha

ao usar uma função disponível. Um mesmo usuário pode ter diferentes papéis,

dependendo da função que usa no momento.

Observa-se que a modelagem dos casos de uso é uma forma de colocar os usuários

como foco de interesse, uma vez que se procura especificar as funções que o sistema

deve ter para atender às necessidades de cada tipo de usuário identificado (Jacobson et

al., 1999).

Assim, para um Sistema Simplificado de Biblioteca que será usado para exemplificar a

aplicação das estratégias, têm-se os seguintes atores, entre outros:

• cliente da Biblioteca;

• bibliotecário;

• assistente;

• diretor.

71

E os seguintes casos de uso, entre outros:

• cadastrar acervo;

• consultar acervo;

• registrar empréstimo;

• consultar acervos emprestados por cliente.

A Figura 3.4 apresenta o diagrama de casos de uso para o exemplo. A notação para este

diagrama e para os demais usados neste Capítulo, encontra-se no Apêndice C.

Fig. 3.4 - Diagrama de casos de uso para o Sistema Simplificado de Biblioteca.

A modelagem dos casos de uso também é acompanhada da descrição das seqüências de

ações que o sistema pode executar ao interagir com os atores. Para cada caso de uso, é

preciso levantar as pré-condições, ou seja, as condições que devem estar satisfeitas ao

iniciar a sua execução. Em seguida, levanta-se o fluxo principal, que representa a

execução mais normal da função e os fluxos alternativos, que representam variantes que

são executadas sob certas condições. Deve-se definir, também, o estado final do

sistema, como pós-condição (Jacobson et al., 1999; Booch et al., 2000; Paula, 2001).

O exemplo a seguir descreve o caso de uso ‘Registrar empréstimo’:

Pré-condição:

Cliente da Biblioteca

Sistema Simplificado de Biblioteca

Bibliotecário

Consultar acervo mais emprestado por cliente

Assistente da Biblioteca Diretor

Cadastrar acervo

Consultar acervo

Registrar empréstimo

72

O Cliente da Biblioteca se identificou ao sistema.

Fluxo principal de eventos

1) O sistema notificado sobre o cliente e o exemplar verifica se o título está

reservado e se o usuário está na lista de reservas.

2) O sistema obtém o número de empréstimos já realizados pelo cliente.

3) O sistema calcula a data de entrega do exemplar, baseada nos dias úteis.

4) O sistema verifica a ocorrência de atrasos na devolução e notifica o

assistente.

5) O assistente tem à sua disposição informações importantes para a condução

do empréstimo.

6) O assistente confirma a realização do empréstimo.

Fluxo de eventos alternativos

No passo 2, o cliente é informado sobre a indisponibilidade.

No passo 3, o cliente é informado sobre o limite atingido e o assistente cancela o

empréstimo.

Pós-condição:

O registro do cliente é eliminado da lista de reservas para o título (se for pertinente).

Caso o título esteja indisponível, o sistema notifica ao assistente a possível data de

disponibilidade e lança o cliente na lista de reservas para o título.

Informações importantes do Modelo de Casos de Uso para a IH

• Descrição dos casos de uso.

Os fluxos de eventos dos casos de uso são entradas importantes para a modelagem da

IH. Contudo, é necessário evitar em sua descrição, decisões implícitas sobre a interface,

como mencionar sobre dispositivos de entrada/saída, dispositivos virtuais (caixas de

texto, botões, etc.), seqüência de entradas, entre outros.

O desenvolvedor deve descrever as ações do usuário e do sistema, sem suposições

73

prematuras de detalhes da interface. Dessa maneira, essa descrição é mais apropriada

para mudança de tecnologia, pois modelam as tarefas de forma mais próxima à natureza

do problema (Constantine e Lockwood, 1999).

O exemplo da descrição do caso de uso ‘Registrar empréstimo’ foi realizado sem

envolver qualquer decisão sobre a interface. O modelador está independente para

escolher a melhor interface para os usuários.

• Seqüência entre os casos de uso.

É importante atentar para a seqüência em que os casos de uso tendem a ser usados. O

bom entendimento desse fluxo influi na modelagem da interface, na forma em que

minimiza a entrada de dados redundantes, assim como evita a interrupção da tarefa pela

falta de informações. A pré e pós-condição dos casos de uso podem oferecer um meio

de expressar tal seqüência (Constantine e Lockwood, 1999).

• Freqüência de execução de cada caso de uso em um espaço de tempo.

Casos de uso freqüentemente executados devem ser simples e rápidos em seu acesso. A

informação da freqüência deve ser proveniente da tarefa (Modelo de Negócio) que o

caso de uso suporta ou automatiza.

TABELA 3.2 - FREQÜÊNCIA DE EXECUÇÃO DOS CASOS DE USO POR ATOR

Casos de uso

Ator humano Registrar reserva


Registrar devolução

Consultar usuários em atraso

Assistente da Biblioteca Baixa Alta Alta Média

Casos de uso

Ator humano Cadastrar acervo

Cadastrar Editora

Listar acervo por Título

Listar acervo por número de tombo

Bibliotecário Alta Média Baixa Baixa

74

Apresentado o contexto e as informações necessárias do CDP para a interface, a seguir,

descrevem-se as estratégias para a modelagem da interface.

3.2.2.2 - Estratégias para Modelagem da IH

Estratégia #MAM1. Envolver os usuários no desenvolvimento

Descrição

Envolver os usuários no desenvolvimento é a forma mais segura de garantir que o

sistema de software atenda às suas necessidades e que, assim, por eles seja aceito. Esse

envolvimento deve ocorrer o mais cedo possível, pois à medida que o desenvolvimento

evolui, as alterações são mais onerosas.

Os níveis de envolvimento possíveis são (LabIUtil, 2000):

• informativo: busca-se do usuário as informações necessárias para o

desenvolvimento do sistema, por meio de técnicas de entrevistas, questionários ou

de sua observação no trabalho;

• consultivo: os modelos e as decisões tomadas pela equipe de desenvolvimento são

apresentadas ao usuário para que ele as verifique e emita sua opinião;

• participativo: é o nível mais elevado de envolvimento e ocorre quando a equipe de

desenvolvimento e os usuários, juntos, tomam decisões. Aqui é empregada a técnica

de “brainstorming”, na qual os usuários manifestam sua perspectiva sobre

determinados aspectos do sistema, como, a organização modular ou o vocabulário

apresentado na interface. Cabe à equipe de desenvolvimento planejar e realizar essas

atividades, recolher e tratar adequadamente seus resultados. Neste nível, o enfoque é

desenvolver com ao invés de desenvolver para.

Comentário

É importante que o envolvimento do usuário ocorra nos diferentes níveis. Deve-se

buscar informações junto ao usuário, consultá-lo e passar a ele o poder de tomar

determinadas decisões, embora este último, exija uma certa mudança organizacional e

cultural da organização (LabIUtil, 2000).

Embora esta estratégia esteja dentro da modelagem da interface, entende-se que ela é

75

extremamente necessária para a modelagem do CDP, o que justifica o seu título.

Estratégia #MAM2. Conhecer a comunidade de usuários

O usuário deve ser sempre o foco principal de interesse do modelador ao longo da

modelagem da interface. O objetivo desta estratégia é, a partir dos atores humanos

presentes no modelo de casos de uso, identificar os usuários e conhecer as suas

características e experiências. Para isso, sugere-se obter as seguintes informações

(Souza et al., 1999):

• principais papéis e tarefas realizadas dentro de cada papel;

• nível de conhecimento do domínio do problema: um usuário que não tem

conhecimento prévio do domínio do problema é considerado novato, enquanto que

aquele que conhece não apenas o domínio, mas também diferentes maneiras de

realizar as tarefas é considerado experiente;

• contexto sócio-cultural: visa identificar as diferenças sócio-culturais entre os

usuários, tais como línguas, dialetos e tradições culturais. É importante para

sistemas que serão distribuídos em diversos países ou em diversas regiões de um

mesmo país. São os casos de aplicações de uso geral e para organizações

multinacionais;

• características: formação educacional, gostos particulares e necessidades especiais.

Estratégia #MAM3. Conhecer as experiências dos usuários quanto ao uso de

computadores

Descrição

Nesta etapa, procura-se conhecer as experiências do usuário quanto ao uso de

computadores. Pode-se obter as seguintes informações:

• familiaridade com os computadores: habilidade no uso de dispositivos de entrada,

por exemplo, mouse e teclado. Os valores extremos são novato e experiente;

• experiências com sistemas de software como sistemas operacionais, editores de

texto, planilhas e demais aplicações;

76

• freqüência, intensidade e obrigatoriedade quanto ao uso do computador;

• tipo de treinamento em Informática já recebido;

• experiência no uso de recursos oferecidos, tais como tutoriais, manuais, macros

(armazenamento de uma seqüência de comandos, ativados por um nome definido

pelo usuário) e teclas aceleradoras para as funções.

Comentário

As experiências com outras aplicações, bem como os treinamentos já recebidos podem

auxiliar na definição do sistema operacional, estilos de interação e na obtenção de

consistência entre as aplicações.

Exemplo

O questionário apresentado a seguir (Figura 3.5) ilustra algumas questões que podem

ser usadas para aquisição de informações sobre o usuário. Este exemplo abrange as

estratégias #MAM2 e #MAM3.

77

Fig. 3.5 - Exemplo de questões aplicadas para o conhecimento do usuário. FONTE: adaptado de Constantine e Lockwood (1999).

Estratégia #MAM4. Classificar os usuários

Descrição

Ao apurar os resultados dos questionários e das entrevistas pode vir à tona uma grande

variedade de características e experiências entre os usuários. Shneiderman (1998)

sugere classificá-los da seguinte maneira:

• usuários novatos: são aqueles que possuem pouco conhecimento de suas tarefas,

assim como dos conceitos de computação;

• usuários de primeira vez: são aqueles que conhecem as suas tarefas, mas possuem

poucos conhecimentos de computação;

Identificador: Nome: Papel Principal: Responsabilidades gerais: Conhecimentos gerais (formação e treinamentos): _desconhecido _não aplicável Conhecimento do domínio: _desconhecido _não aplicável _baixa _média _alta Proficiência em Informática: _desconhecido _não aplicável _baixa _média _alta Interação com o computador: _desconhecido _não aplicável

Freqüência de uso: _baixa _média _alta _específica: ____ Intensidade de uso: _baixa _média _alta _específica: ____ Obrigatoriedade do uso: _requerido _opcional Perfil da informação: _ desconhecido _não aplicável

Fluxo predominante: _do usuário _para o usuário _balanceado Origem: _papel _telefone _raciocínio _outros: ____ Volume de troca: _baixa _média _alta _específica: ____ Suporte para a interação (necessidades especiais e facilidades): _desconhecido _não aplicável Critérios para a interação: _desconhecido _não aplicável

_ eficiência _ aprendizado _recordação _ satisfação _flexibilidade _tolerância a erros _outros:___

78

• usuários experientes ocasionais: são aqueles que conhecem bem suas tarefas e os

conceitos de computação, porém usarão a aplicação (e usam os demais sistemas) de

forma ocasional;

• usuários experientes freqüentes: são aqueles que conhecem bem suas tarefas e os

conceitos de computação e usarão a aplicação de forma freqüente.

Comentário

A classificação acima pode ser refinada, conforme as necessidades do domínio do

problema. Deve-se atentar para o fato de que o usuário novato tende a adquirir

experiência, enquanto que, o que é ocasional não melhora suas capacidades com a

aplicação ao longo do tempo e pode até diminuí-las (Souza et al., 1999). Sobe pena de

sua validade, a classificação deve ser sempre “inspecionada” pelo usuário e deve

trabalhar sobre seu controle.

Após a classificação, deve-se fazer um levantamento para descobrir quais são as classes

de usuários majoritárias.

Exemplo

A interface a seguir (Figura 3.6) foi modelada para que o usuário faça uma cópia de

arquivo, fornecendo as informações corretamente.

Fig. 3.6 - Exemplo de interação. FONTE: adaptada de Bodker (1991, p. 84).

Esta seqüência ajuda os novatos a entender as regras de interação e concluir sua tarefa

de forma eficaz. Porém, para os usuários experientes é uma maneira bastante restritiva e

lenta. Além das entradas seguirem uma ordem rigorosa, muitos toques são necessários.

Uma solução seria permitir ao usuário escolher entre diferentes formas de comando,

79

assim como mudar a sua escolha quando possuir mais experiência.

Estratégia #MAM5. Construir a Especificação de Usabilidade

Descrição

Consiste em definir os atributos de usabilidade (características que podem ser medidas

por alguma técnica que gere dados quantitativos); decidir quais são os instrumentos de

medida e quais valores devem ser obtidos; definir o nível de desempenho (mínimo,

almejado e ótimo) para cada atributo.

As metas de usabilidade, formadas pelo atributo mais o nível de desempenho almejado,

devem ser escolhidas analisando:

• as classes de usuários identificadas: pode ser importante estabelecer os atributos

com diferentes instrumentos de medida e/ou níveis de desempenho. Por exemplo,

facilidade de aprendizado para os usuários novatos; e retenção após o uso, para os

usuários ocasionais. Neste caso, uma coluna chamada “Classe de usuário” deve ser

adicionada à tabela;

• o contexto (ambiente de trabalho) onde o sistema deve operar, como, a tolerância a

erros, a rotatividade de empregados, o volume de transações executadas, o custo de

treinamento, entre outros dados que podem ser obtidos com a modelagem de

negócio.

Para se estabelecer os instrumentos de medida é importante procurar pelas tarefas que

são mais representativas para os usuários. Por exemplo, as mais freqüentes; as que

possuem maior grau de complexidade; as que são raramente usadas, porém produzem

resultados críticos para o negócio; as que estão sendo revisadas; entre outras.

Quanto ao número de atributos, um bom começo para um modelador não experiente, é

especificar três atributos de usabilidade, sendo dois com instrumentos de medida

objetivos e um com instrumento de medida subjetivo. Depois, gradualmente, novos

atributos podem ser colocados na tabela (Hix e Hartson, 1993).

Exemplo

A seguir uma tabela com a Especificação de Usabilidade para o Sistema Simplificado

80

de Biblioteca.

O contexto de operação do sistema é uma Biblioteca de uma instituição de ensino.

Contudo, seu acervo está aberto para toda a comunidade. Dado que o principal motivo

que leva a comunidade à Biblioteca é a pesquisa, um dos objetivos principais do sistema

é disponibilizar a consulta pública ao acervo. O levantamento das características e das

experiências dos potenciais usuários identificou a classe Usuário Novato como a

majoritária. Diante desse panorama, foram definidos os seguintes atributos para explorar

a usabilidade do sistema:

• desempenho inicial (primeiro uso do sistema): o nível de desempenho esperado é a

ausência de erros na consulta ao acervo. Caso aconteçam muitos erros, isso pode

provocar a desistência do uso do sistema e, conseqüentemente, levar à busca por

fichas impressas ou à consulta ao funcionário do balcão;

• retenção após o uso: dado que a freqüência de uso varia de ocasional a freqüente,

procura-se descobrir se o conhecimento de como realizar a consulta ficou mantido;

• satisfação: um questionário com questões sobre as restrições ao uso do sistema e

sobre a preferência em relação às fichas impressas.

TABELA 3.3 - ESPECIFICAÇÃO DE USABILIDADE

Atributo Instrumento de medida

Valor a ser medido

Nível atual

Nível mínimo

Nível almejado

Melhor nível

Desempenho inicial

Consulta ao acervo

Número de erros cometidos

-

3

0

0

Retenção após uso

Acesso ao sistema de ajuda

Número de acessos ao sistema de ajuda em cada janela.

-

2

0

0

Satisfação do usuário

Questionário Média de pontos - Neutro Positivo Muito positivo

Continuando a modelagem conceitual, apresenta-se o contexto da modelagem

comportamental do CDP e as informações importantes para a IH.

81

3.2.2.3 - Contexto do Modelo Comportamental

O Modelo Comportamental é a parte do Modelo Conceitual que descreve o

comportamento do interior do sistema, necessário para interagir com o seu ambiente

externo.

Quando os atores interagem com sistema, eles manipulam conceitos que representam

aquilo que eles conhecem no mundo real como objetos concretos (por exemplo, um

livro), descritivos (por exemplo, o acervo), eventos lembrados (por exemplo, um

empréstimo) ou lugares (por exemplo, a Biblioteca).

Estudando as descrições dos casos de uso e o domínio do problema, o desenvolvedor

abstrai tais objetos e os classifica. Uma classe representa, então, um conjunto de objetos

que são reconhecidos como sendo do mesmo tipo, pois compartilham as mesmas

características, comportamentos e relacionamentos (Rumbaugh et al., 1991; Coad e

Yourdon, 1992; Booch, 1994; Furlan, 1998).

A Figura 3.7 mostra um diagrama de classes para o caso de uso ‘Registrar Empréstimo’

do Sistema Simplificado de Biblioteca.

Fig. 3.7 - Diagrama de classes para um Sistema Simplificado de Biblioteca.

Periódico Nome Número Mês_PublicaçãoVolume

Acervo

Número_Empréstimo

Registro Número_Reserva

11

0..*

Exemplar Número Ano_Publicação Situação

LivroISBNTítulo

Edição

Autor

1

1..*

Reserva Data_Reserva

1 1

1..*

Pessoa Nome Endereço Telefones

Biblioteca Nome

1 1..*1..*

Item_EmpréstimoData_Devolução

1

0..*

Cliente_Biblioteca Registro

1

0..*

1

0..*

0..1 1

1..* 1

EmpréstimoData_Empréstimo

1

1..*

1

1..*

1 0..*0..*

Possui Pertence

Possui

Pertence

Podefazer

Feito por

Pode ser

É uma

Pode fazer

É feito por

ContémPossui

Pertence

Participa

Participa

Contém

Data_Último_Empréstimo

Item_Reserva Data_Disponibilidade

82

Uma colaboração nomeia uma sociedade de classes e outros elementos que trabalham

juntos para fornecer um comportamento cooperativo maior que a soma de todas as suas

partes. Elas são empregadas para especificar a realização dos casos de uso (Booch et

al., 2000).

Essa realização acontece em termos de classes, objetos e seus relacionamentos

(chamado de contexto da colaboração ou parte estrutural) e de um conjunto de

mensagens trocadas entre objetos para obter a função desejada (chamada de interação da

colaboração ou parte comportamental) (Eriksson e Penker, 1998; Booch et al., 2000).

A seguir, um diagrama de colaboração mostra as interações necessárias para a

realização do caso de uso ‘Registrar Empréstimo’ (Figura 3.8).

Fig. 3.8 - Diagrama de colaboração para um Sistema Simplificado de Biblioteca.

As classes de Entidade (estereótipo Entity) modelam conceitos do domínio,

reconhecidos como organismos sociais, lugares, coisas e eventos. As classes de fronteira

(estereótipo Boundary) são usadas para modelar a interface entre um ator (humano,

sistemas de software ou dispositivos de hardware) e o sistema.

<<Boundary>> :EmpréstimoIH

<<Entity>> :Reserva

<<Entity>> :Empréstimo

: Assistente <<Entity>> :Exemplar

5:Obter número de empr. 6:Verificar atrasos 8: Adicionar 3:Obter

<<Entity>> :Acervo

:Cliente da Biblioteca

1:Registro do usuário e exemplar

7:Obter

2:Obter

4:Verificar lista

83

Informações importantes sobre as colaborações para a IH

Guiado pelos passos do caso de uso e pela sua realização, o modelador precisa discernir

o que é necessário estar nas classes de fronteira para capacitar cada ator a usar um caso

de uso. Deve-se tentar identificar:

• quais informações o ator precisa fornecer;

• quais informações o ator precisa receber;

• quando elas são necessárias;

• quais ações o ator pode realizar;

• que ações e informações são opcionais.

Um modo de apresentar o conteúdo da classe de fronteira é usar o mecanismo de notas

da UML, conforme ilustra a Figura 3.9.

Fig. 3.9 - Notas com o conteúdo de uma classe de fronteira.

<<Boundary>>:EmpréstimoIH

Cliente da Biblioteca♦ Nome. ♦ Registro. ♦ Fotografia.

Acervo ♦ Título. ♦ Autor (es).

Empréstimo ♦ Data da devolução. ♦ Dias em atraso. ♦ Total de empréstimos.

Exemplar ♦ Registro

84

3.2.3 - Modelagem Operacional

Fig. 3.10 - Construção do Modelo Operacional.

A Modelagem Operacional indica como o sistema é construído e implantado, face às

tecnologias disponíveis. Esse modelo possui duas partes principais: o Modelo de

Implementação e o Modelo de Implantação.

3.2.3.1 - Contexto do Modelo de Implementação

O Modelo de Implementação refina o Modelo Conceitual adicionando estruturas e

comportamentos necessários para a implementação.

Para os sistemas de software baseados em SOFTBOARD, esse modelo consiste no

refinamento das classes do CDP e na configuração dos demais componentes (após a

modelagem de cada um).

3.2.3.2 - Estratégias para a Modelagem da IH

Para a melhor apresentação das estratégias, as mesmas foram divididas em:

• estratégias para a interação: refere-se à construção da forma geral da interface, como

o usuário interage com o sistema, como as funções devem ser organizadas, como a

interface suporta as diferentes classes de usuário, etc.;

• estratégias para especificação: refere-se à integração do modelo de interação

(construído com as estratégias de interação) ao modelo funcional (construídas com

as estratégias do CDP). Esta especificação estabelece como o CIH deve ser

configurado;

Modelo

Conceitual

Estratégias para a IH

Modelo Operacional Modelo de

ImplantaçãoModelo de

Implementação

85

• estratégias para avaliação: refere-se à avaliação da qualidade da interação usuário-

sistema que a interface propicia.

Padrões de interação para classes de usuários

Conforme visto no capítulo 2, um padrão pode ser definido como um esquema ou

molde a ser utilizado na construção de algo. Padrões ajudam a criar uma linguagem

compartilhada para a comunicação da percepção e experiência sobre problemas e

soluções.

Na literatura de IHC, muitas obras (Preece et al., 1994; Shneiderman, 1998; Souza et al.,

1999) fornecem diretrizes para composição da interface, considerando as características

de cada classe de usuário.

Essas diretrizes, neste trabalho, são consideradas como padrões de interação, sendo

apresentadas a seguir.

Padrão #I1. Usuários novatos e de primeira vez

Descrição

Os membros dessas duas classes tendem a apresentar certa ansiedade quanto ao uso de

computadores, o que geralmente prejudica o aprendizado da aplicação.

Para dar confiança e diminuir as dificuldades desses usuários, o modelador pode seguir

as seguintes diretrizes:

• restringir o vocabulário a um pequeno número de termos familiares e consistentes;

• usar menus para ajudá-los na tomada de decisão;

• colocar um pequeno número de opções de forma a permitir que eles possam

executar tarefas simples, porém de maneira eficaz;

• a cada tarefa escolhida, indicar seu progresso e sinalizar o seu término;

• fornecer várias formas de ajuda e instruções detalhadas. A documentação do usuário

pode constar de tutoriais demonstrativos, manuais e sistemas de ajuda.

86

Padrão #I2. Usuários experientes ocasionais

Descrição

Muitas pessoas são experientes no uso de computadores, porém por utilizar uma grande

variedade de aplicações, tendem a apresentar dificuldades para reter as estruturas de

menus, a localização de determinados recursos ou a sintaxe de um comando.

Para diminuir as dificuldades desses usuários, o modelador pode seguir as seguintes

diretrizes:

• favorecer a exploração de recursos ou tentativas de invocar seqüências de ações

parcialmente esquecidas, até um ponto que não prejudique a integridade da

aplicação;

• usar menus para ajudá-los as reconhecer opções;

• procurar estabelecer consistência entre as aplicações;

• colocar textos a interface que permitem relembrar os comandos;

• fornecer sistemas de ajuda e manuais.

Padrão #I3. Usuários experientes freqüentes

Descrição

Os membros dessa classe desejam fazer seu trabalho de forma eficiente e eficaz.

Geralmente, esperam por respostas rápidas do sistema, mensagens de retorno breves e

capacidade de executar ações por meio de poucas seleções.

Para essa classe de usuários, o modelador pode seguir as seguintes diretrizes:

• colocar acesso rápido para as funções mais usadas, por exemplo, botões que as

disparam na barra de ferramentas e teclas aceleradoras;

• criar uma interface flexível que permita ao usuário acrescentar funções, por

exemplo, a colocação de macros;

• permitir a alteração da interface inicial da aplicação, de forma que o usuário possa

ajustá-la às suas necessidades de uso.

87

Estratégias para a interação

Estratégia #MIE1. Escolher os estilos de interação

Descrição

Consiste em identificar os estilos de interação mais apropriados para a cada classe de

usuário identificada. Para isto, duas importantes entradas devem ser consideradas:

• os resultados obtidos quando da aplicação da estratégia #MAM3 (Conhecer as

experiências dos usuários quanto ao uso de computadores). Essa estratégia pode

revelar os tipos de treinamento recebidos e os estilos de interação mais conhecidos

pelos usuários;

• os fatores favoráveis e desfavoráveis de cada estilo de interação, conforme

apresentado na Tabela 2.1.

Comentário

Pelo fato do CIH da SOFTBOARD usar uma interface gráfica baseada em WIMP, o

modelador pode utilizar de menus, preenchimento de formulário e manipulação direta

como estilos de interação.

Estratégia #MIE2. Minimizar a ocorrência e o efeito dos erros humanos

Descrição

Segundo Norman (1988), o modelador deve assumir que todas as possibilidades de erro

irão acontecer e modelar para minimizar suas chances, em primeiro lugar, ou seu efeito

quando ocorrer. Erros devem ser fáceis de detectar, devem ter mínimas conseqüências e,

se possível, devem ser reversíveis.

Minimização de erros

Conhecer a comunidade de usuários, organizar os menus e formulários adequadamente,

reduzir a necessidade de memorização, manter a consistência entre e dentro da

aplicação são estratégias que ajudam a evitar o erro humano.

Outro caso que evita a sua ocorrência é reconhecer a capacidade humana de fazer

múltiplas atividades em um mesmo período. Enquanto os usuários lidam com muitas

88

atividades, limitações na memória e influências do ambiente podem levá-los a cometer

erros. Para tal característica, a interface pode ser modelada de forma a (Prabhu e

Prabhu, 1997):

• lembrar o usuário sobre alguma tarefa que precisa ser feita imediatamente;

• fornecer uma lista com as tarefas que estão em execução ou suspensas;

• apresentar o estado anterior da tarefa, quando a mesma foi interrompida, para que

seja possível continuar a partir dele;

• permitir a interrupção de uma tarefa, quando desejado e possível.

Detecção

Quando o sistema não for capaz de interpretar uma ação do usuário, existem seis tipos

de respostas possíveis que a interface pode prover:

• não disponibilizar para uso, o elemento da interface que dispara a ação;

• interromper (evitar que o usuário continue);

• avisar com mensagens ou sinais sonoros;

• fazer a auto-correção;

• iniciar um diálogo para a resolução cooperativa usuário-sistema;

• pedir por um esclarecimento.

Recuperação

As mensagens que notificam o erro são um dos meios mais importantes de comunicação

entre o usuário e o sistema. Elas são úteis não somente quando contam ao usuário sobre

o que está errado, mas também quando o informa sobre como agir corretamente. Uma

mensagem apropriada ajuda o usuário a aprender, reduzindo suas chances de cometer o

erro novamente (Prabhu e Prabhu, 1997). Desta maneira, a mensagem precisa:

• fornecer informações suficientes e específicas do que está errado, evitando

sentenças genéricas do tipo: ‘dado inválido’ ou ‘opção incorreta’. Optar por

conceitos conhecidos pelos usuários.

89

• indicar as conseqüências negativas do erro, por exemplo, os arquivos de dados

adulterados, de tal forma que o usuário possa verificar se elas realmente

aconteceram;

• fornecer maneiras para a correção;

• não caracterizar uma condenação ou julgamento, evitando o uso de palavras como

fatal, inválido, ilegal e errado;

• permitir o acesso a informações mais detalhadas ou outros tópicos relacionados

(sistemas de ajuda).

Comentário

Adotar contadores de erros internos no sistema permite descobrir quais funcionalidades

apresentam algum tipo de dificuldade para os usuários. Este levantamento, bem como os

diversos tipos de avaliação, ajudam a melhorar as mensagens, priorizar treinamentos e

modificar as documentações que acompanham o sistema (Shneiderman, 1998).

Exemplo

Mensagens mal construídas: Dado inválido.

Entrada ilegal.

Mensagens bem construídas: A temperatura deve variar entre 0o e 25o Celsius.

Escolha entre as letras S para sair ou C para continuar.

Estratégia #MIE3. Evitar construções antropomórficas

Descrição

Não se deve colocar na interface referências que apresentam o computador com

propriedades humanas. As razões para tal procedimento são (Shneiderman, 1998):

• a sugestão de que um computador pode pensar ou entender, fornece aos usuários um

modelo enganoso de como esta máquina trabalha e de sua capacidade;

• o relacionamento entre pessoas é diferente do relacionamento com computadores.

Enquanto o primeiro deve respeitar a identidade e a autonomia do indivíduo, o

segundo acontece por meio de operação e controle.

90

Portanto, deve-se evitar construir interfaces que apresentam frases com pronomes na

primeira pessoa ou que transmitam noções de amizade, inteligência ou felicidade.

Exemplo

Construções ruins: Eu sou um computador. Você está pronto para começar?

Eu iniciarei a lição quando você pressionar a tecla <Enter>.

Boas construções: Este é um exercício de múltipla escolha.

Para começar a lição, pressione a tecla <Enter>.

Uma boa construção reduz o número de pronomes e palavras, sendo a mais adequada

para informar o usuário sobre a próxima ação a ser realizada.

Estratégia #MIE4. Organizar os menus

Descrição

Uma vez escolhido um estilo de interação por menus, deve-se preocupar em construí-los

adequadamente. Quando os itens do menu estão escritos com uma terminologia familiar

e organizados de uma maneira conveniente, os usuários podem trabalhar de modo mais

eficiente.

Organização

Uma técnica simples para organizar as funcionalidades previstas para o sistema consiste

em um “jogo de cartas”. Nele, cada carta, disposta aleatoriamente sobre uma mesa,

descreve uma futura funcionalidade. É solicitado aos usuários que organizem as cartas

da maneira mais lógica que lhes parecer, assim como dar nomes aos grupos formados.

Neste sentido, é uma técnica também útil para a coleta e formação do vocabulário

operativo do sistema (LabIUtil, 2000).

Os grupos de funcionalidades formados, bem como os vocabulários usados para nomeá-

los, ajudam a compor a hierarquia dos menus e nomear seus itens.

Profundidade x Largura

A profundidade ou o número de níveis de um menu depende, em parte, da largura ou

número de itens por nível. Se mais itens são colocados em um nível, provavelmente,

91

menos níveis serão necessários. Vários estudos obtiveram fortes evidências de que a

largura deve ser preferida, em detrimento da profundidade. De fato, a razão para isso é a

de que, quando a profundidade passa de três níveis, existe uma boa chance dos usuários

perderem o senso de posição dentro da hierarquia e se sentirem desorientados

(Shneiderman, 1998).

Seqüência de apresentação

Uma vez que os itens do menu tenham sido escolhidos, é preciso definir a ordem em

que serão apresentados. Algumas bases para seqüencialização são:

• freqüência de uso: tal informação pode ser obtida observando a Tabela 3.2 -

Freqüência de execução dos casos de uso por ator, conforme visto na Modelagem

Ambiental;

• seqüência de uso: tal informação pode ser obtida observando a descrição das pré e

pós condições dos casos de uso, conforme visto no Modelagem Ambiental;

• ordem cronológica;

• ordem alfabética;

• propriedades físicas ( a partir de um aumento ou diminuição da área, temperatura,

peso, velocidade, etc.)

Comentário

Quando se seqüencializa pela freqüência de uso, os itens são colocados em uma ordem

descendente de freqüência. Essa organização acelera a seleção dos itens mais usados,

mas pode atrapalhar uma outra ordem que poderia existir. O que pode ser feito é colocar

três ou quatro itens precedentes e depois preservar a ordem dos itens restantes.

Exemplo

Na Figura 3.11, os itens iniciais estão dispostos segundo a freqüência de uso e os

demais estão em ordem alfabética.

92

Fig. 3.11 - Exemplo para a seqüencialização de itens de menu.

Estratégia #MIE5. Considerar o projeto gráfico

Descrição

Uma vez que a maior parte da interação é realizada pelo meio visual, é importante

considerar o projeto gráfico da interface, propondo uma diagramação equilibrada no que

se refere à distribuição das áreas livres, evitando ao máximo problemas de alinhamento

e diferenciando claramente as diferentes zonas funcionais. Tais cuidados melhoram a

capacidade do usuário de encontrar e interpretar informações (Tullis, 1997).

A seguir são apresentados alguns resultados compilados a partir de trabalhos de Marcus

(1997), Tullis (1997) e LabIUtil (2000).

Densidade e alinhamento

• Quantidade de informação: deve-se garantir que cada tela contenha somente as

informações realmente necessárias para o usuário, naquele ponto de interação. Toda

informação adicional compete com a informação importante e diminui a sua

visibilidade. Informações de uso esporádico devem ser apresentadas sob pedido.

• Uso de abreviações: embora seja preferido usar as palavras completas, também se

reconhece que abreviações são apropriadas nos casos em que existe necessidade de

espaço. Quando usadas, contudo, é preciso que uma lista com os significados das

abreviações e siglas do vocabulário do domínio e de informática (se pertinente)

esteja disponível para consulta. Veja exemplo na Figura 3.12.

• Instruções de preenchimento: devem descrever somente as ações necessárias (como

93

‘Digite o endereço:’ ou simplesmente ‘Endereço:’ ), evitando pronomes (como

‘Você deve digitar o endereço.’) ou referências ao usuário (‘O usuário do formulário

deve digitar o endereço.’).

• Formato tabular: sugere-se que os itens relacionados sejam dispostos em colunas

como forma de melhorar o tempo de localização de um determinado item. Mais

especificamente, colunas de itens alfanuméricos devem ser ajustados à esquerda

(uma vez que é mais fácil localizar o início de cada item, considerando a cultura

ocidental). Colunas de itens numéricos devem ser ajustados à direita (alinhados no

seu ponto decimal), mostrando de forma mais clara a magnitude de seus valores.

• Lista de seleção: o comprimento recomendado de uma lista deve permitir a

visualização imediata de apenas 7 (+- 2) itens. O modelador deve ativar mecanismos

de navegação interna (como barras de rolagem) quando o número de escolhas

possíveis se tornar elevado. O limite máximo é algo de como 50 itens que devem

estar seqüencializados. Separadores devem ser empregados para marcar a

organização dos itens em grupos lógicos.

• Listas de seleção desdobráveis: no caso de restrições de espaço as listas podem ser

configuradas como desdobráveis. Dessa forma, somente o primeiro item da lista é

apresentado, inicialmente. Para visualizar as outras alternativas o usuário deve

acionar o botão de desdobramento que irá apresentar o restante da lista, para baixo

ou para cima, no primeiro plano da tela.

Agrupamento

• Limites gráficos: além da proximidade espacial, a técnica mais comum usada para

mostrar agrupamentos visuais é aplicar limites gráficos em volta dos elementos.

Geralmente, tais limites são apresentados em forma retangular, conforme ilustrado

na Figura 3.13.

• Cores: apresentar diferentes conjuntos de elementos, em cores contrastantes,

claramente, cria algum grau de agrupamento entre os elementos de mesma cor.

94

Relacionamento espacial

• Indentação: a representação hierárquica entre itens e subitens pode ser mostrada,

eficientemente, pelo uso de indentações.

• Relacionamento entre rótulos e campos: os campos devem estar adequadamente

identificados, sendo que seus rótulos devem ser colocados acima ou à esquerda,

visualmente diferenciados. O alinhamento entre os rótulos deve ser feito pela

esquerda ou à direita (quando apresentarem comprimentos muito diferentes).

• Botões de comando: alinhados verticalmente e à direita do elemento a que fazem

referência, ou horizontalmente e abaixo deste. O botão que indica a escolha padrão

deve ser visualmente diferenciado e posicionado ao alto, se a orientação for vertical,

ou à esquerda, no caso de uma orientação horizontal.

• Simetria: propõe que o relacionamento espacial entre os elementos na tela deva

fornecer algum grau de balanço simétrico. Por exemplo, a simetria pode ser obtida a

partir da centralização dos grupos, mantendo-se um espaçamento igual em cada

lado, conforme ilustrado na Figura 3.13.

Apresentação de textos

• Palavras em maiúsculo: deve-se preferir sempre escrever as palavras em uma grafia

normal (somente as iniciais em maiúsculas). Entretanto, nos casos em que se deseja

atrair a atenção dos usuários, letras maiúsculas podem ser usadas.

• Fonte: as características envolvidas com a percepção das fontes empregadas nos

textos são a serifa e o tamanho usado. A serifa é caracterizada por uma terminação

saliente dos caracteres, conforme ilustrada na primeira letra da Figura 3.14. Fontes

sem serifa são de percepção leve, devendo ser preferidas para textos na interface.

Tamanhos entre 9 a 12 pontos são mais legíveis, o que aumenta a velocidade da

leitura.

Exemplo

Na Figura 3.12, o primeiro relatório está com duas casas decimais e uso repetido de

palavras (Figura 3.12a); o segundo com números inteiros (no caso, a precisão não é

95

requerida) e abreviações (Figura 3.12b). O tempo médio para os usuários interpretarem

os resultados foi, respectivamente, 8,3 seg. e 5 seg. O segundo relatório reduziu o

tempo de interpretação dos resultados em 40%.

Fig. 3.12 - Exemplo de relatórios. FONTE: Tullis (1997, p. 588).

Na Figura 3.13, os agrupamentos são identificados e possuem um espaçamento lateral

igual entre os limites gráficos.

Fig. 3.13 - Exemplo de alinhamento e agrupamento.

(a) (b)

96

Fig. 3.14 - Fontes : (a) com serifa (b) sem serifa.

Estratégia #MIE6. Usar cores de forma cuidadosa

Descrição

Cores podem ser usadas para comunicar idéias, mostrar relacionamentos entre itens,

retratar objetos realisticamente e melhorar a aparência de uma interface. Contudo, por

serem tão poderosas, o modelador deve se preocupar em empregá-las corretamente.

Usar cores de forma cuidadosa requer (Marcus, 1997; Shneiderman, 1998):

• uso conservativo: em geral, cores similares podem ser usadas para agrupar itens

relacionados ou para enfatizar uma organização lógica da informação. Neste caso,

em que o seu significado deve ser lembrado, sugere-se limitar em 4 o número de

cores em uma única tela e em 7 ao longo de toda a interface;

• uso consistente: deve-se procurar criar e obedecer a regras para a aplicação de cores

na interface. Se uma mesma cor é usada diferentemente na interface, então o usuário

tentará encontrar significados para essa mudança. Por exemplo, se mensagens de

erro são definidas em vermelho, deve-se ter certeza que todas elas aparecem com

essa cor. Uma alteração para amarelo pode ser interpretada como sendo uma

mudança na importância da mensagem. O uso consistente também é válido para as

documentações que acompanham o sistema;

• uso de acordo com as expectativas dos usuários: o modelador deve tomar

conhecimento sobre as cores mais representativas para a comunidade de usuários,

como aquelas que são usadas em suas tarefas ou que são culturalmente

reconhecidas;

• cuidado na combinação de cores: cores puras como vermelho e verde quando

aparecem ao mesmo tempo, podem dificultar a absorção da informação pelo

S S (a) (b)

97

usuário. Em Tullis (1997) é sugerido que a quantidade de contraste entre a cor de

fundo e a cor da fonte de um texto é um dos fatores determinantes para a sua

legibilidade. No Apêndice F, são apresentadas essas quantidades para combinações

entre 16 cores presentes em uma paleta VGA. Convertendo a paleta VGA para 256

tons de cinza, em condições ideais, diferenças entre tons iguais ou maiores que 170

indicam combinações mais legíveis, como o caso de cinza claro e preto (diferença =

192) e cinza claro e azul (diferença = 177). Por outro lado, diferenças iguais ou

menores que 85 indicam combinações menos legíveis, como o caso de cinza claro e

marrom (diferença = 79) e cinza claro e branco (diferença = 63).

Comentário

Certas combinações de cores não são percebidas por muitas pessoas. Portanto, deve-se

permitir o seu ajuste na interface.

Testes com outros tipos de monitores e em ambientes escuros/claros também são

necessários para alcançar as melhores combinações de cores.

Estratégia #MIE7. Considerar a eficiência na entrada de dados

Descrição

Grande parte do tempo do usuário é gasto escolhendo comandos, digitando dados ou de

outro modo, proporcionando a entrada ao sistema. Tarefas de entrada de dados podem

ocupar uma fração substancial do tempo de operação de um sistema.

Escolha dos dispositivos físicos

Embora o teclado permaneça como dispositivo de entrada primário, permitir a

flexibilidade na escolha do dispositivo é a melhor maneira de acomodar capacidades

físicas, habilidades individuais e situações de uso. Cada dispositivo de entrada é

otimizado para certos usuários e podem ser mais convenientes de uma situação para

outra. Por exemplo, o mouse é mais indicado para seleções precisas, leitores ópticos

disponibilizam seqüências rapidamente e mesas digitalizadoras fornecem um alto grau

de controle, apreciado por artistas gráficos (Shneiderman, 1998).

Contudo, não se deve exigir a troca entre dispositivos em um determinado ponto de

98

interação. Os usuários devem ser capazes de completar uma seqüência inteira de

entradas, por meio de um único dispositivo.

Minimização de entrada

Poucas ações significam maior eficiência para o usuário. Fazer uma escolha a partir de

uma tecla ou seleção por mouse, ao invés de uma digitação extensa, é potencialmente

mais produtivo. Outro aspecto a ser observado é a redundância de entradas. A partir de

uma requisição, deve-se observar outros pontos de interação onde a mesma informação

é necessária e assim, disponibilizá-la para uso ou sobreposição (Shneiderman, 1998).

Resposta à entrada

A ausência de informações que indiquem uma atividade normal de processamento

obstrui o processo complexo de ação e interpretação, próprio de uma interação. Deve-se

indicar a indisponibilidade do sistema, o tempo esperado de processamento, o progresso

da tarefa e os resultados (sucesso ou fracasso) alcançados (LabIUtil, 2000).

Atenção à origem

Caso os dados de entradas sejam provenientes de algum documento físico (formulário

em papel ou de livros de registros), é importante estabelecer uma seqüência de entrada

comum à origem. Isto minimiza esforços físicos. O mesmo ocorre em relação aos dados

apresentados: não se deve exigir do usuário a realização de cálculos de conversão

(LabIUtil, 2000).

Preenchimento de formulário

• Os campos de dados devem ser adequadamente identificados, com informações

sobre o formato, unidade e valores possíveis. Um símbolo padronizado, em geral ‘:’

deve ser empregado como explicitação do convite à entrada. Com o objetivo de

minimizar a digitação, pode-se estabelecer um valor proposto.

• Os campos opcionais devem ser claramente marcados com o uso da palavra

‘opcional’ ou com uma outra indicação visual. Preferencialmente, devem ser

colocados após os campos obrigatórios.

• Limites gráficos para a entrada devem ser aplicados, para que o usuário seja capaz

99

de perceber o tamanho real dos campos e assim antecipar abreviações necessárias.

• Em entradas de valores codificados com mais de 10 letras ou 5 dígitos, um molde

com espaços, hífens ou barras pode ser definido. O objetivo é dividir a entrada em

grupos de 3 a 4 caracteres, para evitar erros e facilitar a leitura.

• O registro dos dados entrados em um formulário não deve ser acionado como efeito

da ação de entrada de um outro dado. O usuário deve, explicitamente, solicitar este

registro, por meio de um botão de comando. Da mesma forma, deve ser previsto um

botão para cancelar a entrada. Após o registro, os campos desconsiderados devem

ser visualmente marcados.

Estratégias para Especificação

Estratégia #MIE8. Construir o cenário para a interface

Descrição

Um cenário da interface é uma seqüência de desenhos de telas construídos para

representar tanto o conteúdo (os dispositivos virtuais necessários) de uma tela, quanto a

navegação (ou relacionamento) entre elas. Sua finalidade é fornecer uma capacidade

antecipada de observar a interface, permitindo avaliar idéias e também comparar

alternativas, antes de se comprometer com alguma delas (Hix e Hartson, 1993).

O cenário pode ser construído utilizando materiais simples como papéis e canetas.

Cores e padrões de preenchimento são empregados para destacar janelas, menus e

demais elementos que se movam ou mudam de aparência. Notas sobre o

comportamento do elemento podem ser adicionadas ao cenário.

Para compor as telas, o modelador pode explorar o conceito de metáfora. Trata-se de

uma analogia com conceitos e objetos que já são familiares aos usuários e dos quais eles

podem extrair comportamentos e regras de utilização (LabIUtil, 2000). Por exemplo,

para o Sistema Simplificado de Biblioteca pode-se usar o conceito de agenda para

representar as solicitações de reservas de uma obra.

Uma das metáforas mais conhecidas usadas para a construção de interface é a da mesa

de trabalho (“desktop metaphor”). A interface se apresenta como uma mesa na qual os

100

usuários podem manusear uma variedade de objetos comuns a um ambiente de

escritório, como caixas de entrada e saída para correspondências, pastas para arquivo de

documentos, impressoras e telefones (SEI, 1987).

As metáforas podem ser próprias do contexto (ambiente de trabalho) ou coexistirem

com outras já definidas, como o caso de botões, caixas de texto, caixas de verificação,

etc. (LabIUtil, 2000).

Comentário

Outras técnicas, como o uso de transparências e ferramentas gráficas, podem ser usadas

para a construção de cenários.

Exemplo

A Figura 3.15 mostra um cenário inicial para o caso de uso ‘Consultar acervo’.

Fig. 3.15 - Cenário da interface.

Estratégia #MIE9. Refinar as classes de fronteira

Descrição

Para permitir a alimentação dos metadados do CIH no BDEC, adequadamente, é preciso

refinar as colaborações do Modelo Comportamental que possuem classes de fronteira

usadas para modelar a interface humano-computador.

Consultar acervo

Título:

Autor:

Buscar Cancelar

Inicialmente, esse botão está indisponível para o usuário.

Consultar acervo

Título:

Autor:

E

Cancelar Buscar

Digitada uma letra no campo autor ou título, este botão fica disponível.

101

A partir dos cenários, deve-se identificar as classes dos dispositivos virtuais escolhidos

e definir a interação dos objetos dessas classes com os demais objetos, de forma a

permitir a realização do caso de uso (Figura 3.16 e 3.17). Essas classes de objetos serão

usadas para a alimentação dos metadados do CIH.

Conforme visto no Capítulo 2, as interfaces gráficas permitem ações de manipulação

direta que são registradas pelo Sistema de Janelas como eventos. Dada essa

característica, a interface está sujeita a uma série de eventos que podem ser válidos ou

não. Quando um evento válido ocorre, a interface move de um conjunto de eventos

possíveis para outro, ou seja, existe uma mudança de estado. Portanto, o estado

representa o conjunto de eventos válidos esperados em um determinado momento

(Horrocks, 1999).

Desta forma é necessário especificar quais são os eventos válidos para a interface para a

posterior alimentação dos metadados do CIH.

Exemplo

A Figura 3.16 apresenta a parte estrutural da colaboração, referente às classes de

fronteira, para o caso de uso Consultar Acervo.

Fig. 3.16 - Parte estrutural da colaboração.

A Figura 3.17 apresenta a parte comportamental da colaboração, refinada com as

operações dos objetos do CDP.

Janela

BotãoCaixa_TextoTexto

3 2 2

102

Fig. 3.17 - Diagrama de seqüência.

O Diagrama de Gráfico de Estados fornece uma notação que permite que a interface

seja especificada de forma concisa e em diferentes níveis de abstração (Horrocks, 1999;

Booch et al., 2000).

A Figura 3.18 apresenta a parte comportamental da colaboração, detalhada com o

diagrama de gráfico de estados.

Fig. 3.18 - Diagrama de gráfico de estado.

Jn_Consulta

:Janela :Cliente

Set_Título

Set_Autor

Procurar

Digitar título

obLivro:Livro

Digitar autor

Pressionar botão

Cenário: Janela Principal 1

Esperando escolha

Botão Cancelar clicado ou Janela fechada

Cenário: Consulta Acervo

Opção consulta clicada

Janela fechada

2 Esperando entrada de dados

3 Pronto para consulta

Botão Buscar clicado / obLivro.SetAutor, oblivro.SetTitulo, oblivro.Procurar

Autor ou Título digitado

Cenário: Result. Pesquisa

4 Apresentando resultado

Janela fechada

103

A Tabela 3.4 pode ser usada para fornecer detalhes suplementares ao diagrama.

TABELA 3.4 - SUPLEMENTO DO DIAGRAMA DE GRÁFICO DE ESTADOS

Estado Evento Ação Próximo Estado

1 Opção Consulta clicada - 2

2 Autor ou Título digitado - 3

2 Botão Cancelar clicado ou Janela Fechada

- 1

3 Botão Buscar clicado obLivro.SetAutor

obLivro.SetTitulo

obLivro.Procurar

4

3 Botão Cancelar clicado - 1

4 Janela fechada - 2

FONTE: adaptada de Horrocks (1999, p. 36).

Estratégia #MIE10. Documentar os objetos de interface

Descrição

Ambler (1998) sugere o modelo apresentado na Tabela 3.5 para a documentação dos

objetos de interface. No caso, são documentados os objetos que, na associação por

agregação, funcionam como recipientes para outros objetos conteúdo, como o caso de

caixas de diálogo, relatórios e formulários.

Exemplo

TABELA 3.5 - DOCUMENTAÇÃO DA INTERFACE

Objetos de Interface

Janela: Consultar acervo

Propósito: permitir a consulta ao acervo da Biblioteca.

Continua.

104


Objetos de Interface

Interage com:

Janela Principal - apresenta as opções disponíveis

Janela Resultado da Consulta - lista com as referências encontradas para título/autor.

Dispositivos virtuais:

Caixa de texto Autor: qualquer parte do nome do autor que se deseja consultar.

Caixa de texto Título: qualquer parte do título da obra que se deseja consultar.

Botão Buscar: realiza a pesquisa no acervo de acordo com os campos informados.

Botão Cancelar: fecha a janela de consulta sem realizar nenhuma operação de pesquisa.

FONTE: adpatada de Ambler (1998, p. 285).

Estratégias para a Avaliação

Estratégia #MIE11. Avaliar o cenário da interface

Conforme apresentado na estratégia #MIE8, o cenário tem a capacidade de fornecer

uma visão da interface, permitindo avaliar idéias e também comparar alternativas, antes

de se comprometer com alguma delas.

O seguinte método pode ser usado para apresentá-lo ao usuário: o modelador posiciona

o cenário à frente do usuário e faz o papel de “computador”, movimentando as telas em

resposta às suas ações. O usuário faz seleções e ativa os elementos da interface usando

os dedos (simulando o mouse) e escrevendo as entradas necessárias. Outro membro da

equipe pode facilitar a sessão, fornecendo as instruções e encorajando o usuário a

expressar suas opiniões sobre o cenário (Rettig, 1994).

Comentário

Com cenários captura-se idéias rapidamente e com poucos recursos. Pode-se levá-los à

discussão com os usuários e demais modeladores, obtendo assim retornos significativos

para o aprimoramento da interface.

105

Estratégia #MIE12. Construir modelos de usabilidade

Descrição

Seguindo os cenários, o modelador pode construir modelos para descobrir, de modo

antecipado, problemas de usabilidade na interface. Contudo, por existir aspectos de

usabilidade não revelados por esses modelos, ensaios de interação ainda são requeridos

para a avaliação (Kieras, 1997).

Procedimentos para a construção de modelos GOMS:

• escolher as tarefas mais representativas e que nas quais as ações dos usuários podem

ser representadas de forma hierárquica e seqüencial;

• definir as metas dos usuários;

• para cada meta seguir o procedimento recursivo:

construir um método para alcançar a meta;

se necessário, ir para um nível mais baixo de análise, mudando os operadores de

mais alto nível para metas e definindo métodos para alcançá-las;

• fazer a previsão do desempenho humano;

• fazer uma análise qualitativa do modelo.

Exemplo

Suponha o caso de uso ‘Registrar exemplar’ para o Sistema Simplificado de Biblioteca.

Caso exista mais de um exemplar com o mesmo número de registro, o usuário pode

usar, novamente, a opção ‘Incluir’ ou a opção ‘Copiar’ . Isso se deve a um resultado do

modelo de negócio, quando se constatou que um bibliotecário, geralmente, compra

mais de um exemplar de um mesmo título.

Usando a notação NGOMSL, essas alternativas para o cadastro do exemplar podem ser

assim representadas:

Método para a meta: cadastrar exemplar – incluir.

Passo 1) Alcançar a meta: selecionar acervo.

106

Passo 2) Alcançar a meta: incluir exemplar.


Método para a meta: cadastrar exemplar – copiar.

Passo 1) Alcançar a meta: copiar exemplar.


Método para a meta: selecionar acervo.

Passo 1) Apontar para ‘Procurar Acervo’.

Passo 2) Clicar.

Passo 3) Apontar para o campo ‘Número de Registro’.

Passo 4) Mover as mãos para o teclado.

Passo 5) Digitar o número do registro.

Passo 6) Pressionar ‘<Enter>’.


Método para a meta: incluir exemplar.

Passo 1) Apontar para ‘Incluir Exemplar’.

Passo 2) Clicar.

Passo 3) Apontar para o campo ‘Número de Exemplar’.


Passo 5) Digitar o número de exemplar.

Passo 6) Pressionar ‘<Enter>’

Passo 7) Digitar o número da edição.


Passo 9) Digitar o ano da publicação.


107


Método para a meta: copiar exemplar.

Passo 1) Apontar para ‘Copiar Exemplar’.

Passo 2) Clicar.

Passo 3) Apontar para o campo ‘Número de Exemplar’.


Passo 5) Digitar o número de exemplar.



Análise quantitativa - previsões

Considerando que os atributos:

Número de Registro e Número de Exemplar requerem 5 caracteres, Número de Edição

requer 3 caracteres, Ano da Publicação requerer 4 caracteres têm-se :

TEMétodo Selecionar Acervo = 7 seg.

TEMétodo Incluir Exemplar = 12,20 seg.

TEMétodo Copiar Exemplar = 7 seg.

TEMétodo Cadastrar Exemplar - Incluir = 0,40 + 7 + 12,20 = 20 seg.

TEMétodo Cadastrar Exemplar - Copiar = 0,30 + 7 = 7,30 seg.

Isso significa que o Método cadastrar exemplar – copiar é mais rápido e deve ser

adotado como uma solução para maior eficiência na entrada de dados. Contudo, a

adição de mais um método requer um tempo de aprendizado maior.

Os resultados obtidos com a análise devem ser confrontados com os níveis de

desempenho da Especificação de Usabilidade.

Análise qualitativa

• Naturalidade: o método cadastrar exemplar - copiar apresenta-se como um

108

procedimento familiar em que um determinado conteúdo é duplicado para posterior

uso.

• Clareza: como existem dois métodos para alcançar a mesma meta deve ficar claro

(documentado e apresentado na interface) que o cadastrar exemplar - copiar deve ser

usado após o método cadastrar exemplar - incluir.

• Consistência: para outras metas deve ser considerado o uso da opção Copiar.

• Eficiência: O tamanho dos métodos está dependente da quantidade de dados a

serem digitados. Contudo, o método cadastrar exemplar - copiar reduz a quantidade

de entrada para os próximos exemplares.

Estratégia #MIE13. Realizar ensaios de interação

Descrição

Conforme visto no Capítulo 2, os ensaios de interação são realizados sobre versões

operacionais da interface (a própria interface ou protótipos). Dessa forma, é preciso

alimentar os metadados do CIH e dos demais componentes para que a interface possa

passar por este tipo de avaliação. As estratégias para alimentação do CIH são

apresentadas no Capítulo 4, as estratégias para o CDP se encontram em Dias (1999) e

para a alimentação do CGD em Cottini (1999).

Alimentado os metadados no BDEC, gera-se a aplicação e pode-se partir para a

execução desta estratégia, que consiste na realização de ensaios de interação.

Os ensaios de interação fornecem dados quantitativos contra os quais os modeladores

podem comparar as metas definidas na Especificação de Usabilidade. Também produz

dados qualitativos, usados para a descobrir os problemas de usabilidade que podem ter

causado o não alcance da meta de usabilidade.

Esta estratégia envolve a realização dos ensaios de interação e também a análise dos

dados coletados durante a sessão. A seguir são apresentados os principais

procedimentos realizados numa avaliação por ensaios de interação, segundo Hix e

Hartson (1993).

109

Desenvolvimento do Ensaio

• Selecionar os participantes para executar as tarefas presentes na Especificação de

Usabilidade: os participantes devem estar dentro das classes de usuários

identificadas. Estudos têm mostrado que o melhor número de participantes por

sessão encontra-se entre 3 a 5 usuários por classe.

• Especificar as tarefas: cada tarefa deve ser detalhadamente descrita para que seja

realizada, da mesma forma, por cada participante da avaliação. Por exemplo, uma

tarefa com a seguinte descrição ‘Realizar uma consulta no acervo’ pode ser

realizada de muitas maneiras. Sendo assim, uma descrição mais específica, como

‘Realizar a consulta no acervo, procurando pelas obras do autor José de Alencar’ é

mais apropriada para tornar consistente as medidas através de todos os participantes.

• Definir as técnicas complementares: consiste em definir as técnicas para a geração

de dados qualitativos (verbalização, entrevistas, etc.) e as técnicas para registro de

dados (anotação manual, vídeo, etc.). O modelador também pode incluir outras

tarefas que permitem investigações e obtenção de dados qualitativos.

Realização do Ensaio

Na realização do ensaio deve-se registrar o desempenho dos usuários na execução das

tarefas preparadas, distribuir e coletar os questionários e executar as técnicas para

geração de dados qualitativos durante o ensaio ou após o seu término.

Análise dos dados

• Verificar o alcance das metas de usabilidade (atributo mais o nível de desempenho

almejado): consiste em computar os dados quantitativos registrados e compará-los

com os níveis de desempenho estabelecidos. Se todos os níveis almejados tenham

sido atingidos, então significa que a usabilidade da versão da interface está

aceitável. Caso isso não aconteça, mas todos os níveis mínimos foram alcançados,

fica critério da equipe de modelagem (ou da gerência do projeto) ativar um outro

ensaio de interação. Se não for atingido nenhum dos níveis citados, deve-se procurar

analisar os dados qualitativos para buscar as justificativas para o insucesso.

110

• Analisar os problemas de usabilidade: consiste em computar os dados qualitativos

registrados e encontrar os problemas de usabilidade. Para cada problema, define-se

qual foi o seu impacto quanto ao alcance das metas, sua importância e as soluções

para a sua correção.

• Analisar e aplicar as soluções sugeridas na especificação da interface: consiste em

avaliar o impacto das soluções sugeridas no cronograma do projeto. Caso sejam

aprovadas as melhorias sugeridas na interface, deve-se atualizar os modelos para

refletir as decisões da equipe, reconfigurar o CIH e realizar, novamente, o ensaio de

interação.

3.2.3.3 - Contexto do Modelo de Implantação

O Modelo de Implantação descreve como o sistema de software está alocado entre os

recursos computacionais disponíveis. Para isso, é necessário fazer a modelagem do

sistema computacional, ou seja, modelar processadores e dispositivos, assim como os

componentes (subsistemas, classes, etc.) que estão instalados em tais recursos

computacionais.

A Figura 3.19 apresenta o Diagrama de Implantação para um sistema de software

baseado em SOFTBOARD.

Fig. 3.19 - Diagrama de implantação para um sistema baseado em SOFTBOARD. FONTE: Dias (1999).

Computador: Pentium 300 Mhz

CDP.dll

CIH.dll CGD.dll

CMOOS.dll

CIS.dll

Aplicação.exe

CGC.dll

111

3.2.4 - Modelagem Física

Fig. 3.20 - Construção do Modelo Físico.

Para os sistemas de software baseados em SOFTBOARD, o modelo físico corresponde

ao sistema representado pelas bibliotecas de classes, juntamente com todos os

documentos gerados durante o desenvolvimento. Para construir o modelo físico é

necessário implementar as classes do CDP e gerar a aplicação seguindo os passos

(Cunha, 1997):

• montar as bibliotecas com as classes do CDP,CIH,CGD,CIS,CGC e CMOOS;

• montar o código executável da aplicação, que contém uma classe Servidor-CGC

que cria um objeto de uma classe do CIH para a identificação do usuário; e

• gerar o Catálogo e um arquivo de inicialização com todas as informações

necessárias para a carga da aplicação.

3.3 - Alocação das Estratégias da IH no Processo de Desenvolvimento Unificado

O desenvolvimento de interfaces é um processo iterativo, que requer uma especificação

seguida de alguma forma de avaliação que realimenta a própria especificação. Versões

da especificação refinadas a cada teste podem, substancialmente, melhorar a interação

do usuário com o sistema. Portanto, não é um desenvolvimento em dois estágios, ela

requer um processo iterativo e incremental (Hix e Hartson, 1993; Horrocks, 1999).

Como visto no Capítulo 2, o Processo de Desenvolvimento Unificado tem como uma

de suas características ser iterativo e incremental. Portanto, pode-se alocar as estratégias

aqui propostas dentro do Processo de Desenvolvimento Unificado, como apresentado na

Modelo

Operacional

Modelo Físico

112

Figura 3.21.

No fluxo de Requisitos acontece levantamento das características dos potenciais

usuários e a construção da tabela de Especificação de Usabilidade. O fluxo de Desenho

é influenciado por padrões, diretrizes, experiência com outros sistemas e pelos próprios

requisitos do sistema. Esse fluxo produz como artefato uma especificação que pode ser

utilizada para a configuração do CIH. A especificação também permite que a interface

possa ser avaliada sem a necessidade de implementação ou configuração. A

configuração do CIH (alimentação dos metadados) pode acontecer de forma parcial ou

completa. A especificação e a interface podem ser avaliadas no fluxo de Testes.

Fig. 3.21 - Alocação das estratégias nas fases e fluxos do Processo Unificado.

TABELA 3.6 - ALOCAÇÃO DAS ESTRATÉGIAS NAS FASES E FLUXOS DO PROCESSO UNIFICADO

Legenda Estratégias MAM1

MAM2,MAM3,MAM4,MAM5

MIE1,MIE2,MIE3,MIE4,MIE5, MIE6,MIE7,MIE8,MIE9,MIE10

Estratégias de alimentação

MIE11,MIE12,MIE13

Fases Fluxos Concepção Elaboração Construção Transição

Requisitos

Análise

Desenho

Implementação

Testes

Iter. 1

Iter. 2

... ... ... ... ... Iter. n-1

Iter. n

Iterações

113

CAPÍTULO 4

MODELO DOS METADADOS DO CIH E ESTRATÉGIAS PARA A

ALIMENTAÇÃO NO BDEC

Nos sistemas de software baseados na arquitetura SOFTBOARD, o comportamento dos

objetos dos componentes CIH, CGC, CIS e CGD variam de acordo com o CDP, ou seja,

o domínio do problema. Para isso, é necessário que esses componentes estejam

configurados para atender ao CDP da aplicação. Dessa forma, consegue-se um grau

maior de reutilização, pois para cada novo sistema faz-se necessário apenas definir o seu

CDP e configurar os demais componentes da arquitetura.

O CMOOS é que permite dar à arquitetura SOFTBOARD a característica de

configurável. Esse componente mantém o Catálogo, um repositório de metadados, que

são as informações sobre a configuração de cada componente.

Neste capítulo apresenta-se um modelo das informações necessárias para configurar o

CIH e assim torná-lo reutilizável para novos sistemas. Também se apresentam as

estratégias para alimentá-las no BDEC, a partir do qual, o Catálogo é gerado.

Quanto às estratégias de alimentação, deve ser observado o forte relacionamento entre o

CDP e o CIH, uma vez que os usuários e as tarefas são obtidos do domínio do

problema. Para a sua melhor compreensão, inicialmente, são revisadas as estratégias de

alimentação do BDEC com os metadados do CDP, apresentadas em Dias (1999).

Posteriormente, essas são estendidas para incluir novos metadados e, finalmente, são

apresentadas as estratégias de alimentação para os metadados do CIH.

Para permitir a avaliação do modelo de metadados e das estratégias desenvolvidas, um

protótipo operacional foi construído, sendo apresentado no Apêndice B.

4.1 - Abordagem Inicial

Para a modelagem dos metadados do CIH foram aplicados os níveis de abstração

descritivo, conceitual e operacional, apresentados no Capítulo 2. Os modelos resultantes

são apresentados a seguir.

114

4.2 - Modelo dos Metadados do CIH

4.2.1 - Os Requisitos para o CIH

No caso do CIH, a possibilidade de adaptação ao usuário é um aspecto diferente da

reutilização, mas que pode igualmente ser explorado pela configuração. Por exemplo,

um conjunto de botões pode ser colocado em uma janela na posição que o usuário

quiser e, posteriormente, ser substituído por um menu de opções.

Dessa forma, os requisitos para o CIH, definidos por Cunha (1997), estabelecem que

esse componente deve ser configurável de modo que:

1) a interface seja apresentada segundo as características e experiências dos

usuários:

o modelo de metadados do CIH deve ser capaz de tratar todo o ciclo de

aprendizado envolvido na utilização de uma aplicação. Isto significa, que ele

deve suportar as classes de usuários encontradas durante a modelagem. Para

apresentar uma interface segundo as características e experiência dos

usuários, cada classe de usuário deve ter associada um conjunto de

elementos para a interação;

2) a interface possa ser modificada ou reorganizada para atender às

necessidades particulares de cada usuário:

como uma forma de minimizar a dependência do usuário em relação à

configuração original da interface, recursos para a alteração da interface

devem ser providos já em tempo de execução da aplicação. Esses recursos

devem permitir mudanças de posição, tamanho, cor, substituição de

metáforas, criação de atalhos, apresentação de conteúdos explicativos, entre

outros.

Portanto, com a utilização dos recursos, um determinado caso de uso pode,

inicialmente, ser realizado por uma colaboração de objetos escolhidos segundo uma

classe de usuário e posteriormente, quando o usuário realizar mudanças na interface,

ser materializado por uma colaboração formada de metáforas escolhidas por ele próprio.

Desse modo, o modelo de metadados deve estar preparado para reter a configuração

115

original e posterior de uma interface.

4.2.2 - Modelo Conceitual

4.2.2.1 - Modelo Ambiental

O usuário é a principal entidade a interagir com o CIH, sendo suas características e

experiências, as fontes para toda a sua configuração.

Como visto no Capítulo 2, os Sistemas de Janelas atuais mapeiam as ações dos usuários

para eventos e os envia para as aplicações responsáveis por tratá-los. O CIH usa as

ocorrências dos eventos para passar mensagens para os objetos do CDP.

O CIH também é capaz de enviar eventos para os elementos da interface (intra-

aplicação) e controlar o seu estado. Para que isso aconteça, o CIH precisa conhecer o

mecanismo de envio e as informações que devem ser fornecidas para que o evento seja,

efetivamente, enfileirado pelo Sistema de Janelas.

O Catálogo armazena os metadados com as informações sobre o usuário e sobre a

interface, é mantido pelo CMOOS e usado pelo CGC para criar os diversos cenários

da aplicação.

4.2.2.2 - Modelo Comportamental

O modelo de objetos de uma aplicação baseada em SOFTBOARD é formado pelas

classes dos componentes Domínio do Problema (CDP), Interface Humano-Computador

(CIH), Gerenciador de Cenários (CGC), Gerenciador de Dados (CGD), Interação Entre

Sistemas (CIS) e Gerenciador de Configuração de Sistema Orientado a Objetos

(CMOOS).

Cada classe possui atributos que descrevem as características de seus objetos e

operações que descrevem o seu comportamento. As operações são usadas para

manipular o valor dos atributos.

O relacionamento entre classes pode acontecer por meio de Associação ou de

Generalização-Especialização. Uma Associação representa que os objetos de uma ou

mais classes possuem uma conexão semântica, por exemplo, “eles conhecem uns aos

outros”, “para cada objeto X existe um ou mais objetos Y”, “um objeto X funciona

116

como um recipiente para um objeto Y”, etc. Na Generalização-Especialização, as

classes são organizadas em hierarquias que permitem que características e

comportamentos sejam herdados. Uma classe mais específica é consistente com sua

classe mais genérica, porém possui informações que a particulariza (Rumbaugh et al.,

1991; Coad e Yourdon, 1992; Booch, 1994; Eriksson e Penker, 1998).

Um caso de uso representa uma maneira específica em que um ator – pessoa,

dispositivos de hardware ou outro sistema - interage com o sistema em consideração.

Casos de uso são descrições, independentes de implementação, das funções de um

sistema (Eriksson e Penker, 1998; Jacobson et al. 1999; Booch et al., 2000).

Uma colaboração mostra uma solução, dependente de implementação, para a realização

do caso de uso. Esta realização acontece em termos de classes, objetos e seus

relacionamentos (chamado de contexto da colaboração ou parte estrutural) e de um

conjunto de mensagens trocadas entre objetos para obter a função desejada (chamada de

interação da colaboração ou parte comportamental) (Eriksson e Penker, 1998; Booch et

al., 2000).

Para atender aos requisitos do CIH, a classe Classe_Usuário e a classe Grupo_Funcional

representam, respectivamente, as classes de usuários e a categorias funcionais a que

pertencem. Cada classe de usuário possui recursos (representada pela classe

Recurso_IH) que permitem a melhor personalização da interface, e se associa a

colaborações de objetos que realizam aos casos de uso da aplicação. Posteriormente,

após a modificação da interface em tempo de execução, o usuário tem uma colaboração

própria de objetos para a realização do caso de uso.

A classe Objeto representa os objetos das classes dos componentes da SOFTBOARD

que devem ser instanciados.

A classe Metáfora representa os elementos de interface usados na colaboração. Possui

os atributos de altura, largura e posição (expressas nas coordenadas x e y relativas ao

canto superior esquerdo de sua metáfora agregadora).

Cada metáfora possui um tipo que determina a sua aparência e seu comportamento.

Cada tipo (classe Tipo_Metáfora_IH) é uma abstração de um elemento de interface

117

materializado em uma biblioteca. Por exemplo, um tipo “Botão” é materializado por um

elemento “Button” fornecido pelo Windows ou por um elemento “PushButton” do

Motif/X Window.

A classe Propriedade_TM representa as propriedades (título, cor, fonte, borda, etc.)

que um tipo possui. No Windows, as propriedades são modificadas pelo envio de

mensagens de leitura ou de escrita. Nos “toolkits” construídos para o X Window, as

propriedades podem ser acessadas pelo seu próprio nome, como o caso do Motif.

Cada metáfora deve ser disponibilizada de acordo com a permissão que o usuário tem

para utilizar as funções por ela ativada (segurança de acesso).

A classe Evento_Capturado representa os eventos recebidos por uma metáfora em uma

determinada colaboração. Quando um evento acontece pode haver a necessidade da

realização de um grupo de ações. Essas ações podem mudar o estado de um objeto ou

de uma metáfora (classe Atribuição) ou desencadear novos eventos (classe

Evento_Gerado). Para gerar um evento são necessárias informações, como qual é a

metáfora de destino. No modelo, a classe Complemento representa essas informações

de envio de um evento.

As classes Propriedade_TM, Evento e Complemento foram especializadas para mostrar

as classes necessárias para as aplicações baseadas no Sistema Operacional Windows.

A Figura 4.1 apresenta um diagrama de classes que abrange os metadados do CDP e do

CIH. A notação do diagrama de classes da UML encontra-se no Apêndice C.

118

Fig.

4.1

– D

iagr

ama

de c

lass

es d

os m

etad

ados

nec

essá

rios p

ara

o C

IH.

119

4.2.3 - Modelo Operacional

4.2.3.1 - Modelo de Implementação

As classes de objetos persistentes encontradas no Modelo Conceitual foram mapeadas

para o Modelo de Dados Relacional utilizando-se as estratégias para modelagem do

banco de dados das aplicações baseadas em SOFTBOARD, apresentadas em Cottini

(1999).

A Figura 4.2 apresenta o mapeamento das classes e seus relacionamentos para o Modelo

de Dados Relacional, utilizando o diagrama Case*Method. Um resumo dessa notação

encontra-se no Apêndice E.

120

Fig.

4.2

– M

odel

o re

laci

onal

dps

met

adad

os n

eces

sário

s par

a o

CIH

.

121

4.3 - Estratégias para a Alimentação do BDEC

Em Dias (1999) são apresentados um modelo dos metadados do CDP e as estratégias

de alimentação do BDEC com esses metadados. Faz-se necessário complementar o

modelo com as informações sobre os casos de uso encontrados no domínio do

problema, pois a partir deles, são construídas as colaborações.

Portanto, primeiramente, são revisadas algumas das estratégias de alimentação do CDP

interessantes para o CIH. Posteriormente, é apresentada uma extensão para essas

estratégias e finalmente, baseado no Modelo Operacional, são estabelecidas as

estratégias para a alimentação do BDEC com os metadados do CIH.

Nota-se que o cadastro das informações no BDEC pode ocorrer tanto durante processo

de desenvolvimento da aplicação quanto, posteriormente, com a mesma já em uso.

Os exemplos apresentados em cada estratégia estão baseados nos diagramas construídos

como parte de uma modelagem para um Sistema Simplificado de Biblioteca. Os

diagramas encontram-se no Apêndice D.

4.3.1 - Revisão das Estratégias para a Alimentação do BDEC com os Metadados

do CDP

A Tabela 4.1 apresenta as estratégias para a alimentação do BDEC com os metadados

do CDP.

TABELA 4.1 - ESTRATÉGIAS REVISADAS

Estratégias

#ACDP1 - Cadastrar o modelo OO.

#ACDP2 - Cadastrar o componente do CDP.

#ACDP3 - Cadastrar as classes de objetos do CDP.

#ACDP4 - Cadastrar os atributos das classes de objetos do CDP.

#ACDP5 - Cadastrar as operações das classes de objetos do CDP.

Continua.

122


Estratégias

#ACDP6 - Cadastrar as conexões entre os objetos do CDP.

#ACDP7 - Cadastrar as estruturas de generalização-especialização.

#ACDP8 - Cadastrar os casos de uso.

Estratégia #ACDP1. Cadastrar o modelo OO

Descrição

Registre no BDEC a aplicação em desenvolvimento.

Exemplo

TABELA 4.2 - RELAÇÃO RELMODELO_OO

IdModelo_OO Sistema Simplificado de Biblioteca

Estratégia #ACDP2. Cadastrar o componente do CDP

Descrição

Registre no BDEC o componente CDP.

Exemplo

TABELA 4.3 - RELAÇÃO RELCOMPONENTE_SB

IdComponente_SB IdModelo_OO CDP Sistema Simplificado de Biblioteca

Estratégia #ACDP3. Cadastrar as classes de objetos do CDP

Descrição

Registre no BDEC todas as classes dos objetos encontrados no domínio do problema.

123

Exemplo

TABELA 4.4 - RELAÇÃO RELCLASSE

IdClasse IdComponente_SB Biblioteca CDP Acervo CDP Livro CDP

Estratégia #ACDP4. Cadastrar os atributos das classes de objetos do CDP

Descrição

Para cada classe de objetos encontrada no domínio do problema, registre no BDEC

todos os seus atributos.

Exemplo

TABELA 4.5 - RELAÇÃO RELATRIBUTO

IdAtributo IdClasse Nome_Biblioteca Biblioteca Titulo Livro

Estratégia #ACDP5. Cadastrar as operações das classes de objetos do CDP

Descrição

Para cada classe de objetos encontrada no domínio do problema, registre no BDEC as

suas operações. Registre os atributos utilizados pela operação e o tipo de acesso

realizado (ler, escrever).

Exemplo

TABELA 4.6 - RELAÇÃO RELOPERAÇÃO

IdOperação IdClasse Set_Nome_Biblioteca Biblioteca Set_Titulo Livro Set_Autor Livro

124

TABELA 4.7 - RELAÇÃO RELOPER-ATRIB

IdOperação IdAtributo Tipo_uso Set_Nome_Biblioteca Nome_Biblioteca Escrever Set_Titulo Titulo Escrever Get_Titulo Titulo Ler

Estratégia #ACDP6. Cadastrar as conexões entre os objetos do CDP

Descrição

Registre no BDEC as conexões existentes entre os objetos das classes do CDP.

Identifique as associações regulares e as agregações necessárias.

Especifique o papel que os objetos possuem em cada conexão.

Exemplo

TABELA 4.8 - RELAÇÃO RELCONEXÃO

IdConexão Biblioteca_Acervo Acervo_Exemplar Empréstimo_ItemEmpréstimo

TABELA 4.9 - RELAÇÃO RELASS_REGULAR

IdAss_Regular IdConexão AssAcervo_Exemplar Acervo_Exemplar

TABELA 4.10 - RELAÇÃO RELAGREGAÇÃO

IdAgregação IdConexão AgBiblioteca_Acervo Biblioteca_Acervo AgEmpréstimo_ItemEmpréstimo Empréstimo_ItemEmpréstimo

125

TABELA 4.11 - RELAÇÃO RELCLASSE-CONEXÃO

IdClasse IdConexão Papel Biblioteca Biblioteca_Acervo Todo Acervo Biblioteca_Acervo Parte Acervo Acervo_Exemplar Associado

Estratégia #ACDP7. Cadastrar as estruturas de generalização-especialização

Descrição

Registre no BDEC as estruturas de generalização-especialização que envolvem as

classes de objetos do CDP.

Especifique que classes devem participar destas generalizações-especializações e qual o

papel de cada uma.

Exemplo

TABELA 4.12 - RELAÇÃO RELGEN_ESP

IdGen_Esp Acervo_Livro_Periódico

TABELA 4.13 - RELAÇÃO RELCLASSE-GEN_ESP

IdClasse IdGen_Esp Papel Acervo Acervo_Livro_Periódico Gen

Livro Acervo_Livro_Periódico Espec

Periódico Acervo_Livro_Periódico Espec

4.3.2 - Extensão das Estratégias para a Alimentação do BDEC com os Metadados

do CDP

Estratégia #ACDP8. Cadastrar os casos de uso

Descrição

126

Registre no BDEC os casos de uso encontrados durante a construção do Modelo

Ambiental.

Exemplo

TABELA 4.14 - RELAÇÃO RELCASODEUSO

IdCasodeUso IdModelo_OO Cadastrar acervo Sistema Simplificado de Biblioteca Registrar Empréstimo Sistema Simplificado de Biblioteca Consultar acervo Sistema Simplificado de Biblioteca

4.3.3 - Estratégias para a Alimentação do BDEC com os Metadados do CIH

A Tabela 4.15 apresenta as estratégias para a alimentação do BDEC com os metadados

do CIH

TABELA 4.15 - ESTRATÉGIAS PROPOSTAS

Estratégias

#ACIH1 - Cadastrar o componente do CIH.

#ACIH2 - Cadastrar os tipos de metáforas para a construção da interface humano-

computador.

#ACIH3 - Cadastrar as propriedades dos tipos de metáforas.

#ACIH4 - Cadastrar as composições permitidas entre os tipos de metáforas.

#ACIH5 - Cadastrar as substituições permitidas entre os tipos de metáforas.

#ACIH6 - Cadastrar os eventos esperados pelo CIH.

#ACIH7 - Cadastrar as classes de usuários.

#ACIH8 - Cadastrar os grupos funcionais.

#ACIH9 - Cadastrar os usuários.

#ACIH10 - Cadastrar as colaborações.

Continua.

127


Estratégias

#ACIH11 - Cadastrar os objetos que interagem na colaboração.

#ACIH12 - Cadastrar as metáforas que participam da colaboração.

#ACIH13 - Cadastrar o primeiro caso de uso estimulado por um grupo funcional.

#ACIH14 - Cadastrar a permissão de acesso às metáforas por grupo funcional.

#ACIH15 - Cadastrar os eventos capturados pelas metáforas.

#ACIH16 - Cadastrar as ações de atribuição produzidas com os eventos.

#ACIH17 - Cadastrar os eventos gerados em resposta ao evento ocorrido.

Estratégia #ACIH1. Cadastrar o componente do CIH

Descrição

Registre no BDEC o componente do CIH.

Exemplo

TABELA 4.16 - RELAÇÃO RELCOMPONENTE_SB

IdComponente_SB IdModelo_OO CIH Sistema Simplificado de Biblioteca

Estratégia #ACIH2. Cadastrar os tipos de metáforas para a construção da

interface humano-computador

Descrição

Registre no BDEC os tipos de metáforas utilizados para a composição da interface da

aplicação.

Para cada tipo de metáfora, identifique os elementos de interface disponíveis, e a

biblioteca onde se encontram as estruturas de dados e os procedimentos que definem a

sua aparência e comportamento.

128

Exemplo

TABELA 4.17 - RELAÇÃO RELTIPO_METAFORA_IH

IdTipo_Metafora_IH Janela Caixa_Texto Botão Texto Item_Menu

TABELA 4.18 - RELAÇÃO RELELEMENTO

IdElemento Biblioteca IdTipo_Metafora_IH Window Pré-definida pela Win32 Janela Edit Pré-definida pela Win32 Caixa_Texto Button Pré-definida pela Win32 Botão Text Pré-definida pela Win32 Texto PushButton Motif Botão

Estratégia #ACIH3. Cadastrar as propriedades dos tipos de metáforas

Descrição

Para cada tipo de metáfora, registre as suas propriedades e o seu tipo no BDEC.

Especializando para as aplicações baseadas em Windows, identifique as propriedades

disponíveis para cada elemento e a mensagem do Windows utilizada para ler e alterar

esta propriedade.

Exemplo

TABELA 4.19 - RELAÇÃO RELPROPRIEDADE_TM

IdPropriedade_TM IdTipo_Propriedade IdTipo_Metafora_IH Título TpString Janela Tamanho_Máximo TpInteiro Caixa_Texto

129

TABELA 4.20 - RELAÇÃO RELPROPRIEDADE_TM_WN

IdPropriedade_TM_Wn Mensagem_Ler Mensagem_Escrever IdPropriedade_TM IdElement

Text Wm_GetText Wm_SetText Título Window MaxText Em_GetLimit Em_SetLimitText Tamanho_Máximo Edit Text Wm_GetText Wm_SetText Rótulo Button

Estratégia #ACIH4. Cadastrar as composições permitidas entre os tipos de

metáforas

Descrição

As composições devem ser registradas no BDEC procurando-se por padrões de

agregação, como, o padrão Recipiente-Conteúdo onde objetos recipientes contêm

vários outros objetos conteúdo. Por exemplo, um tipo de metáfora Janela é um

recipiente para os tipos de metáfora Caixa_Texto e Botão.

Exemplo

TABELA 4.21 - RELAÇÃO RELCOMPOSIÇÃO

IdTipo_Metafora_IH IdTipo_Metafora_IH_Com Janela Caixa_Texto Janela Botão

Estratégia #ACIH5. Cadastrar as substituições permitidas entre os tipos de

metáforas

Descrição

Um recurso que pode ser utilizado pelo usuário para personalizar sua interface é

substituir uma determinada metáfora por outra. Para que isso aconteça, o recurso deve

conhecer quais metáforas podem ser trocadas. Por exemplo, uma metáfora de tipo Item

de menu pode ser substituída por uma de tipo Botão.

Exemplo

130

TABELA 4.22 - RELAÇÃO RELSUBSTITUIÇÃO

IdTipo_Metafora_IH IdTipo_Metafora_IH_Sub Item _menu Botão Lista Combo

Estratégia #ACIH6. Cadastrar os eventos esperados pelo CIH

Descrição

Registre no BDEC os eventos esperados pelo CIH .

Em cada Sistema de Janelas o evento é manuseado por estruturas de dados e

identificadores diferentes. Especializando para as aplicações baseadas em Windows,

identifique os eventos esperados.

Exemplo

TABELA 4.23 - RELAÇÃO RELEVENTO

IdEvento EvTecla_Pressionada EvMouseMovimentado EvMouse_Clicado

TABELA 4.24 - RELAÇÃO RELEVENTO_WN

IdEvento_Wn IdEvento Wn_KeyDown EvTecla_Pressionada Wn_MouseMove EvMouseMovimentado

TABELA 4.25 - RELAÇÃO RELEVENTO_WN

IdEvento_Wn IdEvento Bn_Clicked EvMouse_Clicado En_SetFocus EvCaixa_Texto_Ganhou_Foco En_KillFocus EvCaixa_Texto_Perdeu_Foco

131

Estratégia #ACIH7. Cadastrar as classes de usuários

Descrição

Após o estudo dos usuários, registre as classes que melhor representam as experiências,

conhecimentos e habilidades levantadas entre os potenciais usuários.

Para cada classe de usuário, identifique os recursos para a personalização da interface

que estão disponíveis e a sua recomendação para o uso.

Estratégia de modelagem IH : #MAM4.

Exemplo

TABELA 4.26 - RELAÇÃO RELCLASSE_USUÁRIO

IdClasse_Usuário IdModelo_OO Novato Sistema simplificado de biblioteca Primeira vez Sistema simplificado de biblioteca Experiente_Freqte. Sistema simplificado de biblioteca

TABELA 4.27 - RELAÇÃO RELRECURSO_IH

IdRecurso_IH Recomendação Mover metáfora Recomenda-se não disponibilizá-lo para aplicações em

quiosques de acesso público. Salvar configuração Recomenda-se disponibilizá-lo para usuários freqüentes.

TABELA 4.28 - RELAÇÃO RELCLASSE_RECURSO_IH

IdClasse_Usuário IdRecurso_IH Experiente_Freqte. Mover metáfora Experiente_Freqte. Salvar configuração

Estratégia #ACIH8. Cadastrar os grupos funcionais

Descrição

Após o estudo das tarefas a serem executadas pela aplicação, registre no BDEC os

132

grupos que melhor representam as categorias que podem utilizar (possuem permissão)

as funções que suportam cada tarefa.

Exemplo

TABELA 4.29 - RELAÇÃO RELGRUPO_FUNCIONAL

IdGrupo_Funcional IdModelo_OO Bibliotecário Sistema simplificado de biblioteca Assistente Sistema simplificado de biblioteca

Estratégia #ACIH9. Cadastrar os usuários

Descrição

Registre no BDEC os usuários que usam a aplicação e classifique-os segundo seu grupo

funcional e classe de usuário.

Estratégia de modelagem IH : #MAM2.

Exemplo

TABELA 4.30 - RELAÇÃO RELUSUÁRIO

IdUsuário IdClasse_Usuário IdGrupo_Funcional Elen Experiente_Freqte. Bibliotecário Marcos Novato Assistente

Estratégia #ACIH10. Cadastrar as colaborações

Descrição

Para cada classe de usuário, registre no BDEC, uma colaboração que realiza cada caso

de uso. Posteriormente, quando o recurso “Salvar configuração” for utilizado, uma

nova colaboração é registrada no BDEC, sendo o atributo IdUsuário preenchido com a

identificação do usuário.

Estratégia de modelagem IH : #MIE9.

133

Exemplo

TABELA 4.31 - RELAÇÃO RELCOLABORAÇÃO

IdColaboração IdCasodeUso IdClasse_Usuário Consultar_Acervo_Nv. Consultar acervo Novato Consultar_Acervo_EF. Consultar acervo Experiente_Freqte

Estratégia #ACIH11. Cadastrar os objetos que interagem na colaboração

Descrição

Registre no BDEC os objetos que participam na colaboração (parte estrutural). Esses

objetos serão instanciados pelo CGC para a composição do cenário em tempo de

execução.


Exemplo

TABELA 4.32 - RELAÇÃO RELOBJETO

IdObjeto IdClasse IdColaboração ObLivro Livro Consultar_Acervo_Nv. ObLivro Livro Consultar_Acervo_EF

Estratégia #ACIH12. Cadastrar as metáforas que participam da colaboração

Descrição

De acordo como o cenário construído para o caso de uso, registre no BDEC as

metáforas escolhidas para a composição da interface.

Identifique também as propriedades usadas pela metáfora e o valor inicial de cada uma.


Exemplo

134

TABELA 4.33 - RELAÇÃO RELMETAFORA_IH

IdMetafora Altura Largura C_x C_y IdTipo_Metafora_IH IdColaboração

Jn_Consulta 120 146 110 60 Janela Consultar_Acervo_Nv.Tx_Info 8 122 4 6 Texto Consultar_Acervo_Nv.Tx_Autor 8 18 7 28 Texto Consultar_Acervo_Nv.Tx_Titulo 8 20 6 46 Texto Consultar_Acervo_Nv.Ct_Autor 10 100 31 26 Caixa_Texto Consultar_Acervo_Nv.Ct_Título 10 100 31 44 Caixa_Texto Consultar_Acervo_Nv.Bt_Buscar 12 38 28 86 Botão Consultar_Acervo_Nv.Bt_Cancelar 12 38 78 86 Botão Consultar_Acervo_Nv.

TABELA 4.34 - RELAÇÃO RELMETAF_PROP_IH

IdMetafora_IH IdPropriedade_TM Valor Jn_Consulta Título Consulta ao acervo Tx_Info Texto Preencha o formulário com os dados da publicação:

Tx_Autor Texto Autor: Tx_Titulo Texto Título: Bt_Buscar Rótulo Buscar Bt_Cancelar Rótulo Cancelar

A Figura 4.3 mostra o cenário da interface criado para a colaboração.

Fig. 4.3 - Metáforas da interface.

135

Estratégia #ACIH13. Cadastrar o primeiro caso de uso estimulado por um grupo

funcional

Descrição

Registre no BDEC a identificação do primeiro caso de uso a ser estimulado por um

grupo funcional. Este atributo é usado pelo CGC para montar o primeiro cenário da

aplicação.

Exemplo

TABELA 4.35 - RELAÇÃO RELGRUPO_FUNCIONAL

IdGrupo_Funcional IdCasodeUso IdModelo_OO Bibliotecário Apresentar Opções do Sistema Sistema Simplificado de BibliotecaAssistente Registrar Empréstimo Sistema Simplificado de Biblioteca

Estratégia #ACIH14. Cadastrar a permissão de acesso às metáforas por grupo

funcional

Descrição

Para cada metáfora, identifique o seu comportamento em relação ao acesso de um

usuário de um determinado grupo funcional. Este acesso pode ser:

• disponível;

• invisível (a metáfora não é mostrada);

• indisponível (a metáfora é apresentada, porém não recebe foco de mouse ou

teclado).

Exemplo

TABELA 4.36 - RELAÇÃO RELGRUPO_FUN_METAFORA_IH

IdGrupo_Funcional IdMetafora_IH Acesso Bibliotecário Bt_Buscar Disponível

136

Estratégia #ACIH15. Cadastrar os eventos capturados pelas metáforas

Descrição

Identifique quais eventos capturados pelas metáforas devem ser tratados na colaboração

(a).

A ocorrência de um evento pode determinar a execução de um grupo de ações (b). Essas

ações podem ser para gerar novos eventos ou para realizar operações de atribuição.

Desta forma, identifique o grupo de ações que o evento capturado dispara (c).


Exemplo

a)

TABELA 4.37 - RELAÇÃO RELEVENTO_CAPTURADO

IdEvento_Capturado IdMetafora_IH IdEvento Acionamento_Buscar Bt_Buscar EvMouse_Clicado Acionamento_Cancelar Bt_Cancelar EvMouse_Clicado

b)

TABELA 4.38 - RELAÇÃO RELGRUPO_AÇÃO

IdGrupo_Ação GaMostrarResultado GaFechar_Janela

c)

TABELA 4.39 - RELAÇÃO RELEVENTO_CAPTURADO

IdEvento_Capturado IdMetafora IdEvento IdGrupo_Ação Acionamento_Buscar Bt_Buscar EvMouse_Clicado GaMostrarResultado Acionamento_Cancelar Bt_Cancelar EvMouse_Clicado GaFechar_Janela

137

Estratégia #ACIH16. Cadastrar as ações de atribuição produzidas com o evento

Descrição

A ocorrência de um evento pode determinar a execução de ações de atribuição. Por

exemplo, a transferência de um valor digitado em uma caixa de texto para um atributo

de um objeto do CDP, a transferência de um valor de um atributo de um objeto para

uma caixa de texto, a execução de uma operação de um objeto, entre outros. Dessa

forma, registre no BDEC, as ações executadas em resposta a um evento capturado.


Exemplo

TABELA 4.40 - RELAÇÃO RELATRIBUIÇÃO

IdAtribuição IdMetafora IdPropriedade_TM IdObjeto IdOperação IdGrupo_Ação

AtribAutor Ct_Autor Valor ObLivro Set_Autor GaMostrarResultadAtribTitulo Ct_Titulo Valor ObLivro Set_Titulo GaProcurar AtribProcurar ObLivro Procurar GaProcurar

Estratégia #ACIH17. Cadastrar os eventos gerados em resposta ao evento ocorrido

Descrição

Especializando para o Sistema de Janelas do Windows, o mesmo requer ao enviar um

evento para uma metáfora, valores para dois argumentos. Esses argumentos variam de

acordo com o evento, e seus valores podem ser constantes ou obtidos a partir da

chamada de algum método de um objeto.

Por exemplo, o evento Wm_Close pode ser enviado para uma janela para fechá-la:

• primeiro argumento: um valor nulo;

• segundo argumento: um valor nulo.

Dessa forma, registre no BDEC, os eventos gerados em resposta a um evento capturado.

138

TABELA 4.41 - RELAÇÃO RELEVENTO_GERADO

IdEvento_Gerado IdMetafora_IH IdEvento_Wn IdGrupo_Ação Fechamento_Janela Jn_Consulta Wm_Close GaFechar_Janela

TABELA 4.42 - RELAÇÃO RELCOMPLEMENTO_WN

IdComplemento_Wn Tipo Número 1 Argumento 1 2 Argumento 2

IdObjeto IdOperação Valor IdEvento_Gerado

0 Fechamento_Janela 0 Fechamento_Janela

4.4 - A Prototipação do CIH

Durante este trabalho de pesquisa, foram construídos protótipos operacionais para

permitir a alimentação do BDEC com os metadados do CDP e CIH, e para realizar a

carga de uma aplicação baseada em SOFTBOARD.

Os seguintes objetivos nortearam a prototipação:

• validar o modelo de metadados do CIH, conforme apresentado na seção 4.2;

• validar as estratégias de alimentação propostas, conforme apresentado na seção 4.3;

• apresentar a interface configurada, diferentemente, para cada classe de usuário

informada;

• criar metáforas em tempo de execução;

• alterar as propriedades das metáforas em tempo de execução;

• aplicar os recursos de redimensionamento e movimentação;

• capturar os eventos do Sistema de Janelas e ativar métodos dos objetos instanciados

em um determinado cenário;

• gerar eventos para o Sistema de Janelas.

139

Para atender aos objetivos, duas implementações foram realizadas: um protótipo que

permitiu a alimentação do BDEC com os metadados do CDP e CIH, e um outro que

usa esses metadados para criar a interface configurável das aplicações baseadas em

SOFTBOARD. A descrição de ambos encontra-se no Apêndice B.

4.4.1 - Resultados da Prototipação

A experiência da prototipação foi extremamente válida. Os objetivos que nortearam a

construção dos protótipos foram atingidos, o que permitiu obter alguns resultados

diretos:

• o modelo de metadados necessários para o CIH foi bastante apurado, a partir dos

retornos obtidos com as implementações;

• os requisitos para o CIH configurável, 1) a interface deve ser apresentada segundo

as características e experiência dos usuários, e 2) que ela possa ser modificada ou

reorganizada para atender as necessidades particulares de cada usuário, são

possíveis de serem atendidos.

• Inicialmente, a interface foi apresentada segundo a classificação do usuário, e

posteriormente, com o uso dos recursos (movimentação e redimensionamento) a

mesma foi personalizada pelo próprio usuário. Esta personalização é persistente e é

recuperada quando do próximo uso do sistema.

141

CAPÍTULO 5

CONCLUSÃO

Nas primeiras décadas do desenvolvimento de sistemas de software, os próprios

desenvolvedores das aplicações eram os usuários. A experiência e a alta motivação

justificavam a aceitação de interfaces humano-computador complexas. Hoje em dia, o

uso de computadores pela sociedade cresce continuamente. Cada vez mais, pessoas não

especializadas em computação usam essas máquinas como meio para os mais diversos

fins.

Dada a diversidade da população de usuários, a experiência do desenvolvedor não mais

se casa com a dos usuários que utilizam seus sistemas. Portanto, o uso de seu próprio

julgamento para construir uma interface pode ser totalmente equivocado.

Ao se estabelecer estratégias e padrões para a modelagem da interface humano-

computador dos sistemas baseados em SOFTBOARD, contribui-se para que o

desenvolvimento da mesma seja mais efetivo e sistemático.

Os desenvolvedores podem se orientar sobre os modelos que devem ser construídos

para produzirem sistemas com maior usabilidade, aspecto este que determina a

qualidade da interação humano-computador, fornecida pela interface. Verificou-se que

para atingir essa qualidade é preciso conhecer os usuários em potencial, analisar suas

tarefas, definir metas de usabilidade a serem buscadas durante o desenvolvimento,

aplicar diretrizes conhecidas para a interação, especificar a interface e, finalmente,

avaliá-la. Tudo dentro de um processo iterativo e incremental.

Dentro da abordagem de desenvolvimento de Cunha (1997) para a melhoria da

qualidade dos sistemas de software e produtividade dos desenvolvedores, também foi

definido o modelo de metadados que permite a configuração do CIH da arquitetura

SOFTBOARD. Por meio de estratégias, estabeleceu-se como deve ser a alimentação

desses metadados no BDEC. A partir deste, é gerado o Catálogo que é utilizado pelo

CMOOS para adaptar o CIH configurável ao CDP do sistema.

Com a prototipação, o modelo de metadados necessários para o CIH foi bastante

apurado. Constatou-se que o mesmo suporta as estratégias propostas para a modelagem

142

da interface. Verificou-se que os requisitos para o CIH, 1) a interface deve ser

apresentada segundo as características e experiência dos usuários e 2) que ela possa ser

modificada ou reorganizada para atender às necessidades particulares de cada usuário,

são possíveis de serem atendidos com o modelo de metadados proposto.

A SOFTBOARD é uma arquitetura que possibilita um aumento na qualidade dos

sistemas de software desenvolvidos e a melhoria na produtividade das equipes de

desenvolvimento. Para um novo sistema, apenas a essência do mesmo é desenvolvida.

Quanto aos usuários, a SOFTBOARD possibilita maior flexibilidade de uso pois aceita

as diversas classes de usuários e permite que a interface seja personalizada. Além disso,

sistemas podem ter um tempo menor de desenvolvimento, possibilitando atender aos

usuários com presteza e poucos gastos.

Espera-se que as estratégias e padrões propostos neste trabalho, possam ser utilizados

para a modelagem e configuração da interface humano-computador dos sistemas

baseados em SOFTBOARD. Contudo, reconhece-se que existem outras teorias e

técnicas que contribuem para o desenvolvimento de interfaces que aqui não foram

usadas.

Também se espera que, com novas descobertas sobre o que faz os sistemas serem mais

ou menos fáceis de serem aprendidos, o que os torna mais eficientes nas mãos dos

usuários, o que pode ser feito para maximizar seus efeitos desejáveis e minimizar os

efeitos desagradáveis, estas estratégias e padrões possam ser complementados.

Como sugestão para trabalhos futuros, espera-se que sejam modelados os componentes

CMOOS e CGC da SOFTBOARD, e também que se construa um ambiente de

desenvolvimento capaz de produzir sistemas de software baseados nessa arquitetura.

143

REFERÊNCIAS BIBLIOGRÁFICAS

ACM SIGHI Curricula for human-computer interaction. Nova York, 1992.

Ambler, S. Building object application that work. Cambridge University Press,

1998. 476 p.

Apple Computer Macintosh human interface guidelines. Reading: Addison-Wesley,

1993.

Bodker, S. Through the interface. Hillsdale: Lawrence Erlbaum Associates, 1991.

Booch, G. Object oriented analysis and design with applications. 2. ed. Reading:

Addison-Wesley, 1994.

Booch, G.; Rumbaugh, J.; Jacobson, I. UML: guia do usuário. Rio de Janeiro:

Campus, 2000. 472 p.

Card, S. K.; Moran, T.; Newell, A. The psychology of human-computer interaction.

Hillsdale: Lawrence Erlbaum Associates, 1983. 469 p.

Coad, P.; Yourdon, E. Análise baseada em objetos. 2. ed. Rio de Janeiro: Campus,

1992. 225 p.

____ Projeto baseado em objetos. Rio de Janeiro: Campus, 1993. 195 p.

Coad, P.; North, D.; Mayfield, M. Objects models: strategies, patterns & applications.

Upper Saddle River: Prentice-Hall, 1995. 505 p.

Constantine, L.; Lockwood, L. Software for use. Reading: Addison-Wesley, 1999.

582 p.

Cottini, L.T. Estratégias e padrões para modelagem de banco de dados para

sistemas baseados na arquitetura SOFTBOARD. São José dos Campos.

Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas

Espaciais, 1999.

Cunha, J. B. S. Uma abordagem de desenvolvimento de software para a melhoria

da qualidade e da produtividade. São José dos Campos. 176 p. Tese (Doutorado

em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, 1997.

144

Dias, A. S. Estratégias e padrões para o desenvolvimento de sistemas de software

baseados em SOFTBOARD. São José dos Campos. 278 p. Dissertação (Mestrado

em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais, 1999.

Eriksson, H.; Penker, M. UML toolkit. Nova York: John Wiley & Sons, 1998. 397 p.

Fiorini, S.T.; Staa, A.V.; Baptista, R.M. Engenharia de software com CMM. Rio de

Janeiro: Brasport livros e multimídia, 1998. 346 p.

Furlan, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books,

1998. 329 p.

Gamma, E.; Helm, R.; Johnson, R.;Vlissides, J. Design patterns. Reading: Addison-

Wesley, 1995. 395 p.

Hay, D. C. Princípios de modelagem de dados. São Paulo: Makron Books, 1999.

271 p.

Hix D.; Hartson, R.H. Developing user interfaces. Nova York: John Wiley and Sons,

1993. 381 p.

Horrocks, I. Constructing the user interface with statecharts. Reading: Addison-

Wesley, 1999. 250 p.

Humphrey, W. S. A personal commitment to software quality. [online].

<http://www.sei.cmu.edu/pub/documents/articles/pdf/psp.swe.pdf>. Mar. 2001.

Jacobson, I.; Booch, G.; Rumbaugh, J. The unified software development process.

Reading: Addison-Wesley, 1999. 463 p.

Kieras, D. A guide to GOMS model usability evaluation using NGOMSL. In:

Helander, M.; Landauer, T.; Prabhu, P. ed. Handbook of human-computer

interaction. 2 ed. North-Holand, 1997. Cap.31, p. 733-766.

____ Using the keystroke-level model to estimate execution times. [online]. <URL:

ftp.eecs.umich.edu/people/kieras/GOMS/KLM.pdf>. May 2001.

Laboratório de Utilizabilidade (LabIUtil). Ergonomia de interfaces humano-

computador. [online]. <http://www.labiutil.ufsc.br>. Dez. 2000.

http://www.sei.cmu.edu/pub/documents/articles/pdf/psp.swe.pdf

http://www.labiutil.ufsc.br

145

Leite, J. C. Modelos e formalismos para a engenharia semiótica de interfaces de

usuário. Rio de Janeiro. 205 p. Tese (Doutorado em Informática) – Pontifícia

Universidade Católica do Rio de Janeiro, 1998.

Lucena, F; Liesenberg, H. Interfaces homem-computador. [online].

<http://www.dcc.unicamp.br/proj-xchart/start.htm>. Out. 1999.

Marcus, A. Graphical user interfaces. In: Helander, M.; Landauer, T.; Prabhu, P. ed.

Handbook of human-computer interaction. 2 ed. North-Holand, 1997. Cap. 19,

p. 423-440.

Martin, R. Patterns. [online]. <http://www.oma.com/pdf/Plop.pdf>. Aug. 1998.

Microsoft The windows interface – an application design guide. Microsoft Press,

1992.

Myers, B. A. UIMSs, toolkits, interface builders. [online]. <http://www.cs.cmu.edu

/~bam>. Jun. 2000.

Norman, D. Cognitive Engineering. In: Norman, D.; Draper, S. ed. User centered

systems design. Hillsdale: Lawrence Erlbaum Associates, 1986. p. 31-61.

____ The psychology of everyday things. Nova York: Basic Books, 1988. 257 p.

Open Software Foundation (OSF) Motif style guide. Englewood Cliffs: Prentice-Hall,

1990.

Paap, K. R.; Cooke, N. J. Design of menus. In: Helander, M.; Landauer, T.; Prabhu, P.

ed. Handbook of human-computer interaction. 2 ed. North-Holand, 1997. Cap.

24, p. 533-572.

Paula, W.P. Engenharia de software: fundamentos, métodos e padrões. Rio de

Janeiro: LTC, 2001. 581 p.

Prabhu, P.V.; Prabhu, G.V. Human error and user-interface design. In: Helander, M.;

Landauer, T.; Prabhu, P. ed. Handbook of human-computer interaction. 2 ed.

North-Holand, 1997. Cap. 22, p. 489-501.

http://www.dcc.unicamp.br/proj-xchart/start.htm

http://www.oma.com/pdf/Plop.pdf

http://www.cs.cmu.edu

146

Preece, J.; Sharp, H.; Benyon, D.; Holland, S.; Carey, T. Human-computer

interaction. Reading: Addison-Wesley, 1994. 775 p.

Quercia, V.; O’Reilly, T. X window system user’s guide. Sebastopol: O’Reilly &

Associates, 1991.

Rettig, M. Prototyping for tiny fingers. Communications of the ACM, v. 37, n. 4., p.

21-27, Abr. 1994.

Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen, W. Object-oriented

modeling and design. Englewood Cliffs: Prentice-Hall, 1991. 528 p.

Setzer, V.W. Bancos de dados: conceitos, modelos, gerenciadores, projeto lógico,

projeto físico. 3 ed. São Paulo: Edgard Blücher Ltda., 1995. 289 p.

Software Engineering Institute (SEI). User interface technology survey. Pittsburgh:

SEI, 1987. (CMU/SEI-87-TR-6).

Sommerville, I. Software engineering. 5 ed. Reading: Addison Wesley, 1995.

Souza, G. J. Interface configurável. São José dos Campos. 126 p. Dissertação

(Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas Espaciais,

1997.

Souza, C. S.; Leite, J. C.; Prates, R. O.; Barbosa, S. D. Projeto de interface de usuário:

perspectivas cognitivas e semióticas. In: Congresso da Sociedade Brasileira de

Computação, 19. Anais. Rio de Janeiro: Edições EntreLugar, 1999.

Shneiderman, B. Designing the user interface. 3. ed. Reading: Addison Wesley,

1998. 638 p.

Tullis, T. S. Screen design. In: Helander, M.; Landauer, T.; Prabhu, P. ed. Handbook

of human-computer interaction. 2 ed. North-Holand, 1997. Cap. 23, p. 503-531.

Yourdon, E. Análise estruturada moderna. Rio de Janeiro: Editora Campus, 1990.

836 p.

147

APÊNDICE A

BIBLIOGRAFIA COMPLEMENTAR

Azevedo, D. Interação Configurável Entre/Intra Sistemas. São José dos Campos.

Dissertação (Mestrado em Computação Aplicada) - Instituto Nacional de Pesquisas

Espaciais, 2001.

Ferreira, M. G. V. Componente gerenciador de dados configurável. São José dos

Campos. 126 p. Dissertação (Mestrado em Computação Aplicada) - Instituto

Nacional de Pesquisas Espaciais, 1996.

Pressman, R. Engenharia de software. São Paulo: Makron Books, 1995. 1056 p.

Wixon,D.; Wilson, C. The usability engineering framework for product design an

evaluation. In: Helander, M.; Landauer, T.; Prabhu, P. ed. Handbook of human-

computer interaction. 2 ed. North-Holand, 1997. Cap. 27, p. 653-688.

149

APÊNDICE B

PROTÓTIPO

1. Abordagem Inicial

Segundo Coad e Yourdon (1993), se o domínio do problema estiver bem

compreendido, e se o método de análise de requisitos for eficaz, e se os usuários e

desenvolvedores se comunicarem de modo eficiente, um modelo de requisitos pode ser

acurado, pronto para ser submetido aos projetistas e programadores. Infelizmente, esses

“se” são problemáticos: o domínio do problema pode estar pobremente compreendido,

o método de análise de requisitos pode não ser o melhor, e os usuários e analistas

podem ser incapazes de se comunicarem.

Uma solução capaz de minimizar esses problemas consiste na construção de vários tipos

de protótipos. Um protótipo é uma aplicação, normalmente experimental e incompleta,

que permite aos desenvolvedores avaliarem suas decisões durante o desenvolvimento do

sistema de software.

A prototipação operacional é usada para (Coad e Yourdon, 1993):

• construir uma demonstração funcional e obter um retorno crítico dos usuários;

• ter algo com que se trabalhar, alguma coisa mais tangível do que diagramas;

• descobrir logo no início onde estarão as partes mais complicadas do sistema;

• descobrir requisitos esquecidos e assim apurar o modelo.

Com essas expectativas, durante este trabalho de pesquisa, foram construídos

protótipos para permitir a alimentação do BDEC com os metadados do CDP e CIH, e

para realizar a carga de uma aplicação baseada em SOFTBOARD.

Os protótipos são detalhados a seguir.

2. Desenvolvimento

2.1 O Gerador

O Gerador é o protótipo que permitiu a alimentação do BDEC com os metadados do

150

CDP e CIH para uma determinada aplicação baseada em SOFTBOARD.

O Gerador foi implementado na linguagem Borland Delphi, usando a biblioteca VCL,

baseada no padrão de interface Windows.

O modelo relacional, apresentado no Capítulo 4, foi utilizado para a criação das tabelas

para armazenamento dos metadados.

A seguir são apresentadas algumas janelas da interface humano-computador do

Gerador.

As Figuras B.1 e B.2 apresentam o mapa de menus do protótipo.

Fig. B.1 - Mapa de menus com os metadados do CDP.

151

Fig. B.2 - Mapa de menus com os metadados do CIH.

A Figura B.3 apresenta a janela para alimentação dos metadados, que corresponde às

estratégias #ACDP1,#ACDP2, #ACIH1.

Fig. B.3 - Alimentação dos metadados Modelo OO e Componente_SB.


152

estratégias #ACDP3, #ACDP4, #ACDP5.

Fig. B.4 - Alimentação dos metadados Classe, Atributo e Operação.


estratégias #ACIH10 e #ACIH11.

Fig. B.5 - Alimentação dos metadados Colaboração e Objeto.

153

As Figuras B.6 e B.7 apresentam as janelas para alimentação dos metadados, que

corresponde à estratégia #ACIH12.

Fig. B.6 - Alimentação dos metadados Metafora_IH.

Fig. B.7 - Alimentação dos metadados Propriedade da Metáfora.

A Figura B.8 apresenta a janela para alimentação dos metadados, que corresponde à

154

estratégia #ACIH15.

Fig. B.8 - Alimentação dos metadados Evento_Capturado.


estratégias #ACIH16 e #ACIH17.

Fig. B.9 - Alimentação dos metadados Atribuição e Evento Gerado.

155

A Figura B.10 apresenta a geração do Catálogo, a partir do BDEC, para ser usado pelo

Protótipo-CIH.

Fig. B.10 - Geração do Catálogo.

2.2 O Protótipo-CIH

O Protótipo-CIH é o protótipo que, efetivamente, simula uma parte do ambiente de uma

aplicação baseada em SOFTBOARD.

Esse protótipo foi implementado na linguagem Borland C++ e usa os próprios

elementos pré-definidos do Windows (Window, Button, Text, etc.) para a criação da

interface.

O protótipo também usa o Catálogo, gerado com os metadados alimentados no BDEC,

para realizar a carga da aplicação e para montar seus diversos cenários.

Conforme apresentado na Figura B.11, inicialmente, escolhe-se para uso uma das

aplicações registradas no Catálogo. Após a escolha, é necessária a identificação do

usuário.

156

Fig. B.11 - Escolha da aplicação e identificação do usuário.

Com a identificação, o CGC busca no Catálogo pela configuração personalizada para o

usuário. Caso encontre, o cenário é montado com base nessa configuração. Caso

contrário, o cenário é montado de acordo com a classe do usuário. A Figura B.12

apresenta o cenário Consultar Acervo.

Fig. B.12 - Consulta ao acervo.

Como recursos para personalização, o protótipo possui a possibilidade de mover um

determinado elemento da interface e redimensionar o tamanho de cada um. Para manter

a consistência com o padrão de interface Windows, tais recursos foram colocados no

menu do sistema, junto às opções para a janela: Restaurar, Mover, Redimensionar o

157

tamanho, Minimizar, Maximizar e Fechar. A Figura B.13 apresenta os recursos

colocados como opções no menu.

Fig. B.13 - Recurso Mover elemento.

Selecionada a opção ‘Mover elemento’ (Figura B.13), o usuário pode escolher qualquer

um dos elementos da interface para movê-lo para uma outra posição.

Na Figura B.14a, o botão Buscar foi selecionado. A partir daí, mantendo o botão do

mouse pressionado, o mesmo foi arrastado para uma nova posição, conforme mostrado

na Figura B.14b.

Fig. B.14 - Movimentação do elemento.

(a) (b)

158

Selecionada a opção ‘Tamanho do elemento’ (Figura B.15), o usuário pode definir um

novo tamanho para qualquer um dos elementos da interface. Na Figura B.16a, o botão

Buscar foi selecionado para ser redimensionado. A partir daí, clicando sobre qualquer

uma das ancoras que envolvem o elemento, o usuário pode redimensioná-lo, conforme

mostrado na Figura B.16b.

Fig. B.15 - Recurso Redimensionar elemento.

Fig. B.16 - Redimensionamento do elemento.

(a) (b)

159

APÊNDICE C

DIAGRAMAS DA UML

1. Diagrama de Casos de Uso

Um diagrama de casos de uso exibe um conjunto de casos de uso, atores e seus

relacionamentos. Esse diagrama ajuda a definir o que existe externamente ao sistema

(atores) e quais funções do sistema estão disponíveis para uso (casos de uso).

No diagrama, o sistema é representado por um retângulo; o ator é representado pelo

símbolo de uma pessoa fora do retângulo, enquanto que o caso de uso é representado

por uma elipse, colocada dentro do retângulo. Uma linha entre o ator e o caso de uso

representa uma associação entre ambos.

A Figura C.1 apresenta a notação para o diagrama. de casos de uso

Fig. C.1 - Notação simplificada para o Diagrama de Casos de Uso.

Fig. C.1 - Notação para o diagrama de casos de uso. FONTE: Booch et al. (2000).

2. Diagrama de Classes

Um diagrama de classes representa a estrutura estática do sistema. Ele exibe as classes,

suas estruturas internas (atributos e operações) e seus relacionamentos.

A Figura C.2 apresenta a notação para o diagrama.

nome do ator

nome do sistema

nome da associação

fronteira do sistema

caso de uso

ator caso de uso1

160

Fig. C.2 - Notação para o diagrama de classes. FONTE: Booch et al. (2000).

3. Diagramas de Interação

O diagrama de interação modela os aspectos dinâmicos do sistema. Uma interação é um

comportamento que compreende um conjunto de mensagens trocadas entre um conjunto

de objetos em um determinado contexto para a realização de um propósito, tal qual a

realização de um caso de uso.

A UML propõe dois tipos de diagramas de interação: de Colaboração e de Seqüência.

3.1 Diagrama de Colaboração

O diagrama de colaboração é um diagrama de interação cuja ênfase está na organização

estrutural dos objetos que enviam e recebem mensagens.

Conforme ilustra a Figura C.3, os diversos objetos que compõem a interação são

representados por retângulos; as linhas entre os objetos representam vínculos entre eles.

nome da classe

nome do atributo

nome da operação

associação

restrição de associação

1 um e somente um 0..1 zero ou um 0..* zero ou mais 1..* um ou mais

generalização

Agregação

classe1 atributo operação

classe3

classe4

classe5

1 0..* classe2


restrição ou

161

Setas de mensagens são desenhadas entre os objetos para mostrar o fluxo de mensagens.

A ordem temporal de uma mensagem é indicada por um número, aumentando

unitariamente para cada nova mensagem no fluxo de controle.

Fig. C.3 - Notação para o diagrama de colaboração. FONTE: Booch et al. (2000).

3.2 Diagrama de Seqüência

Um diagrama de seqüência é um diagrama de interação cuja ênfase está na ordenação

temporal das mensagens.

Conforme ilustra a Figura C.4, um diagrama de seqüência é formado colocando-se os

objetos que participam da interação no nível superior do diagrama, ao longo do eixo X.

A seguir as mensagens que esses objetos enviam e recebem são colocadas ao longo do

eixo Y, em ordem crescente de tempo, de cima para baixo. A linha de vida do objeto é

a linha tracejada vertical que representa a existência de um objeto em um período de

tempo. O foco de controle é um retângulo alto e estreito, que mostra o período durante o

qual um objeto está desempenhando uma ação. A parte superior do retângulo é alinhada

com o início da ação; a parte inferior é alinhada com sua conclusão.

o1:classe1

o2:classe2

1: operação (lista de parâmetros)

objeto: nome da classe

sentido do fluxo demensagem vínculo

162

Fig. C.4 - Notação para o diagrama de seqüência. FONTE: Booch et al. (2000).

3. Diagrama de Gráfico de Estado

Um diagrama de gráfico de estados exibe uma máquina de estados formada por estados,

transições, eventos e ações. São importantes principalmente para a modelagem de

comportamentos de uma classe ou colaboração e para dar ênfase a comportamentos de

um objeto ordenado por eventos.

O diagrama possui um ponto de início (estado inicial) e vários pontos de finalização

(estados finais). Um ponto de início é representado por um círculo todo preenchido, e

um ponto de finalização é representado por um círculo em volta de um outro círculo

menor preenchido. Os estados são representados por retângulos com cantos

arredondados. As setas representam transições, progressões que ocorrem de um estado

para outro. As setas são rotuladas com o nome do evento que causa a transição de um

estado para outro.


o1:classe1

o2:classe2

operação(lista de parâmetros)

objeto:nome da classe

foco de controle linha de vida

163

Fig. C.5 - Notação para o diagrama de gráfico de estado. FONTE: Booch et al. (2000). 5. Diagrama de Componente

Um diagrama de componente exibe as organizações e dependências existentes entre um

conjunto de componentes. Alguns componentes são a implementação, na arquitetura

física, dos conceitos e da funcionalidade definida na arquitetura lógica (classes e seus

relacionamentos).

Neste diagrama, um componente é mostrado como um retângulo com dois retângulos

menores do seu lado esquerdo. O nome do componente é escrito acima ou dentro do

símbolo. Uma seta tracejada representa a dependência entre os componentes,

significando que um componente precisa do outro para possuir uma definição completa.


Fig. C.6 - Notação para o diagrama de componente. FONTE: Booch et al. (2000).

componente2

componente1

componente

Relacionamento de dependência

1

estado1

2 estado2

estado transição nome do evento /

nome da ação

estado inicial estado final

assinatura do evento [condição de guarda] / expressão de ação nome do estado

entrar:ação-entrada fazer:ação sair: ação-saída

164

6. Diagrama de Implantação

Um diagrama de implantação exibe nós conectados por associações. Um nó consiste

em um objeto físico que representa um recurso, geralmente possuindo pelo menos uma

memória e capacidade de processamento.

Neste diagrama, um nó é representado por um cubo. As associações entre os nós são

representadas por linhas. Instâncias de componentes e objetos podem estar contidos

dentro dos símbolos que representam o nó, a fim de mostrar quais unidades de software

são executadas dentro de cada um.


Fig. C.7 - Notação para o diagrama de implantação. FONTE: Booch et al. (2000).

7. Notação da Colaboração

Fig. C.8 - Notação da colaboração. FONTE: Booch et al. (2000).

nó2

nó1

nó

nome da associação

conexão

Sistema

caso de uso1 Colaboração1

Colaboração

165

APÊNDICE D

DIAGRAMAS DO SISTEMA SIMPLIFICADO DE BIBLIOTECA

Fig. D.1 - Diagrama de casos de uso.

Fig. D.2 - Diagrama de classes.

Cliente da Biblioteca


Bibliotecário

Consultar acervo mais emprestados por cliente

Assistente da Biblioteca Diretor

Cadastrar acervo


Consultar acervo

Periódico Nome Número Mês_Publicaçao Volume

Item_Reserva Data_Disponibilidade

Acervo

Número_Empréstimo

Registro Número_Reserva

1 1

0..*

Exemplar NúmeroAno_Publicação Situação

Livro

Edição

1

1..*

Reserva Data_Reserva

1 1

1..*

Pessoa Nome_Pessoa Endereço Telefones

Biblioteca Nome_Biblioteca

1 1..*1..*

Item_EmpréstimoData_Devolução

1

0..*

Cliente da Biblioteca Registro

1

0..*

1

0..*

0..1 1

1..* 1

EmpréstimoData_Empréstimo

1

1..*

1

1..*

1 0..*0..*

Possui Pertence

Possui

Pertence

Podefazer

Feito por

Pode ser

É uma

Pode fazer

É feito por

ContémPossui

Pertence

Participa

Participa

Contém

Data_Último_Empréstimo

Procurar Set_Autor Get_Autor Set_Titulo Get_Titulo

ISBN Título Autor

166

Fig. D.3 - Realização do caso de uso Consultar acervo.

Fig. D.4 - Diagrama de seqüência para a colaboração.

Jn_Consulta

:Janela : Assistente

Set_Título

Set_Autor

Procurar

Digitar título

obLivro:Livro

Digitar autor

Pressionar botão

Assistente


Consultar acervo

Consultar_Acervo_Nv.

167

Fig. D.5 - Diagrama de gráfico de estado para a colaboração.

Cenário: Janela Principal 1

Esperando escolha

Botão Cancelar clicado ou Janela fechada

Cenário: Consulta Acervo

Opção consulta clicada

Janela fechada

2 Esperando entrada de dados

3 Pronto para consulta

Botão Buscar clicado / obLivro.SetAutor, oblivro.SetTitulo, oblivro.Procurar

Autor ou Título digitado

Cenário: Result. Pesquisa 4

Apresentando resultado

Janela fechada

169

APÊNDICE E

NOTAÇÃO CASE*METHOD

Fig. D.1 - Notação simplificada do Case*Method. Adaptada de Hay (1999).

Fig. E.1 - Notação simplificada do diagrama Case*Method. FONTE: Adaptada de Hay (1999).

GENERALIZAÇÃO

#Chave primária Atributo

ESPECIALIZAÇÃO 1 #Chave primária

Atributo Chave estrangeira

ESPECIALIZAÇÃO n #Chave primária Atributo Chave estrangeira

RELAÇÃO # Chave primária Atributos



ou exclusivo Associação


um e somente um

zero ou um

zero ou mais

um ou mais

PARTE-ESPECIALIZAÇÃO n #Chave primária Atributos Chave estrangeira

Estrutura Todo-Parte

171

APÊNDICE F

DIFERENÇAS ENTRE COMBINAÇÕES DE CORES

TABELA F.1 - DIFERENÇAS NOS VALORES DE CINZA EM UMA PALETA VGA PARA WINDOWS

Cor de frente Cl. Esc. Cl. Cl. Cl. Cl. Cl. Cl.

Preto Azul Verde Ciano Ver. Mag. Mar. Cinza Azul Verde Ciano Ver. Mag. Mar Bra.

Preto 0 15 75 90 38 53 113 192 128 29 150 179 76 105 226 255

Azul 15 0 60 75 23 38 98 177 113 14 135 164 61 90 211 240

Verde 75 60 0 15 37 22 38 117 53 46 75 104 1 30 151 180

Ciano 90 75 15 0 52 37 23 102 38 61 60 89 14 15 136 165

Verm. 38 23 37 52 0 15 75 154 90 9 112 141 38 67 188 217

Mag. 53 38 22 37 15 0 60 139 75 24 97 126 23 52 173 202

Marrom 113 98 38 23 75 60 0 79 15 84 37 66 37 8 113 142

Cinza claro

192 177 117 102 154 139 79 0 64 163 42 13 116 87 34 63

Cinza esc.

128 113 53 38 90 75 15 64 0 99 22 51 52 23 98 127

Azul claro

29 14 46 61 9 24 84 163 99 0 121 150 47 76 197 226

Verde claro

150 135 75 60 112 97 37 42 22 121 0 29 174 45 76 105

Ciano claro

179 164 104 89 141 126 66 13 51 150 29 0 103 74 47 76

Verm. Claro

76 61 1 14 38 23 37 116 52 47 74 103 0 29 150 179

Mag. Claro

105 90 30 15 67 52 8 87 23 76 45 74 29 0 121 150

Amar. 226 211 151 136 188 173 113 34 98 197 76 47 150 121 0 29

Cor

de

fund

o

Branco 255 240 180 165 217 202 142 63 127 226 105 76 179 150 29 0

FONTE: Tullis (1997, p. 522).

ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DA...

Documents

Transcript of ESTRATÉGIAS E PADRÕES PARA A MODELAGEM DA...