uma linguagem visual para descrição de use cases. · uma linguagem visual para descrição de use...

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E

DE COMPUTAÇÃO

Uma Linguagem Visual para Descrição de UseCases.

Alessandro José de Souza

Orientador: Prof. Dr. Anderson Luiz de Oliveira Cavalcanti

Tese de Doutorado apresentada ao Pro-grama de Pós-Graduação em EngenhariaElétrica e de Computação da UniversidadeFederal do Rio Grande do Norte - UFRNcomo parte dos requisitos para obtenção dotítulo de Doutor em Ciências.

Número de ordem PPgEE: D165Natal, RN, maio de 2016.

Seção de Informação e Referência

Catalogação da publicação na fonte. UFRN / Biblioteca Central Zila Mamede

Souza, Alessandro José de.Uma Linguagem Visual para Descrição de Use Cases / Alessandro José de

Souza. - Natal, 2016.137f: il.

Orientador: Anderson Luiz de Oliveira Cavalcanti.

Tese (Doutorado) - Universidade Federal do Rio Grande do Norte. Centro deTecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de Compu-tação.

1. Engenharia de Requisitos. 2. Engenharia de Software. 3. InteraçãoHumano-Computador. 4. Modelo de Interação. I. Cavalcanti, Anderson Luiz deOliveira. II. Título.

Uma Linguagem Visual para Descrição de UseCases.

Alessandro José de Souza

Tese de Doutorado aprovada em 06 de maio de 2016 pela banca examinadora compostapelos seguintes membros:

Prof. Dr. Anderson Luiz de Oliveira Cavalcanti (orientador) . . . . . DCA/UFRN

Profa Dra Claudia Maria Fernandes Araújo Ribeiro . . . . . . . . . . . . . . . . . . . . IFRN

Prof. Dr. Raimundo Santos Moura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UFPI

Prof. Dr. Bruno Santana da Silva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMD/UFRN

Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira . . . . . . . . . . DCA/UFRN

“Tudo o que sei é que nadasei.”(SÓCRATES)

Agradecimentos

Primeiro de tudo, gostaria de agradecer ao Pai a quem chamamos de Deus - criador do céue da terra, das coisas visíveis e invisíveis - por me guiar nesta caminhada que só Ele e eusabemos intimamente o quanto foi difícil. Ao mesmo tempo peço perdão pelos momentosem que me deixei “abater” e pensar em desistir. Este foram momentos de fraqueza ondedeixei que as forças terrenas sobrepusessem aos seus ensinamentos divinos.

Agradeço a meus pais, que mesmo sem terem a oportunidade de estudar, por questõessociais, souberam me orientar quanto as maravilhas e riscos que o estudo colocaria emminha vida. Obrigado meu pai e minha mãe e desculpe pelas minhas faltas e momentosde afastamento para estudo.

Quero agradecer a minha “irmãzinha”(Alessandra Souza) que sempre esteve na torcidapor essa e outras conquistas e meu cunhado José Álvaro, que me levou aos grupos depesquisa do DCA/UFRN onde finalizei meu mestrado e agora doutorado.

Agradeço, também, a meu grande amigo Macilon, pessoa que convivi intensamente naprimeira tentativa de doutoramento. Posso dizer que Macilon faz parte da minha família,pessoa simples mas de muitas virtudes - Um grande Homem. Gostaria de ter finalizado odoutorado com você meu “Brother”, mas mesmo com exemplo claro de perseverança quevocê demostrava naquele momento, infelizmente não consegui ter o mesmo. ParabénsDoutor Macilon, você é o cara, e sabes porquê.

Agradeço ao meu orientador Anderson Luiz pela oportunidade e confiança. Não é todoorientador que tem a coragem de receber um orientando que acabara de sair de outroprograma de pós-graduação. Aliás, coragem é o que não falta a você! Sucesso em suacarreira profissional!!

Também não posso deixa de agradecer a todos os colegas do IFRN em especial ao profes-sor José de Ribamar que conhecedor de todo processo sempre me incentivou a concluiresta etapa profissional. Ao professor Gustavo Fontoura que dedicou tempos preciosospara ajudar na parte estatística desta tese. Meu muito obrigado.

Por último, mas não menos importante quero apresentar meus agradecimentos a duas daspessoas mais próximas de mim, minha esposa Alessandra Leite e minha filha Thaís Leite(Tatá). A minha querida esposa e companheira não quero agradecer apenas as dezenas derevisões gramaticais sobre os textos dos artigos, dissertação de mestrado e agora tese dedoutorado, mas por todos esses dias que esteve ao meu lado, me apoiando desde quandoera um aluno concluinte do curso técnico de mecânica da então ETFERN. Você sempre

foi e será fonte de expiração para tudo que faço. Obrigado por estar sempre ao meu ladoe por compartilhar comigo a maior riqueza que temos, nossa filha Thaís. Talvez você nãoentenda agora Thaís, tive que estar um pouco afastado do convívio familiar por questõesde estudo e trabalho, mas tudo foi pensando não só no presente, mas no seu futuro. Quepossamos a partir de agora ter uma convivência maior, eu, você e sua mãe. Obrigado porexistirem em minha vida.

Resumo

Para que se possa obter sucesso no desenvolvimento de um projeto de software, é ne-

cessário conhecer seus requisitos, sejam eles funcionais ou não-funcionais (atributos de

qualidade). Nesse sentido, os use cases têm sido amplamente adotados pelos profissionais

de engenharia de software como uma das ferramentas para elicitação e análise de requi-

sitos. No entanto, sua forma fragmentada e textual de descrição das funcionalidades do

sistema não tem sido suficiente para suscitar os interesses relacionados ao design de inter-

face do usuário. Este fato levou profissionais de interação humano-computador a criarem

seus próprios métodos e técnicas que, muitas vezes, contrapõem-se à filosofia usada por

engenheiros de software para modelagem da interação usuário-sistema. Por essa razão,

com o propósito de melhorar o suporte à descrição de use case integrado com o design

centrado no usuário, propõe-se a Visual Language for Use Case Description (VL4UCD).

Neste trabalho, é definido o uso da VL4UCD durante as tarefas de análise e validação

de requisitos, de forma a endereçar, ainda na fase inicial do projeto, as preocupações

de ambos os grupos (engenharia de software e interação humano-computador) sobre o

desenvolvimento de sistemas de software interativo.

Palavras-chave: Engenharia de Requisitos, Engenharia de Software, Interação Humano-

Computador, Modelo de Interação.

Abstract

In order to success during the development of a software project, it is necessary to

know its requirement, whether they are functional requirements or non-function require-

ments (quality attributes). In that direction, the use cases have been widely adopted by

both Software Engineering and Human-Computer Interaction professionals. However, its

fragmented and textual form of the system description has not been enough to provide

interest concerned to the user interface design. This fact has led human-computer inte-

raction professionals to create their own methods and techniques which often go in the

opposite the philosophy used by software engineers for modeling the user-system inte-

raction. Therefore, aiming to improve the support to use case description integrated with

the user centered-design, it is proposed the Visual Language for Use Case Description -

VL4UCD. In this work, it is defended the use of VL4UCD during the tasks of analysis and

requirement validation, of form to address, still in the initial project phase, the concerns

of both groups (software engineering and human-computer interaction) about of software

interactive system development.

Keywords: Requirements Engineering, Software Engineering, Human-Computer In-

teraction, Interaction Model.

Sumário

Sumário i

Lista de Figuras iv

Lista de Símbolos e Abreviaturas vii

Lista de Tabelas vii

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Fundamentação Teórica 7

2.1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Padrões de Design de interface . . . . . . . . . . . . . . . . . . . 13

2.2 Especificação de Software . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Modelos e Representações de Engenharia de Software . . . . . . . . . . 21

2.4 Modelos e Representações de Interação Humano-Computador . . . . . . 27

2.5 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Trabalhos Relacionados 34

3.1 UMLi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 MoLIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3 ALaDIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

i

3.4 Software architecture that supports usability (STATUS) . . . . . . . . . . 41

3.5 Usability-driven software architecture patterns . . . . . . . . . . . . . . . 43

3.6 Comparação entre notações . . . . . . . . . . . . . . . . . . . . . . . . . 44


4 VL4UCD: Notação e Ferramenta 47

4.1 Notação VL4UCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Projeto de Software e VL4UCD . . . . . . . . . . . . . . . . . . . . . . 53

4.3 Use Case Description Tool . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4 Contribuições da VL4UCD . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4.1 Atores, objetivo e condições de execução . . . . . . . . . . . . . 63

4.4.2 Regras de negócio . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.3 Associações de inclusão e extensão . . . . . . . . . . . . . . . . 65

4.5 Modelos VL4UCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66


5 Experimentos 73

5.1 Planejamento Experimental . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1.1 Contexto da Avaliação . . . . . . . . . . . . . . . . . . . . . . . 76

5.1.2 Instrumentação . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.1.3 Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.1.4 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.1.5 Procedimentos Experimentais . . . . . . . . . . . . . . . . . . . 81

5.2 Análise e Interpretação dos Resultados . . . . . . . . . . . . . . . . . . . 81

5.3 Validade do experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.3.1 Validade interna . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.3.2 Validade externa . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3.3 Validade de construção . . . . . . . . . . . . . . . . . . . . . . . 94

5.3.4 Validade de conclusão . . . . . . . . . . . . . . . . . . . . . . . 95


6 Considerações finais 97

6.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Referências bibliográficas 101

A Matriz de benefícios/táticas 108

B Imagens ampliadas do capítulo 4 110

C Questionário Demográfico 114

D Objeto Experimental 117

Lista de Figuras

2.1 Editor de configurações das preferências do MacOS . . . . . . . . . . . . 15

2.2 Editor de configurações do Gmail . . . . . . . . . . . . . . . . . . . . . 16

2.3 Processo de desenvolvimento da Engenharia de Usabilidade, extraído de

Barbosa & Silva (2010). . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Modelo simplificado de design de interação, extraído de Barbosa & Silva

(2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Use cases - Sistema de telefonia . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Fluxos de eventos de um use case. . . . . . . . . . . . . . . . . . . . . . 23

2.7 Use case base e sua extensão. . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8 Use case base com a inclusão. . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Modelo GOMS para tarefa de apagar arquivo. . . . . . . . . . . . . . . . 29

2.10 Exemplo de um modelo HTA, adaptado de Barbosa & da Silva (2010). . . 30

2.11 Exemplo de um modelo CTT, extraído de http://www.w3.org/2012/02/ctt/

W3C (2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1 Exemplo de um user interface diagram da UMLi. . . . . . . . . . . . . . 36

3.2 Exemplo de um activity diagram da UMLi. . . . . . . . . . . . . . . . . 37

3.3 Notação da linguagem MoLIC. . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Modelo de diagrama ALaDIM com algumas funcionalidades para caixa

eletrônico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.5 Framework de usabilidade, adaptado de Folmer & Bosch (2003). . . . . . 41

4.1 Elementos gráficos da VL4UCD. . . . . . . . . . . . . . . . . . . . . . . 48

iv

4.2 Subconjunto do metamodelo da VL4UCD - Elementos OpeningInterac-

tion, ClosingInteraction, Scene e SystemProcess . . . . . . . . . . . . . . 48

4.3 Subconjunto do metamodelo da VL4UCD - Elementos que compõem

uma scena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Subconjunto do metamodelo da VL4UCD - Elementos interação básica. . 51

4.5 Subconjunto do metamodelo da VL4UCD - Transições de estado. . . . . 52

4.6 Subconjunto do metamodelo da VL4UCD - Operadores de interação. . . . 53

4.7 Projeto estrutural da interação - UC: Pesquisar aluno. . . . . . . . . . . . 55

4.8 Projeto detalhado da interação para o use case Pesquisar Aluno. . . . . . 56

4.9 Prototipo de interface com usuários - UC: Pesquisar aluno. . . . . . . . . 57

4.10 Diagrama de sequência para o use case Checar Saldo (caso de sucesso). . 58

4.11 Diagrama de sequência: Checar Saldo (caso de falha). . . . . . . . . . . . 59

4.12 Ferramenta de suporte à VL4UCD. . . . . . . . . . . . . . . . . . . . . . 66

4.13 Subconjunto de uses cases do MasterTool. . . . . . . . . . . . . . . . . . 67

4.14 Modelo em VL4UCD para o use case criar projeto. . . . . . . . . . . . . 68

4.15 Modelo em VL4UCD para o use case criar POU. . . . . . . . . . . . . . 68

4.16 Modelo em VL4UCD para o use case Login. . . . . . . . . . . . . . . . . 70

5.1 Method evaluation model, extraído de Moody (2003). . . . . . . . . . . . 75

5.2 Esquema de procedimento experimental . . . . . . . . . . . . . . . . . . 82

5.3 Duração média de modelagem por atividade (G1) . . . . . . . . . . . . . 83



5.6 Respostas ao item 3 do questionário pós-tarefa. . . . . . . . . . . . . . . 87








A.1 Matriz de benefícios de usabilidade vs. táticas arquiteturais, extraído de

Bass & John (2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

B.1 Modelo em VL4UCD para o use case criar projeto. . . . . . . . . . . . . 110

B.2 Modelo em VL4UCD para o use case criar POU. . . . . . . . . . . . . . 111

B.3 Modelo em VL4UCD para o use case Login. . . . . . . . . . . . . . . . . 112

B.4 Modelo em VL4UCD para o use case “Fechar conta”. . . . . . . . . . . . 113

Lista de Tabelas

2.1 Padrão de design - Editor de Configurações. . . . . . . . . . . . . . . . . 14

2.2 Use case - Fazer chamada . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Use case - Encerrar chamada . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 Operadores temporais do ConcurTaskTrees. . . . . . . . . . . . . . . . . 31

3.1 Quadro comparativo entre as notações. . . . . . . . . . . . . . . . . . . . 45

5.1 t-Test: amostras presumindo variâncias diferentes para o construct (AE) . 84

5.2 Estatística descritiva para o construct (PEOU) . . . . . . . . . . . . . . . 86

5.3 t-Test: amostras presumindo variâncias diferentes para o construct (PEOU). 86

5.4 Estatística descritiva para o construct (PU) . . . . . . . . . . . . . . . . . 88

5.5 t-Test: amostras presumindo variâncias diferentes para o construct (PU) . 89

5.6 Estatística descritiva para o construct (ITU) . . . . . . . . . . . . . . . . 91

5.7 t-Test: amostras presumindo variâncias diferentes para o construct (ITU) . 91

5.8 Relação de confiabilidade dos itens . . . . . . . . . . . . . . . . . . . . . 95

5.9 Grau de significância dos resultados. . . . . . . . . . . . . . . . . . . . . 96

vii

Capítulo 1

Introdução

Os sistemas de software vêm se tornando cada vez mais essenciais à sociedade. Não

é difícil encontrar pessoas utilizando algum tipo de sistema interativo para realizar tarefas

cotidianas. Como exemplo, é possível destacar o uso de terminais de auto-atendimento

bancário, agendamento de compromisso em um aparelho celular, plataformas virtuais de

educação a distância, serviços de atendimento ao cliente, entre outros. O fato é que o uso

de software deixou de ser uma tarefa exclusiva dos profissionais de computação, passando

a ser uma ferramenta de auxílio às tarefas realizadas por pessoas dos mais diversos perfis.

Esse contexto vem atraindo estudos com o objetivo de melhorar as experiências de uso

dos sistemas produzidos, bem como as metodologias para seu desenvolvimento.

A construção de um sistema é realizada a partir de um conjunto de atividades relaci-

onadas e organizadas, denominadas de processo de software. Atualmente, há inúmeros

modelos de processo de software que podem ser utilizados de acordo com a necessi-

dade do produto a ser desenvolvido. De maneira geral, esses modelos são compostos de

cinco atividades fundamentais: especificação, design, implementação, validação e evolu-

ção [Sommerville 2010]. Na prática, essas atividades são sub-divididas em outras, tais

como: validação de requisitos, design da arquitetura, testes unitários, documentação, ge-

rência de configuração e mudanças, etc.

As exigências sobre um sistema de software têm tornado o seu processo de cons-

trução cada vez mais complexo. Além dos requisitos funcionais, existem aqueles que

CAPÍTULO 1. INTRODUÇÃO 2

são responsáveis por caracterizar a qualidade do produto. Requisitos de qualidade como

desempenho, disponibilidade, confiabilidade, escalabilidade, portabilidade, usabilidade,

são alguns dos requisitos atualmente exigidos por clientes e pelas próprias equipes de de-

senvolvimento, o que têm demandado, cada vez mais, a participação de profissionais de

diversas áreas, inclusive de fora da computação.

Com o objetivo de produzir software com características interativas, a comunidade

de computação historicamente organizou-se em duas grandes áreas - Engenharia de Soft-

ware (ES) e Interação Humano-Computador (IHC) - propondo que a comunicação entre

ambas ocorra por meio de relatórios textuais, diagramas e protótipos que representem

as características (requisitos funcionais e de qualidade) desejáveis do sistema [da Silva

et al. 2005].

Os profissionais de engenharia de software concentram suas decisões sobre a espe-

cificação e implementação do projeto da arquitetura interna do sistema. O projeto ar-

quitetural do software envolve, além dos requisitos funcionais, fatores que ditam a qua-

lidade do sistema, como: divisão do software em componentes que facilitam a gerência

e re-aproveitamento de artefatos (modularidade e reusabilidade); eficiência em termos

de processamento computacional (performance) e capacidade de instalação em sistemas

operacionais diferentes (portabilidade) [Hofmeister et al. 2000].

Na engenharia de software, várias representações gráficas (modelos) juntamente com

textos descritivos ajudam a formar a descrição da arquitetura do sistema. Os referidos

modelos possibilitam representar desde as visões estáticas e dinâmicas da arquitetura até

relacionamentos que existem entre seus componentes. Essas representações podem ser

feitas por meio de linguagens formais, como Architecture Description Language (ADL),

ou notações semiformais, como a Unified Modeling Language (UML), sendo esta última

mais comumente usada pela comunidade de desenvolvimento de software [Garlan et al.

2010].

Os profissionais de IHC concentram-se na relação entre o usuário e o sistema, ou


seja, no projeto de interface com usuário. Nesse contexto, o projeto de interface 1, com

o objetivo de privilegiar a qualidade de uso, inicia-se com a investigação daqueles que

utilizam o sistema, suas características e atividades, seu ambiente de trabalho, as tarefas a

serem realizadas por meio do sistema, por exemplo. A partir do conhecimento do usuário,

os designers de interface partem para o projeto, prototipação e avaliação dos artefatos de

software produzidos.

Para realizar o projeto de interface, o profissional de IHC faz uso de conhecimen-

tos de áreas externas à computação. Áreas como psicologia, sociologia e antropologia

possuem considerável influência nos métodos e técnicas utilizados pelos profissionais de

IHC. Como exemplo dessas influências teóricas, é possível destacar aquelas utilizadas na

década de 50 para mensurar o comportamento humano - Lei de Hick-Hyman [Hick 1952],

[Hyman 1953] e Lei de Fitts [Fitts 1954] - até as existentes atualmente, como exemplo,

a engenharia semiótica [de Souza 2005], a qual trata do projeto de interface como um

processo de significação e comunicação que envolve designers, usuários e sistemas inte-

rativos.

1.1 Motivação

Neste panorama, constata-se que engenheiros de software e profissionais de IHC pos-

suem concepções distintas sobre a construção de um software interativo. Essa diferen-

ciação incide sobre o requisito de usabilidade, que para engenheiros de software é visto

como atributos internos do sistema que afetam a performance e a produtividade do usuá-

rio; por outro lado profissionais de IHC tratam usabilidade como a medida de satisfação

do usuário com o sistema. Inserido nesse cenário contextual, cada grupo desenvolveu

seus próprios métodos e técnicas, prejudicando, assim, a comunicação entre ambos.

Com o propósito de atender às necessidades do desenvolvimento de software inte-

1Interface é a parte do sistema com a qual o usuário mantém contato físico e cognitivo durante ainteração [Moran 1981]


rativo, Bass et al. (2003) apresentam os padrões arquiteturais Model-View-Controller

(MVC) [Krasner & Pope 1988] e Presentation Abstraction Control (PAC) [Coutaz 1987],

referenciando-os como táticas para separar detalhes de implementação de interface de

usuário das funcionalidades internas do sistema. Essas táticas vieram com o propósito

de garantir que, alterações realizadas na interface de usuário não causassem impactos so-

bre os demais componentes da arquitetura do software, possibilitando, assim, integrar os

trabalhos realizadas pelos grupos de IHC e ES.

Folmer & Bosch (2004), não obstante, têm demostrado que essa abordagem de se-

paração da interface de usuário da lógica de negócio da aplicação não é o suficiente.

Muitas questões de usabilidade não dependem apenas de como a informação é apresen-

tada (a exemplo da alteração na estrutura de menus, layout de telas, cores, etc.), mas de

alguns recursos que precisam ser inseridos nos componentes internos do sistema para po-

der garantir uma boa usabilidade, por exemplo: undo, cancel, progress indication entre

outros. Folmer & Bosch (2004) argumentam, ainda, que tais funcionalidades costumam

ser apresentadas ao arquiteto do software depois que o sistema está pronto ou em uma

fase avançada de desenvolvimento, acarretando significativo impacto arquitetural.

Desse modo, este trabalho considera que problemas oriundos da falta de comunicação

entre ambos os grupos (ES e IHC) podem ser minimizados a partir da fase de especifi-

cação de requisitos. Por exemplo, se o software deve prover um contínuo feedback para

o usuário, então esta característica deveria ser considerada em tempo de especificação,

proporcionando, assim, um design arquitetural com suporte às questões associadas à usa-

bilidade. Para isso, propõe-se a Visual Language for Use Case Description (VL4UCD),

cujo objetivo consiste em auxiliar o processo de modelagem da interação usuário-sistema,

de modo a maximizar os benefícios das abordagens sugeridas pelos engenheiros de soft-

ware e profissionais de IHC.


1.2 Objetivos

Este trabalho tem como objetivo auxiliar o projeto de interação, da área de IHC, inte-

grado a descrição dos use cases, contribuindo, desta forma, para tomada de decisões de

forma eficiente durante as fases iniciais do processo de desenvolvimento de software inte-

rativo. Para tanto, apresentamos a Visual Language for Use Case Description - VL4UCD.

Esta notação tem como característica a integração dos conceitos necessários para repre-

sentar as preocupações de ambos os grupos (ES e IHC).

Desta forma, baseado na motivação já apresentada podemos chegar às seguintes per-

guntas de doutorado:

• Será que a VL4UCD permite modelar a interação usuário-sistema com menor custo

(tempo) em relação a outras já existentes?

• A notação VL4UCD é mais fácil de usar do que outras já existentes?

• Será a notação VL4UCD mais útil que as linguagens atuais?

• Profissionais de desenvolvimento de software teriam intenção em usar a VL4UCD?

Para obter as percepções de potenciais usuários sobre VL4UCD, um estudo experi-

mental envolvendo estudantes e profissionais de desenvolvimento de software foi reali-

zado. O estudo avaliou a percepção dos participantes com relação a eficácia, utilidade

e intenção de uso na prática. Todo experimento foi pautado sobre o framework teórico

denominado Method Evaluation Model e orientações sobre engenharia de software expe-

rimental apresentadas por Wohlin et al. (2012).

1.3 Organização do Trabalho

Para fins de otimização da leitura e da difusão do conhecimento produzido e aqui

defendido, é delineada, a seguir, a organização deste documento. No segundo capítulo,

é apresentada a fundamentação teórica para os problemas endereçados nesta pesquisa,


dando destaque à motivação para se criar uma nova forma de integrar as atividades de

engenharia de software e IHC com o objetivo de melhorar a qualidade de uso do sistema.

No terceiro capítulo, elenca-se os trabalhos relacionados a esta pesquisa, evidenciando

os aspectos positivos e suas deficiências para resolver o problema. No quarto capítulo,

encontra-se a descrição dos elementos da linguagem e a ferramenta de suporte. No quinto

capítulo apresentamos e analisamos os resultados do estudo experimental envolvendo a

VL4UCD. Por fim, no capítulo seis, as considerações finais sobre este trabalho de douto-

rado.

Capítulo 2

Fundamentação Teórica

Este capítulo, apresenta inicialmente o conceito de usabilidade como um dos critérios

para qualidade de software. Para isto, são apresentadas três definições atribuídas pela co-

munidade de computação ao termo usabilidade. Buscou-se, também, construir um breve

panorama sobre a especificação de software, demostrando sua importância para o pro-

cesso de desenvolvimento, tanto sob a ótica da engenharia de software quanto da intera-

ção humano-computador. Os conceitos apresentados aqui ajudarão a entender o problema

tratado nesta tese. Dessa forma, a seção 2.1 apresenta os conceitos de usabilidade e na 2.2

os conceitos gerais sobre especificação de software, enfatizando a necessidade desta ati-

vidade durante a fase inicial do projeto. Nas seções 2.3 e 2.4, é apresentado como ambos

os grupos (ES e IHC) fazem para representar os requisitos da interação. Com esse intuito,

conceitos extraídos destas formas de design são utilizados para construção de nova lin-

guagem para modelagem da interação usuário-sistema. Para concluir, apresenta-se uma

síntese do que foi tratado no capítulo, enfatizando a necessidade de resolver problemas de

comunicação entre profissionais de ES e IHC.

2.1 Usabilidade

Para alcançar seus objetivos o usuário interage com um software por meio de sua in-

terface, também conhecida como Graphical User Interface (GUI). As GUI’s devem ser

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 8

construídas de forma a possibilitar que os usuários do software possam aproveitar ao má-

ximo o apoio computacional oferecido pelo sistema. Para tal, estas GUI’s devem possuir

critérios de qualidade que permitam adequado nível de interação usuário-sistema. Como

critérios de qualidade podemos citar dois dos principais: usabilidade e acessibilidade.

O critério de acessibilidade diz respeito a remoção de barreiras que impossibilitem

aos usuários interagirem com o software por meio de sua interface. Para se alcançar este

critério de qualidade a comunidade de computação tem apresentado alguns métodos e

técnicas que permitem contornar certas limitações dos usuários. Como exemplo, as reco-

mendações do W3C vêm no sentido de permitir que todos possam ter acesso aos websites,

independente de possuírem alguma deficiência ou não. Nestas recomendações são abor-

dadas desde as características das fontes (cor e tamanho) de acordo com as necessidades

dos usuários, até recomendações relativas ao código HTML e CSS, por exemplo.

Em linha geral, usabilidade está relacionada com a facilidade com que pessoas manu-

seiam ferramentas ou objetos com fim de realizar uma tarefa do dia-a-dia. A comunidade

de IHC propôs ao longo dos anos diferentes definições sobre o que de fato é usabilidade.

Com o propósito de promover uma maior consistência, a International Organization

for Standardization (ISO) tem desenvolvido vários padrões que dizem respeito a usabili-

dade de sistemas interativos como, por exemplo, componentes de interface (ícones, cur-

sores, entre outros). Já no final da década de 90 a norma sobre requisitos de ergonomia,

ISO 9241-11 (1998), define usabilidade como sendo:

“A medida em que um produto pode ser utilizado por usuários específicos

para alcançar seu objetivos com eficiência, eficácia e satisfação em um es-

pecífico contexto de uso.”

Segundo a norma, a eficiência é um atributo que está relacionada com os recursos

desprendidos para os usuários interagirem com o sistema e alcançarem seus objetivos.

A eficácia está relacionada com a capacidade dos usuários alcançarem seus objetivos

corretamente por meio do sistema. Outro atributo que podemos destacar na norma é a


satisfação do usuário em usar o sistema. Isso evidencia uma preocupação além da visão

de performance do usuário, como: se o usuário realizou a tarefa corretamente, ou se o

usuário finalizou a tarefa corretamente dentro de um prazo previsto, etc. O atributo de

satisfação está relacionado à visão do usuário sobre a experiência de usar o sistema, ou

seja, a maneira com que o sistema se apresenta para o usuário realizar suas tarefas está de

acordo com o que ele idealizava para o mesmo.

Ao definir critérios de qualidade de software, a ISO 9126-1 (2000) propõe a definição

de usabilidade como sendo:

“A capacidade do software em permitir que usuários realizem suas tarefas

com eficácia, produtividade, segurança e satisfação em um específico con-

texto de uso.”

Esta definição é similar a apresentada na ISO 9241-11, exceto pelo fato de adicio-

nar o conceito de segurança (safety). Este atributo está relacionado com a prevenção de

erros, evitando que os usuários os cometam ou se cometerem, possam facilmente se recu-

perar, voltando ao estado anterior (por exemplo, usando funcionalidades undo e rendo).

Portanto, a definição de usabilidade proposta nas duas ISO são complementares.

Fora do escopo da ISO, importantes trabalhos sobre usabilidade já foram propostos.

Dentre eles podemos destacar aqueles produzidos por Nielsen (1993). Sua abordagem

sobre usabilidade tem sido muito usada quando se trata de design de interface. Ele consi-

dera que usabilidade é um aspecto que influencia na aceitação de um sistema de software

e define um modelo de usabilidade com cinco atributos:

• facilidade de aprendizado (learnability): Este atributo define que o sistema deve

ser fácil de usar, permitindo que mesmo usuários inexperientes sejam capazes de

realizar suas tarefas de modo satisfatório. Para que um sistema seja fácil de usar

ele deve ser intuitivo, ou seja, mesmo sendo a primeira vez que o usuário utiliza o

sistema, este deve possuir características em sua interface que conduzam a intera-


ção. Nem sempre o usuário possui tempo hábil para ler o manual do sistema como

uma atividade pré-interação. Quanto menor a carga de treinamento necessária para

usar o sistema, melhor. Afinal, os recursos tecnológicos existentes são justificados

quando permitem melhorar a realização das tarefas no dia-a-dia das pessoas.

• eficiência (efficiency): Este atributo diz respeito ao grau de produtividade do usuá-

rio durante sua interação com o sistema. A produtividade pode ser medida, por

exemplo, pelo tempo necessário para que o usuário realize suas tarefas. Não é por-

que o usuário possui experiência com um determinado sistema que ele terá produti-

vidade com o mesmo. Para um sistema interativo oferecer uma boa produtiviade ele

deve oferecer mecanismos que possibilitem essa produtividade. Por exemplo, ima-

ginemos um sistema de caixa de supermercado onde, para cada produto que passa

pelo caixa o usuário tivesse que digitar o código do mesmo e ainda clicar sobre um

botão na interface para confirmar a compra do produto. O tempo gasto para essa

tarefa geraria um alto nível de stress não só para quem está operando o sistema,

mas, também, para aqueles que estão na fila para realizar suas compras.

• facilidade de memorização (memorability): Este atributo está diretamente relacio-

nado com o grau de esforço cognitivo realizado pelo usuário durante a interação

com o sistema. Sistemas de uso esporádicos ou com longos intervalos de tempo

entre uma interação e outra tendem a dificultar a interação usuário-sistema. Isso

porque, com o passar do tempo toda ou parte da interação aprendida pelo usuário

pode cair no esquecimento. Diante disso, é importante que a interface dê pistas, du-

rante a interação usuário-sistema, de forma a ajudar o usuário a resgatar na memória

o que foi aprendido em momentos passados.

• segurança no uso (safety): A segurança está relacionada ao grau de proteção ofe-

recida pelo sistema de forma a minimizar a quantidade de erros durante a inte-

ração. Para isso, o sistema deve evitar problemas como, por exemplo, reduzindo a

possibilidade de acionamentos equivocados de comandos indesejáveis. Outra ma-


neira seria auxiliando os usuários a se recuperarem de uma interação mal sucedida

permitindo que os mesmos possam desfazer o que foi feito por engano.

• satisfação do usuário (satisfaction): Este atributo está relacionado com o senti-

mento do usuário, iniciante ou não, do quão agradável é a interação usuário-sistema.

O trabalho de Nielsen não ficou apenas no campo de definição de usabilidade, mas

também como seria possível medir a usabilidade de um sistema. Baseado em um banco

de dados de problemas de usabilidade, identificados a partir de vários projetos de siste-

mas interativos, Nielsen (1994) extraiu um subconjunto desses problemas os quais ele

considerou como os mais relevantes e recorrentes durante suas avaliações. Este estudo

deu origem ao que conhecemos como heurísticas de Nielsen, e consiste em um conjunto

de diretrizes que ajudam a reconhecer e mensurar o quão bom pode ser a interação do

sistema. São elas:

• Diálogo simples e natural: A interface com o usuário não deve conter informa-

ções irrelevantes ou que sejam raramente utilizadas. Informações extras tendem a

poluir a interface diminuindo a visibilidade do que realmente é relavante para o diá-

logo. A sequência do diálogo e o acesso aos objetos e operações do sistema devem

apresentar-se em ordem cronológica e natural.

• Falar a linguagem do usuário: Os termos usados devem ser claros e baseados na

linguagem do usuário, em vez de termos orientados ao sistema.

• Minimizar a sobrecarga de memória do usuário: Os objetos de que compõem o

diálogo devem ajudar os usuários durante a interação de forma a permitir que os

mesmos façam suas escolhas sem que precisem lembrar de um determinado co-

mando. Além disso, as instruções para utilização do sistema devem estar sempre

visíveis.

• Consistência: Comandos ou ações idênticos devem sempre ter o mesmo efeito, ou

seja, devem apresentar, por exemplo, uma mesma localização e formato na inter-


face. Desta forma, o usuário poderá mais facilmente indentifica-lo.

• Feedback: O sistema deve manter os usuários continuamente informados sobre o

que está acontecendo. O que significa dizer que a interface deve possui recursos

que informe ao usuário o que o sistema fez, deixou de fazer ou está fazendo.

• Saídas claramente demarcadas: O sistema deve permitir que o usuário se sinta no

controle. Para isso, deve permitir, a qualquer momento, a possibilidade de finali-

zar uma tarefa ou desfazer uma determinada operação acionada equivocadamente,

retornando o sistema para o último estado consistente.

• Atalhos: O sistema deve disponibilizar mecanismos que ajudem a acelerar o traba-

lho dos usuários, mesmo que para isso ele tenha que possuir um profundo conhe-

cimento sobre o sistema. Combinações de teclas, comandos de voz e cliques de

mouse são bons exemplos que podem ser usados para construir atalhos para deter-

minadas funções do sistema.

• Boas mensagens de erro: Os sistemas devem expressar suas mensagens em lingua-

gem clara e sem códigos, indicando o problema e sugerindo uma solução. Fazer o

usuário entender e resolver o problema também ajuda a aumentar a sensação de que

ele está no controle do sistema.

• Prevenir erros: Ao se projetar um sistema deve-se atentar para as situações onde

existem maior incidência de erros de forma a modificar a interface para que estes

erros não ocorram. Segundo Nielsen:

“Melhor do que boas mensagens de erro é um projeto cuidadoso que

impede que um problema ocorra.”

• Ajuda e documentação: Um sistema bem projetado em sua comunicação com o

usuário deve minimizar a necessidade de ajuda para utiliza-lo. Mesmo assim, uma

boa documentação deve ser construída para ajudar os usuários em caso de dúvida.

Essa documentação deve estar sempre disponível, de fácil uso e focada na tarefa do

usuário. Documentações extensas são motivos de descontentamento e não utiliza-


ção por parte dos usuários.

2.1.1 Padrões de Design de interface

A partir das diretrizes de Nielsen e de outros pesquisadores do tema, a comunidade de

IHC criou um conjunto de soluções de interação, também conhecidas como padrões de

design de interface. Estas soluções são representações concretas do design da interface

usuário-sistema e passaram, desde então, a compor os sistemas interativos que usamos

nos dias atuais. O conceito de padrões de design tem origem com Alexander (1979) no

domínio da arquitetura e urbanismo. A ideia por trás dos padrões é capturar as melhores

práticas em um determinado domínio do design com o objetivo de compartilha-las.

No domínio da computação os padrões de design foram inseridos inicialmente por

Gamma et al. (1995) na forma de padrões de arquitetura de software. Os padrões suge-

ridos por Gamma definem como os objetos que compõem a estrutura interna do sistema

podem ser organizados em termos de criação, associação e comportamento. Com o pas-

sar dos anos a comunidade de IHC criou inúmeros padrões de design de interface, sendo

alguns destes encontrados no catálogo de Borchers (2000), Tidwell (2005) e Welie (2016).

A representação de um padrão de design possui um conjunto mínimo de informações

que possibilitam seu entendimento e posterior aplicação. Por exemplo, no catálogo de

Tidwell um padrão de design de interface está representado com a seguinte estrutura:

• título: representação em poucas palavras da ideia do padrão;

• o que: apresenta uma descrição resumida da solução;

• usar quando: indica em quais situações o padrão pode ser usado;

• por quê: apresenta dados que justificam a aplicação do padrão;

• como: descreve de forma detalhada a solução e como pode ser implementada;

• exemplos: apresentam ilustrações de interfaces concretas da solução.

O exemplo da tabela 2.1 representa o padrão Editor de Configurações (Settings Edi-


tor), adaptado do catálogo de Tidwell. Os termos em negrito representam relações do

padrão descrito com outros do mesmo catálogo ou não.

Tabela 2.1: Padrão de design - Editor de Configurações.

título editor de configurações.

o que forneça uma página ou janela onde os usuários podem alterar as configura-ções/preferências do sistema.

usar quando quando você necessita projetar uma interface de aplicação mobile, sistema operacio-nal, sites ou algo similar, o qual o usuário necessita alterar uma ampla quantidade deconfigurações.

por quê o usuário deve ser capaz de encontrar e editar uma configuração desejada sem quepara isso precise percorrer uma sequência prescrita de etapas (Wizard). No editor deconfigurações o acesso aleatório é importante e as propriedades ficam agrupadas emcategorias.

como inicialmente, torne o editor de configuração de fácil acesso. Boa parte das plataformas(mobile e desktop) já possuem um local onde o usuário pode procurar/encontrar aspreferências do sistema. Sites normalmente colocam links para configuração de perfilda conta de usuário em sua parte superior (direita ou esquerda).Em segundo lugar, agrupe as preferências/configurações dentro de páginas e nomeieos grupos de forma a ajudar o usuário a imaginar o que tem dentro. Um exercíciode Card-sorting é uma boa técnica para ajudar a construir e nomear os grupos depreferências/configurações.Em terceiro lugar, deve-se decidir como construir as páginas (ou janelas) que com-porão os diversos itens de cada grupo. Tabs, Two-Panel Selector e One-WindowDrilldown apresentam-se como layouts mais comuns para editores de configuração.

exemplos A figura 2.1 apresenta a janela de preferências do Mac OS. Nela podemos identi-ficar cinco categorias (Pessoal, Hardware, Internet e redes sem fio, Sistemas e ou-tro). Cada grupo possui seus subgrupos que dão acesso as suas respectivas prefe-rências/configurações que o usuário pode editar. A figura 2.2 apresenta a página deconfigurações de uma conta do Gmail. Nela as configurações estão agrupadas emforma de tabs, onde cada uma possui um conjunto considerável de parâmetros paraedição ou simples visualização.

Apesar de representarem uma solução para um determinado problema em certo con-

texto, os padrões de design de interface não funcionam como uma “receita de bolo” capaz

de conceber todo projeto de interação do sistema. Os padrões não constituem por si só

uma ferramenta capaz de substituir o processo criativo dos projetistas, ou seja, para que

um sistema interativo alcance bons níveis de usabilidade é necessário que estes sejam

mais uma ferramenta de auxílio durante o projeto de interação do sistema.


Figura 2.1: Editor de configurações das preferências do MacOS

2.2 Especificação de Software

Como pode ser observado na literatura e como já descrito no capítulo 1, a engenharia

de software organizou seu processo de desenvolvimento de software em cinco atividades

fundamentais: especificação de software, design, implementação, validação e evolução.

Para Sommerville (2010), a atividade de especificação de software ajuda a compreender

e definir os serviços necessários e identificar as restrições de operação e desenvolvimento

do produto. Ela caracteriza-se como uma atividade crítica para o processo de software,

visto que, quanto mais tarde for identificado um problema de requisito, maior será o custo

associado para sua correção.

O guia intitulado Software Engineering Body of Knowledge (SWEBOK) [Abran et al.

2004] apresenta quatro etapas (fases) bem definidas dentro da engenharia de requisitos:

a. Elicitação: igualmente conhecida como captura ou descoberta de requisitos, esta


Figura 2.2: Editor de configurações do Gmail

etapa tem como objetivo entender e definir o problema que o software pretende

solucionar. Possui como fonte de investigação os stakeholders 1, documentos, sis-

temas em operação e os ambientes operacionais e organizacionais. Técnicas como

entrevistas, cenários, prototipação e observação são ferramentas utilizadas para ten-

tar capturar os requisitos do sistema;

b. Análise: esta fase destina-se à detecção e resolução de requisitos conflitantes entre

os diversos stakeholders, além de descobrir as fronteiras do software e como ele

deve interagir com seu ambiente. Para tanto, é necessária a descrição/construção

de um ou mais modelos do sistema com o propósito de auxiliar no entendimento

da solução. Diversos modelos podem ser construídos, por exemplo: modelo de da-

dos, modelo de objetos, modelo de interação com usuário e modelo de estados. O

1Stakeholder de um sistema é uma pessoa ou grupo de pessoas que tem influência direta ou indiretasobre os requisitos do sistema [Abran et al. 2004]


que é produzido nesta fase está fortemente relacionado com o projeto de arquite-

tura do software e é sobre ela que são projetados os componentes responsáveis por

satisfazer os requisitos do sistema.

c. Especificação de requisitos: esta etapa traduz-se na produção de um documento es-

truturado que define o conjunto de requisitos do sistema. Esses documentos podem

ser descritos por meio de linguagem natural, modelos gráficos ou uma combinação

dos dois. Para compor uma representação gráfica do sistema os analistas utilizam,

por exemplo, diagramas de caso de uso, diagrama de classes, diagrama de ativida-

des e diagrama de estados. Os mencionados diagramas permitem documentar os

requisitos a partir de três perspectivas: estrutural, funcional e comportamental. De-

pendendo do tamanho/complexidade do sistema, o SWEBOK sugere pelo menos

três tipos de documentos: requisitos de usuário, requisitos de sistema e requisitos

de software.

d. Validação de requisitos: a validação de requisitos tem como propósito descobrir er-

ros nos requisitos documentados, de forma que modificações possam ser feitas para

corrigir o problema. A validação de requisitos é realizada sobre a ótica dos seguin-

tes aspectos: (i) conteúdo - este aspecto permite avaliar se o nível de detalhamento

dos requisitos elicitados e documentados são apropriados. Critérios como comple-

tude, rastreabilidade, consistência e verificabilidade são questionamentos chaves

para aprovação destes aspectos; (ii) documentação - este aspecto tem como objetivo

identificar se os requisitos estão documentados em conformidade com as diretrizes

especificadas previamente. Inteligibilidade, conformidade e não-ambiguidades são

critérios avaliados; (iii) acordo - refere-se à aceitação dos stakeholders com re-

lação aos requisitos documentados. Este aspecto busca a resolução de possíveis

conflitos, principalmente aqueles que surgem após uma mudança nos requisitos. É

natural que, ao longo do processo, os stakeholders adquiram maior conhecimento

do sistema a ser desenvolvido, mudando, assim, suas opiniões quanto a requisitos


já acordados.

A atividade de especificação não é exclusividade da engenharia de software. Em IHC,

independentemente do processo produtivo adotado, a atividade de projeto e construção da

interface vem sempre precedida de atividades de elicitação e análise de requisitos. Um

exemplo disso é o (ver figura 2.3) ciclo de vida da engenharia de usabilidade proposto

por Mayhew (1999). O referido processo inicia com um ciclo de atividades denominado

análise de requisitos. Nessa etapa, com base nas características dos usuários, análise

de tarefas e características de plataforma, são definidas as metas de usabilidade a serem

alcançadas pelo sistema.

Figura 2.3: Processo de desenvolvimento da Engenharia de Usabilidade, extraído de Bar-bosa & Silva (2010).

Rogers et al. (2011) propõem um ciclo de vida mais simplificado para o design de

interação. Seu modelo consta de apenas quatro atividades nas quais identificar necessi-

dades/estabelecer requisitos é o ponto partida do processo, conforme pode ser visto na


figura 2.4. O propósito desta atividade é caracterizar os usuários do sistema, seu ambiente

físico e social de trabalho, suas tarefas e forma de se relacionar com elas em determinadas

circunstâncias. A partir de tal atividade, alguns designs alternativos são gerados de forma

a acomodar os requisitos identificados, permitindo que versões interativas sejam produ-

zidas e levadas à avaliação. Com base nos feedbacks das avaliações e na caraterística

interativa do processo, é possível lapidar as ideias iniciais até chegar a uma versão final.

Figura 2.4: Modelo simplificado de design de interação, extraído de Barbosa & Silva(2010).

Apesar dos exemplos citados nesta tese apresentarem que profissionais de engenharia

de software e IHC concordam que a construção dos seus artefatos deva ser precedida

por uma fase de especificação, na qual requisitos do sistema são elicitados, analisados

e documentados por meio de linguagem natural e/ou modelos gráficos, ambos diferem

sobre o foco que deve ser levado em consideração.

A engenharia de software demonstra possuir uma perspectiva de design centrada no

sistema, ou seja, seus esforços estão voltados para atividades e problemas de engenharia

como, por exemplo, minimizar o tempo de desenvolvimento, reuso de componentes de

software, instalação e manutenção.

Na perspectiva centrada no sistema, o que importa é o que está dentro dele, ou seja,


algoritmos, estruturas de dados, a arquitetura interna dos componentes e as tecnologias

utilizadas para desenvolvimento e execução do software. Com isso, atributos de qualidade

do sistema ficam restritos àqueles relacionados à construção, como reuso, performance,

manutenibilidade, portabilidade, integridade e segurança. A usabilidade é um atributo

que fica restrito, algumas vezes, a determinar o intervalo de tempo satisfatório para que

um usuário realize uma determinada tarefa, como checar o saldo de sua conta bancária,

ou informar que o sistema deve ter um recurso de ajuda (help) para usuário.

Na perspectiva centrada no uso, proposta pelos profissionais de IHC, para um software

interativo apresentar boa usabilidade é preciso conhecer o usuário, suas necessidades, for-

mas de pensar e agir. Para Rogers et al. (2011), um fato que retrata bem a necessidade

de se entender o usuário, é quando precisa-se projetar um software interativo a ser utili-

zado por crianças e adultos. Para as crianças uma interação baseada em personagens de

desenho animado seria motivador, enquanto que os adultos não diriam a mesma coisa.

Outro fator importante para satisfação do usuário na interação com o sistema refere-se ao

contexto de uso. Por exemplo, não é interessante para um operador de caixa de padaria

ou supermercado que a interação com o sistema seja baseado em manipulação de obje-

tos (botões e menus) através do mouse. Nesse caso, as caraterísticas do seu ambiente de

trabalho e as tarefas a serem realizadas exigem um forma diferente interação; por isso,

considerável parte das operações inerentes ao trabalho são executadas apenas sobre um

teclado.

As diferentes perspectivas sobre o desenvolvimento de software interativos deram ori-

gem a métodos e técnicas próprios de cada área (ES e IHC). Como resultado, desencadeou-

se uma lacuna entre estas duas áreas, causando impactos sobre o processo produtivo e na

qualidade do produto final. Para minimizar esse problema, é preciso que a especificação

de requisitos em processos de desenvolvimento de software interativos passe a ter uma

atenção tanto para os aspectos internos do software quanto os externos, que, nesse caso,

são usuários, seus objetivos e tarefas e o contexto de uso.


Com o intuito de minimizar esses entraves, os requisitos especificados pelas equipes

de engenheiro de software e IHC precisam ser comunicados e negociados antes de co-

meçar a fase de projeto e implementação do sistema. Para que isso ocorra, é necessário

que exista uma linguagem comum entre ambos. Portanto, chegar a um acordo sobre esta

linguagem e a maneira como utilizá-la parece ser uma condição fundamental. Quanto

maior for a semelhança entre a forma de trabalho, características culturais e educacionais

que essa linguagem apresentar entre os dois grupos, melhor será a interação e consequen-

temente os resultados obtidos.

2.3 Modelos e Representações de Engenharia de Software

Introduzidos por Jacobson [Jacobson 2004] e amplamente adotados em abordagens

orientadas a objetos, como o Rational Unified Process (RUP), os use cases são usados

para modelar e representar unidades funcionais ou serviços providos por um sistema de

software. Segundo a especificação UML [OMG 2013], estas funcionalidades do sistema

devem ser representadas por meio de um diagrama de use cases. Nele são representados

os atores 2, os use cases e a relação entre eles (ver figura 2.5). Para cada use case do

diagrama, deve existir uma descrição detalhada da sequência de interações entre atores e

sistema, incluindo as mensagens trocadas e ações executadas pelo sistema. Essa descrição

pode ser representada por intermédio de uma linguagem natural ou notações gráficas,

como diagramas de sequência, atividades e estado.

Em um use case podem existir inúmeros caminhos, representados por meio do fluxo

de evento básico e os fluxos de eventos alternativos (ver figura 2.6). Um fluxo básico

descreve as ações que são normalmente solicitadas quando um use case é executado en-

quanto os fluxos alternativos descrevem o comportamento opcional ou excepcional de um

use case. Os fluxos de eventos alternativos funcionam como desvios ao fluxo de evento2Apesar de um ator em um use case poder representar um usuário ou sistema, neste trabalho o termo é

utilizado apenas com foco no usuário.


básico e são disparados de acordo com o evento escolhido durante a interação usuário-

sistema podendo voltar ao fluxo básico ou finalizar a execução de um use case.

O fluxo de evento básico de um use case pode ser, ainda, desviado a partir da existên-

cia de relacionamentos de inclusão e extensão entre os use cases. Um relacionamento de

extensão é utilizado para descrever cenários opcionais a um use case base. Para isso, uma

condição de extensão deve ser estabelecida no relacionamento de extensão. Para exem-

plificar, no fluxo básico do use case Fazer Chamada, o ator deverá digitar o número de

telefone desejado, permitindo, assim, que este realize uma ligação telefônica. Contudo,

é possível que o ator não lembre o número desejado e, então, precise acessar sua lista de

contatos. Prevendo esta possibilidade, o analista projetou o use case Ver Contatos, que

estende o use case base. Uma extensão de use case pode ocorrer em um ou mais pontos

do use case base. Posteriormente à execução da extensão, será retomada a execução do

use case base do ponto em que havia deixado. A figura 2.7 representa o esquema geral

para o processo de extensão de uma use case.

O relacionamento de inclusão é utilizado quando existe um cenário comum a mais de

um use case, evitando descrever uma mesma sequência de passos mais de uma vez. Dife-

rente dos relacionamentos de extensão que indicam opcionalidade, os relacionamentos de

inclusão indicam obrigatoriedade, ou seja, quando um use case tem um relacionamento

Figura 2.5: Use cases - Sistema de telefonia


Figura 2.6: Fluxos de eventos de um use case.

Figura 2.7: Use case base e sua extensão.

de inclusão com outro, a execução do primeiro obriga a execução do segundo. A inclusão

representa um segmento contínuo de comportamento, incluído em um determinado local

do use case base (ver figura 2.8). Como exemplo deste tipo de relacionamento, observa-

se, na figura 2.5, o use case Fazer Chamada, no qual se incluem os passos necessários

para estabelecer um circuito virtual para a chamada por meio do use case Gerenciar

Circuito Virtual.

O problema, no entanto, é a dificuldade em obter uma visão global3 do comporta-

mento da interação a partir da combinação de diversos use cases [Somé 2006]. Em outras

3Para fins desta tese visão global refere-se a capacidade de representar todas as possíveis interações dousuário com o sistema de uma forma não fragmentada.


Figura 2.8: Use case base com a inclusão.

palavras, a representação é fragmentada e, como consequência, pode gerar redundâncias

e inconsistências entre use cases, prejudicando, por conseguinte, decisões precisas so-

bre a descrição do projeto de interação. Para exemplificar esses casos de fragmentação

na interação entre ator e sistema, apresentamos as tabelas 2.2 e 2.3, que descrevem de

forma resumida os use cases Fazer Chamada e Encerrar Chamada telefônica, respecti-

vamente.

Entre os problemas relacionados com a fragmentação da interação global do sis-

tema, podemos citar aqueles relacionados à navegabilidade. De acordo com Shneiderman

[Shneiderman 1997], o usuário, quando pede, por engano, para o sistema executar uma

certa funcionalidade, ele espera que seja possível interrompê-la retornando ao último lo-

cal consistente da interação. Para o exemplo demonstrado na tabela 2.2 o ato de encerrar

uma chamada deveria levar o ator do sistema ao passo 2 do use case Fazer Chamada.

No entanto, não é o que se observa quando se deseja encerrar uma chamada para um

número incorreto em aplicações telefônicas de celulares touch screen com sistema ope-

racional Android (versão 2.1.1). Nessas aplicações, o ato de cancelar uma chamada faz

com que a aplicação seja totalmente encerrada, obrigando o usuário a entrar novamente no

aplicativo para, então, ter acesso novamente ao teclado do telefone. Isso ocorre porque os

desenvolvedores do produto implementaram a função de Encerrar Chamada prevendo


Tabela 2.2: Use case - Fazer chamadaResumo: O use case descreve os passos necessá-

rios para estabelecer uma ligação telefô-nica entre dois telefones celulares.

Ator: ChamadorPré-condição:

Existência de sinal da operadora.

Fluxobásico:

1) O chamador aciona a aplicação te-lefônica;2) O sistema apresenta o teclado touchpara discagem;3) O chamador disca um número e aci-ona a funcionalidade de discagem;4) O sistema analisa os números e veri-fica o endereço de rede do receptor;5) O sistema estabelece a conexão entreo chamador e o receptor.

Fluxo al-ternativo:

Se o chamador desejar ele pode exten-der o use case Encerrar Chamada.

Pós-condição:

Conexão chamador-receptor estabele-cida.

apenas a situação sucesso, replicando-a para todas as situações, inclusive aquelas em que

o usuário apenas deseja corrigir um número que foi teclado equivocadamente.

Tabela 2.3: Use case - Encerrar chamadaResumo: O use case descreve os passos necessá-

rios para encerrar uma chamada entredois telefones celulares.

Ator: Chamador.Pré-condição:

Conexão entre chamador-receptor esta-belecida.

Fluxobásico:

1) O chamador aciona a função encerrarchamada;2) O sistema encerra a chamada;3) O sistema fica pronto para estabelecernova chamada.

Pós-condição:

Conexão chamador-receptor encerrada.

Como descrito no início desta seção, a realização de use cases podem ser representa-

dos basicamente de três formas: diagramas de atividade, diagramas de estado e descrição

narrativa. Na prática, por facilitar a comunicação entre stakeholders, a linguagem natural


tonou-se a forma mais utilizada para representar a interação entre atores e sistemas.

Ao longo dos anos, esta forma de representação textual dos use cases sofreu di-

versas contribuições, tanto da comunidade acadêmica quanto da indústria de software.

Essas contribuições têm como objetivo melhorar sua estrutura de representação e por

consequência o entendimento daqueles que trabalham no desenvolvimento do software.

Como exemplo, é possível citar os Templates e Guidelines de Cockburn (2000) e o estilo

Essential Use Cases de Constantine & Lockwood (2001).

Apesar dos avanços já alcançados, a forma de representação mencionada possui ainda

algumas deficiências para representar os interesses dos profissionais de IHC. Sua forma de

descrição livre proporciona uma proliferação textual que prejudica a análise de interesses

por parte de alguns stakeholders como, por exemplo, os profissionais de IHC. Além disso,

a narrativa permite que escritores omitam, de forma mais corriqueira, partes do use cases

que, muitas vezes, podem ser relevantes para interação do usuário com o sistema. Descri-

ções resumidas como “o usuário preenche e submete o formulário...” ou a falta de uma

mensagem alertando o usuário que algo aconteceu ou deixou de acontecer são bastante

relevantes no momento de implementar um sistema que pretende ter boa usabilidade.

Por último, mas não menos importante, é comum encontramos descrições na forma

“o caso de uso finaliza quando o usuário pressiona o botão gravar...”. Para Constantine

& Lockwood (2001), esse tipo de descrição é inapropriada para o design de interfaces de

usuário, posto que ela antecipa etapas do processo de design quando assume a descrição

de partes concretas da interface. Esta é uma prática perigosa, visto que pode, de certa

forma, restringir o trabalho dos profissionais de IHC, levando-os a produzir uma interface

de baixa qualidade de uso.


2.4 Modelos e Representações de Interação Humano-Com-

putador

De forma geral, a comunidade de IHC organizou o design de interação do sistema

em quatro atividades básicas: especificação de requisitos, projeto de alternativas, proto-

tipação e avaliação [Rogers et al. 2011]. É durante a atividade de especificação que os

requisitos são capturados e analisados para servir de base para o projeto. Nas abordagens

centrada no usuário, modelos de usuário e de suas tarefas são utilizados como ferramen-

tas para analisar, interpretar e representar requisitos do sistema [Ahmed & Ashraf 2007].

No design centrado no usuário, os modelos de usuários e tarefas caracterizam-se como

peças essenciais para compreensão do problema, pois possibilitam descrever as tarefas do

usuário e suas capacidades (motoras e cognitivas) de interação com o sistema.

Ao longo do tempo, alguns modelos de tarefas com notações diferentes foram cria-

dos pela comunidade de IHC, dentre os mais comuns, podemos citar o GOMS (Goals,

Operators, Methods, and Selection Rules), HTA (Hierarchical Task Analysis) e CTT

(ConcurTaskTrees).

O modelo GOMS, proposto por Card et al. (1983), tem como objetivo representar o

comportamento dinâmico da interação usuário-sistema, a partir da representação de três

subsistemas de interação: perceptivo, cognitivo e motor. Além de permitir a descrição das

tarefas, o GOMS permite a realização de análises que preveem o desempenho de usuário

durante a interação do sistema. Contudo, deve-se partir do pressuposto que cada usuário

já conhece a tarefa que irá realizar, o que tende a ser uma deficiência do método, posto

que, desse modo, não é possível medir prováveis erros de interação, factível para usuários

que ainda não possuem experiência sobre a tarefa.

Existem diferentes variações de GOMS, permitindo, assim, avaliar e predizer o de-

sempenho do usuário durante a interação. Dentre estas variações, cabe destacar os mo-

delos KLM (Keystroke-Level Model) e CMN-GOMS (Critical Path Method - GOMS).


No entanto, para essas variações, os principais conceitos são idênticos, e são descritos a

seguir:

• Goals: reproduzem o que o usuário deseja alcançar com o sistema, por exemplo,

apagar um arquivo, editar um texto, etc. Estes podem ainda ser decompostos em

submetas;

• Operators: representam as ações permitidas pelo software para que o usuário possa

executar suas tarefas. A representação dos operadores pode ser definida de forma

abstrata ou mesmo concreta, como exemplo, especificando uma ação de clique de

mouse, escolha de menu, etc.

• Methods: são as sequências necessárias para que uma meta possa ser atingida.

• Selection rules: representam as condições necessárias para se selecionar um method

para atingir uma meta, caso exista mais de um método disponível.

Considere uma tarefa cujo objetivo é apagar um arquivo usando o Windows Explorer.

Essa tarefa pode ser basicamente decomposta em duas submetas: Selecionar arquivo

e Emitir comando para apagar arquivo. Para concluir essas submetas, o usuário

tem a opção de usar tanto o teclado quanto o mouse. A escolha do método a ser utilizado

vai depender das condições em que se encontra o usuário e do seu desejo de utilizar o

mouse ou teclado para executar a tarefa. A figura 2.9 apresenta um exemplo detalhado de

um modelo GOMS para apagar um arquivo.

A segunda representação para modelos de tarefas, tratado neste trabalho, refere-se ao

HTA [Annett & Duncan 1967]. Diferentemente da modelagem com GOMS, que busca

representar o comportamento da interação, o HTA baseia-se na representação funcional da

tarefa. O modelo possui uma notação textual acompanhada de uma representação gráfica

de caixas e linhas do tipo organograma, nas quais o elemento inicial representa o objetivo

de mais alto nível (por exemplo, cadastrar projeto final) e os demais caracterizam-se como

subobjetivos (por exemplo, informar dados do projeto, informar orientador), necessários


GOAL: Apagar arquivo GOAL: Selecionar Arquivo Method: Seleção via teclado Select rule: Se as mão estão sobre o teclado Operator: Deslocar o curso usando as teclas de direção do teclado

Method: Seleção via mouse Select rule: Se a mão esquerda está sobre o mouse Operator: Deslocar o curso do mouse até o arquivo Operator: Clicar com o botão esquerdo do mouse sobre o arquivo GOAL: Imitir o comando para apagar o arquivo Method: Apagar arquivo via teclado Select rule: Se as mão estão sobre o teclado Operator: pressionar o botão delete do teclado Operator: Confirmar a exclusão do arquivo

Method: Apagar arquivo via o menu suspenso (drop-down) Select rule: Se a mão está sobre o mouse Operator: Mover o cursor do mouse até o ícone do arquivo Operator: Clicar com o botão direito do mouse sobre o arquivo Operator: Localizar a opção de apagar arquivo no menu suspenso Operator: Mover o cursor do mouse até o comando de apagar arquivo Operator: Clicar com o botão esquerdo do mouse sobre o comando Operator: Confirmar a exclusão do arquivo

Method: Arrastar e soltar o arquivo sobre a lixeira Select rule: Se a mão está sobre o mouse Operator: Mover o cursor do mouse até o ícone do arquivo Operator: Clicar com o botão esquerdo do mouse sobre o arquivo Operator: Localizar a lixeira Operator: Mover o cursor do mouse até a lixeira Operator: Liberar o botão esquerdo do mouse Operator: Confirmar a exclusão do arquivo

Figura 2.9: Modelo GOMS para tarefa de apagar arquivo.

para alcançar o objetivo principal.

Além dos objetivos e subobjetivos, a notação em HTA possui o conceito de opera-

ção, que são elementos de mais baixo nível na hierarquia do organograma, acometidos a

representar ações de entradas ou saídas.

A organização de um conjunto de subobjetivos de um objetivo maior é feita por meio

de um plano. Cada plano define, por sua vez, as relações existentes entre cada subobjetivo,

as quais, podem ser do tipo: sequência “>” (um objetivo/operação atingido por vez);

seleção “/” (decisão entre um ou mais objetivos a serem atingidos ); ou concomitância

“+” (mais de um objetivo/operação atingido ao mesmo tempo).

No modelo da figura 2.10, observa-se a representação gráfica, por meio do HTA, de


objetivos, subobjetivos e operações, referentes à tarefa de lançamento de um projeto final

de curso em um sistema hipotético. Essa tarefa possui no primeiro plano o subobjetivo

Informar dados do projeto e a operação Enviar mensagem de confirmação e as-

sim que os dados do projeto são informados a operação é executada. O segundo plano

do diagrama apresenta como ocorre inserção de dados, sendo o cadastro do orientador

condicionado a não existência de informações prévias deste.

Figura 2.10: Exemplo de um modelo HTA, adaptado de Barbosa & da Silva (2010).

Como pode ser visto, o HTA enfoca as ações físicas e observáveis que são executadas

em uma tarefa do usuário, independentemente de estarem relacionadas com o software ou

não. O ponto de partida é o objetivo do usuário que é refinado em subobjetivos até chegar

a passos de mais baixo nível de interação, que podem ser representados em protótipos de

interface com o usuário.

A terceira e última forma de representação de tarefas apresentada neste trabalho é o

CTT, que foi criada com o propósito de auxiliar o design de aplicações interativas [Paterno

et al. 1997]. Para seus autores, o CTT permite que os profissionais de IHC focalizem seu

trabalho sobre os aspectos mais relevantes da interação usuário-sistema, evitando detalhes

de baixo nível de implementação, como layout de tela, tipos de menus, entre outros.

O CTT é baseado na representação de tarefas em uma estrutura em árvore, na qual

o elemento raiz representa o objetivo principal do usuário e abaixo dela as sub-tarefas


necessárias para atingir esse objetivo. Possui quatro tipos de tarefas sendo estas represen-

tadas por diferentes ícones gráficos:

• Abstract Tasks ( ): não se constitui em uma tarefa em si, mas uma representação

de composição das sub-tarefas;

• User Tasks ( ): representam as decisões do usuário durante a interação;

• System Tasks ( ): representam a resposta da aplicação para as ações do usuário;

• Interactive Tasks ( ): representam a interação propriamente dita entre usuário e

sistema.

Além das tarefas, o CTT possui oito diferentes operadores temporais para representar

o relacionamento entre tarefas de um mesmo nível e mais três operadores unários con-

forme representado na tabela 2.4.

Tabela 2.4: Operadores temporais do ConcurTaskTrees.

Operador Representação Descrição

Concorrency (concorrência) T1 ||| T2 Especifica que as tarefas (T1 e T2) pode ser executadas em qualquer ordem ou ao mesmo tempo.

Synchronization (comunicantes) T1 |[]| T2 Especifica que as tarefas (T1 e T2) trocam informação.

Enabling (ativação) T1 >> T2 Especifica que a tarefa T2 só deve ser inicializada após o término da tarefa T1.

Enabling with information passing (ativação com passagem de informação)

T1 [ ]>> T2 Especifica que a tarefa T2 só deve ser inicializada após o término da tarefa T1 e que esta passará informação para T2.

Desactivation (desativação) T1 [> T2 Especifica que a tarefa T1 é desativada pela tarefa T2.

Interruption (interrupção) T1 |> T2 Especifica que a tarefa T1 é suspensa até que a tarefa T2 finalize e será retomada do ponto em que parou.

Choice (escolha) T1 [ ] T2 Especifica que apenas uma das tarefas (T1 e T2) podem ser ativadas.

Independent (indenpendente) T1 |=| T2 Especifica que as tarefas (T1 e T2) pode ser realizadas em qualquer ordem.

Iteraction (iteração) T1 (n) Especifica que a tarefa pode ser executada n vezes.

Optional Task (tarefa opcional) [T1] Especifica que a realização da tarefa não é obrigatória.

Recursion (recursiva) T Possibilidade de incluir na especificação da tarefa ela mesma.

A figura 2.11 apresenta um modelo CTT para uma tarefa de reserva de quarto de


hotel. Nesse cenário, a tarefa abstrata HotelReservasion representa o objetivo principal

do usuário, e é alcançado por meio da escolha de um tipo de quarto, representada pelas

subtarefas de interação SelectSingleRoom, SelectDoubleRoom e o operador escolha

“[ ]”, além da marcação propriamente dita MakeReservation. Nesta subtarefa, o sistema

prepara e apresenta as disponibilidades referente ao tipo de quarto e o usuário faz sua

escolha.

Além da notação proposta para a modelagem de tarefas, o CTT possui uma ferramenta

computacional denominada CTTE (ConcurTaskTree Environment), cujo objetivo é propi-

ciar suporte às atividades de modelagem e análise de tarefas permitindo, inclusive, que

interfaces gráficas de usuário sejam geradas para múltiplas plataformas: web, desktops e

dispositivos móveis.

Figura 2.11: Exemplo de um modelo CTT, extraído de http://www.w3.org/2012/02/ctt/W3C (2013)

2.5 Síntese do capítulo

Como pôde ser visto neste capítulo, usabilidade é um dos fatores que contribuem

para qualidade de softwares interativos. E como atributo de qualidade deve ter a atenção

necessária dentro do processo de construção do software. As técnicas de modelagem da

interação usuário-sistema apresentadas, possuem ligeira divergência no tratamento dado

durante a especificação do sistema.

A proposta de modelagem da interação usuário-sistema a partir de use cases tem como


objetivo a decomposição do sistema em funcionalidade que este deve prover. Essa decom-

posição auxilia o design dos componentes da arquitetura interna do sistema, mas dificul-

tam que profissionais de IHC tenham uma visão global da interação. Ademais, os use

cases são geralmente descritos de forma textual, o que possibilita uma especificação deta-

lhada de elementos concretos de interface, como botões e ações de mouse, fato que inibe

o trabalho de designers de interação.

Por outro lado, as representações baseadas em tarefas, propostas pela comunidade de

IHC, são usadas para analisar o objetivo e propósito do que as pessoas fazem. Essa abor-

dagem permite a obtenção da visão global do que o usuário precisa fazer para alcançar

seu objetivo. Modelos de tarefas possuem uma notação mais formal como demonstrado

pelo HTA e CTT. Contudo, é possível identificar algumas limitações nesse método de re-

presentação da interação: (i) modelos de tarefas são carregados de conceitos e estruturas

que fogem ao conhecimento dos profissionais de ES, tornando-se, assim, um obstáculo a

estes profissionais; (ii) quando aplicados sobre tarefas complexas, a notação rapidamente

torna-se difícil de ser seguida; (iii) os modelos de tarefas não permitem representar cami-

nhos de exceção, ou seja, prever e tratar um erro que possa ocorrer durante a realização

da tarefa; (iv) assim como os use cases, os modelos descritos usando GOMS permitem a

descrição de tarefas com níveis de abstração muito baixo.

No próximo capítulo, serão apresentados alguns trabalhos relacionados que procuram

resolver a deficiência de comunicação entre as representações de IHC e ES.

Capítulo 3

Trabalhos Relacionados

Conforme apresentado na seção de motivação deste trabalho (capítulo 1), durante a

década de noventa preocupações com usabilidade eram consideradas apenas como parte

do design de interface do usuário, sendo este, executado após a fase de design arquitetural.

Nos últimos dez anos, pesquisadores têm mostrado que este tipo de tática tem elevado

os custos do projeto e apontam que o caminho é capturar e organizar os requisitos de

usabilidade em tempo de design arquitetural.

Um processo de desenvolvimento de software integrado e colaborativo torna-se uma

tarefa necessária para uma eficiente e produtiva interação entre todos os profissionais

envolvidos [Seffah 2008].

Neste capítulo relatamos cinco propostas de integração entre as atividades de ES e

IHC, sendo três relacionadas à modelagem da interação usuário-sistema e as demais fo-

cadas sobre a atividade de avaliação da arquitetura para suporte à usabilidade.

3.1 UMLi

Dentro das abordagens que propõem o uso da UML como ferramenta para modelagem

do software, e face à sua limitação para representar a modelagem da interface com o

usuário, Silva [Silva & Paton 2003] propôs a UMLi - Unified Modeling Language for

Interactive Applications. A UMLi é uma extensão da UML para representar o projeto

CAPÍTULO 3. TRABALHOS RELACIONADOS 35

da interface do usuário que, nesta abordagem, consiste na construção de dois diagramas:

user interface diagrams e activity diagrams.

O user interface diagram reúne o conjunto de classes e objetos de interação respon-

sáveis por representar os widgets que compõem o aspecto visual da interface do usuário -

modelo de apresentação. Cada user interface diagram possui um objeto chamado Fre-

eContainer ( ) que representa o elemento de mais alto nível da interface, no caso uma

janela. Um FreeContainer pode acomodar os seguintes objetos:

• Containers ( ): Um Container pode agrupar qualquer dos objetos descritos a se-

guir, inclusive ele mesmo. Esses objetos se equiparam aos frames utilizados em

interfaces concretas.

• Editors ( ): São objetos responsáveis, simultaneamente, por receber e mostrar

informações. Esses objetos representam, por exemplo, um componente de interface

do tipo edit que podem apresentar informações vindas do sistema e possibilitar a

alteração da informação nele contida.

• Displayers ( ): São responsáveis por mostrar informações ao usuário. Podem

representar componentes concretos como, por exemplo, os labels.

• Inputters ( ): São responsáveis por receber informações do usuário. Estes objetos

podem ser mapeados para componentes de interface do tipo combobox, edits, entre

outros.

• ActionInvokers ( ): São objetos que representam os eventos disparados pelo usuá-

rio como, por exemplo, os botões e links.

Já para representar uma visão do comportamento da interação usuário-sistema foi

criado o activity diagram como extensão ao diagrama de atividades da UML. O activity

diagram da UMLi define três categorias de SelectionStates, a saber:

• OrderIndependentState ( ): Este elemento identifica as atividades que serão exe-

cutadas, independente da ordem escolhida pelo usuário. Nestes casos, cada ativi-


dade deve ser executada uma única vez.

• OptionalState ( ): Indicado para situações em que o usuário deve optar por uma

das atividades possíveis. Assim como os OrderIndependentState um OptionalState

deve ter pelo menos duas atividades selecionáveis.

• RepeatableState ( ): Este elemento da linguagem indica que uma atividade se-

lecionada deverá ser executada continuamente até que o usuário determine o seu

fim.

A relação existente entre os diversos objetos da linguagem é realizada por meio dos

Interaction object Flows. A UMLi possui cinco tipos de fluxos de interação possíveis,

alguns destes estão representados na figura 3.2. As figuras 3.1 e 3.2 representam, respec-

tivamente, um exemplo de um user interface diagram e activity diagram da UMLi para

um cenário de pesquisa de livros. A interface do usuário está definida por meio de três

containers: o que representa os parâmetros (title, author e year) a serem pesquisados; o

que representa o resultado da pesquisa; e o que contém objetos de invocação de funcio-

nalidades (Search e Cancel) do sistema. Já o activity diagram representa a dinâmica da

interação, ou seja, por meio dele podemos identificar, por exemplo, que o usuário pode

escolher qual parâmetro será usado para buscar o livro.

SearchBook

Title Author Year

TitleParam AuthorParam YearParam

Results ResultValues

Seach Cancel

Figura 3.1: Exemplo de um user interface diagram da UMLi.


SearchBook

getTitle

getAuthor

getYear

:TitleParam

:AuthorParam

:YearParam

<<interacts>>

<<interacts>>

<<interacts>>

<<confirms>>

bpq.doQuery()

setResult(bq)

bqp:BookQueryParameter

bq:BookQuery

:Search

:SearchBook

:Cancel

:ResultValues

<<interacts>>

<<presents>>

<<cancels>>

SpecifyBookDetails

Figura 3.2: Exemplo de um activity diagram da UMLi.

Apesar do user interface diagrams permitir uma descrição abstrata interface, não po-

demos dizer a mesma coisa para os activity diagrams. Neste último, os SelectionStates

são utilizados sobre as chamadas de métodos concretos de objetos e não sobre os ele-

mentos abstratos de interface, existentes no user interface diagrams. Isso torna-se um

obstáculo para profissionais de IHC, pois estes não possuem o conhecimento do design

detalhado dos objetos internos do sistema. É possível, inclusive, que durante a fase de

modelagem da interação usuário-sistema ainda não se tenha a definição dos métodos dos

objetos que farão parte do sistema.

Outro fator limitante da UMLi é a ausência de mecanismos que estimulem a repre-

sentação de possíveis mensagens de erros, oriundas de uma falha do sistema ou de exe-

cução de ações equivocadas do usuário. Além disso, a UMLi não possui elementos que

possibilitem integrar interações existentes entre diferentes use cases, tornando, assim, a

representação fragmentada.


3.2 MoLIC

A MoLIC (Modeling Language for Interaction as Conversation) é uma notação para

dar suporte à criação de interfaces interativas, inicialmente concebida por Paula (2003)

e sendo posteriormente revisada por Silva (2005). Com suas bases teóricas na Semió-

tica [de Souza 2005], a MoLIC foi criada para tratar interação como uma conversa entre

usuário e sistema, este último caracterizado como preposto do designer na conversa. Para

a engenharia semiótica, a interface é uma mensagem elaborada pelos designers a qual o

usuário precisa decodificar para atingir seus objetivos.

O projeto para representar a interação usuário-sistema usando MoLIC é composto de

três artefatos inter-relacionados: lista de tarefas (HTA extendido), esquema de signos e di-

agrama de interação. É no diagrama de interação que está representado o diálogo possível

entre designer e usuário. Os elementos que formam o diagrama são (1) ubiquitous access,

(2) scene, (3) closing point, (4) system process, (5) user’s and designer’s utterance e (6)

breakdown transition.

O diagrama apresentado na figura 3.3 expressa um cenário de “Busca na Web” base-

ado em ferramentas como Google ou Yahoo. Nesse exemplo, por meio da cena Buscar,

usuário e preposto falam sobre o termo da busca (representado pelo diálogo d+u: termos)

enquanto que na cena Resultados falam sobre a exibição dos resultados da pesquisa (d+u:

resultado da busca). Como resultado da interação do usuário (u: buscar), o preposto pode

apresentar as seguintes falas: d: resultados encontrados ou d: nenhum resultado encon-

trado para os casos em que o usuário digita algum termo de pesquisa, ou d: busca vazia

para o caso em que o usuário não digitou nenhum termo de pesquisa.

Embora apresente um forte referencial teórico, a idéia de usar os conceitos da semió-

tica torna o uso da MoLIC um obstáculo na integração das atividades de IHC e ES, pois

suas estruturas de concepção da interação usuário-sistema são relativamente desconhe-

cidas para engenheiros de software. Isso é evidenciado por Ahmed & Metzker (2004),


Figura 3.3: Notação da linguagem MoLIC.

quando mencionam que métodos e técnicas de domínio restrito são as principais causas

para não se ter uma prática mais ampla do design centrado no uso. Além do uso da se-

miótica para representar a fala entre designer e usuário, a MoLIC faz uso do conceito

de modelo de tarefas, apresentado na seção 2.4, fato que restringe, na visão da ES, a

representação das unidades funcionais ou serviços que constituem o sistema.

3.3 ALaDIM

ALaDIM (Language for Description of Interactive Message) [Costa Neto 2013] é

uma notação para modelagem abstrata da interação usuário-sistema. ALaDIM possui

uma notação mais próxima da linguagem utilizada pelos engenheiros de software. Tem

como objetivo representar as funcionalidades oferecidas pelo sistema e a forma pela qual


os usuários podem interagir com elas numa perspectiva de ação e reação.

Para representar o processo de interação, ALaDIM possui dois grupos de elementos:

os gráficos (espaços de interação, função de domínio e transições) e textuais (interações

básicas e operadores). Os elementos textuais podem ser vistos como elementos chave

para representar “o que” o usuário pode fazer sobre o sistema e “como”. Por meio da

figura 3.4 (extraído de Neto et al. (2011)), é possível ter uma visão do uso de cada um dos

elementos dessa linguagem e como eles permitem organizar a interação usuário-sistema.

Figura 3.4: Modelo de diagrama ALaDIM com algumas funcionalidades para caixa ele-trônico.

Apesar de ALaDIM possuir um vocabulário capaz de representar os elementos e as


condições necessárias para o usuário interagir com o sistema, não fica caracterizado na

linguagem sua ligação com outros artefatos do projeto de software a exemplo de use ca-

ses ou data models. Isso fica evidente a partir do momento que um modelo ALaDIM é

construído sem que seja discriminado o tipo de usuário (ator) que irá interagir com o sis-

tema ou, ainda, pela ausência de características (tipo de dado e tamanho) das informações

que o usuário pode/deve manipular durante sua interação. Outra dificuldade apresenta-se

quando é necessário identificar, sobre o diagrama, a relação entre use case. Neste caso

apenas uma representação por meio de áreas hachuradas foi prevista por seus autores.

3.4 Software architecture that supports usability (STA-

TUS)

Com o propósito de minimizar os impactos das decisões do projeto de usabilidade so-

bre a arquitetura do software, Folmer & Bosch (2003) iniciaram suas pesquisas definindo

um framework para representar a ligação entre requisitos de usabilidade mais abstratos

e os padrões mais específicos de usabilidade. As camadas definidas por Folmer estão

descritas abaixo e suas relações podem ser observadas na figura 3.5:

Figura 3.5: Framework de usabilidade, adaptado de Folmer & Bosch (2003).

• Usability attributes: esta camada incorpora um conjunto de características abstratas


sobre usabilidade, são elas: (i) learnability, caracteriza o sistema por sua capacidade

de proporcionar um fácil e rápido aprendizado para usuários novos; (ii) efficiency,

refere-se ao número de tarefas que o usuário pode executar corretamente por uni-

dade de tempo; (iii) reliability, atributo que avalia a possibilidade de recuperação

do usuário frente aos erros cometidos durante a realização de um tarefa; (iv) satis-

faction, medida do nível de satisfação do usuário com o sistema.

• Usability properties: as propriedades incorporam os princípios de design que pes-

quisadores em IHC acreditam ter influência sobre a usabilidade de sistemas. Estas

propriedades podem ser usadas como requisitos na fase de design do projeto (ex.:

prover feedback para o usuário, prover controle explícito da tarefa, etc).

• Usability patterns: esta camada faz referência às técnicas que podem ser aplicadas

para endereçar as propriedades de usabilidade. Para esta camada foram levanta-

dos vários padrões catalogados por Tidwell (2005) que possuem impactos sobre o

design arquitetural do sistema de software.

Como forma de contribuir com a avaliação da arquitetura de software para suporte

à usabilidade, Folmer et al. (2004) propõem uma técnica denominada SALUTA (Scena-

rio based Architecture Level Usability Analysis). Está técnica consiste na avaliação da

arquitetura a partir de cenários de uso, onde estes são relacionados aos quatro atributos

de usabilidade. Para cada cenário de uso é atribuído um valor numérico (1 a 4) que de-

termina a prioridade dos atributos de usabilidade. A partir deste ponto, é realizado uma

verificação sobre a arquitetura do software com o objetivo de identificar se a mesma in-

clui padrões ou propriedades de usabilidade que estejam relacionados com o atributo. O

resultado da análise pode ser apresentado em forma de resposta simples (por exemplo,

suporta ou não), ou mais elaborada em termos percentuais (suporta 70%).

Embora o trabalho de Folmer e seus colegas tenha ajudado a co-relacionar princípios

abstratos de usabilidade a artefatos concretos de interação usuário-sistema, a qualidade

da avaliação, proposta em sua técnica, depende muito da quantidade de evidências de


padrões e propriedades encontrados sobre projeto da arquitetura do sistema. Isso torna o

processo avaliativo uma tarefa difícil, pois a arquitetura de um software possui diversos

aspectos que não são facilmente representados em um único modelo, sendo necessário

um conjunto de visões arquiteturais para representá-la.

3.5 Usability-driven software architecture patterns

Bass & John (2003), usando uma abordagem bottom-up, geraram um catálogo com

27(vinte e sete) cenários que expressam atributos de usabilidade e que possuem impli-

cações significativas sobre a projeto arquitetural do software. Esse estudo foi realizado

a partir de consultas a trabalhos de pesquisas e experiências de projetos em desenvolvi-

mento de software. Além de descrever os benefícios de usabilidade trazidos por cada

cenário, os autores propõem, ainda, uma ou mais táticas arquiteturais que podem ser usa-

das para implementar cada cenário.

Desta forma, os desenvolvedores ao selecionarem um determinado cenário, poderão,

além de conhecer seus benefícios, ter uma ideia do que precisa para implementá-lo. Esta

característica é um diferencial para outras listas que são encontradas na literatura de IHC

(como exemplo, Nielsen’s Heuristics). Por exemplo, para um cenário de cancelamento

da ação de um usuário, o arquiteto pode usar uma tática de “preemptive scheduling” para

que um componente listener possa responder à solicitação de cancelamento da ação e um

“recording” para restaurar o estado inicial do sistema.

Esses benefícios e táticas são organizados, também, em forma de uma matriz bidimen-

sional, e têm o propósito de servir como fonte consultiva para as atividades de avaliação

ou design da arquitetura de sistema. Assim, caso a equipe de desenvolvimento identifique

a necessidade de um dos cenários de usabilidade, então poderá usar a matriz para procurar

pela(s) célula(s) ocupada(s) por este cenário. A identificação de um cenário pode ocor-

rer através de consulta ao próprio catálogo, uma avaliação heurística ou outra técnica de


avaliação. No apêndice A.1, é apresentada uma imagem com detalhes da matriz utilizada

para auxiliar no mapeamento entre benefícios de usabilidade e táticas arquiteturais.

Embora essa proposta ajude a pensar em decisões arquiteturais para cenários que me-

lhoram a usabilidade do sistema, o trabalho apresenta algumas limitações: (i) assim como

a proposta de Folmer & Bosch (2003), soluções de design de interação estão restritas aos

cenários já catalogados. Isso faz com que um novo tipo de cenário não seja tratado em

tempo de design arquitetural, ou que haja um tentativa de aproximação via analogia com

cenários já catalogados, sem garantias de sucesso, gerando possíveis problemas de usabi-

lidade do sistema e custos elevados de reprojeto; (ii) se uma tática for utilizada para um

determinado cenário, não há garantias que esta mesma implementação servirá para outro

cenário.

3.6 Comparação entre notações

No capítulo 2 e durante este capítulo foram apresentadas algumas notações utilizadas

para representar o projeto de IHC, sendo a UMLi, MolIC e ALaDIM propostas para apoiar

a comunicação entre profissionais de engenharia de software e IHC. Temos argumentado

que as propostas citadas não têm apresentado as características necessárias para integrar

conceitos do projeto de interação, da área de IHC, à definição de use cases.

Com base nos conceitos apresentados no capítulo 2 foram extraídas cinco caracterís-

ticas básicas para um notação atender/representar interesses dos engenheiros de software

e IHC. Estas características estão apresentadas na tabela 3.1, que também expõe a capaci-

dade das notações apresentadas até o momento em atender ou não a estas características.

É importante destacar que, embora os autores de ALaDIM proponham que esta no-

tação seja integrada aos use cases, não consideramos assim nesta tese, haja visto que a

única referência aos use cases é feita por meio de produção de hachuras sobre o modelo

de interação. Essa técnica restringe os intereses dos engenheiros de software pois partes


das descrições de use cases, importantes para o projeto de engenharia, não podem ser

representados.

Tabela 3.1: Quadro comparativo entre as notações.

Notações /Caracterís/cas Visão global Caminhos

alterna/vos

Descreve problemas na interação

Expressa Artefatos concretos

Integrado com Use cases

GOMS (Cap. 2) Não Sim Não Sim Não

CTT (Cap. 2) Não Sim Não Não Não

HTA (Cap. 2) Não Sim Não Não Não

UMLi Não Sim Não Sim Não

MoLIC Sim Sim Sim Não Não

ALaDIM Sim Sim Sim Sim Não

Analisando a tabela 3.1 percebe-se que nenhuma das representações apresentadas

atende completamente as características necessárias para apoiar o projeto de interação

e use cases. Considerando que o principal propósito desta tese é apoiar a construção

do projeto de interação usuário-sistema integrado à definição de use cases, nenhuma das

notações apresentadas possui esta característica.

Observa-se, também, que mesmo com origens na comunidade de IHC, notações como

GOMS, CTT, HTA e UMLi não possuem características que habilitam os projetistas da

interação do sistema obterem uma “visão global” da interação ou até mesmo “descrever

problemas na interação”.

Outra importante característica apresentada no capítulo de fundamentação desta tese

refere-se a possibilidade dos projetistas estarem especificando, sobre o modelo de inte-

ração, aspectos concretos de interface do usuário ou da arquitetura interna do sistema.

Neste contexto, UMLi e ALaDIM deixam que funções internas ao sistema sejam especi-

ficadas, quando o ideal seria o uso de visões especificas para esse tipo de especificação.

Um exemplo disso é conceito de função de domínio da notação ALaDIM.

Portanto, no próximo capítulo apresentaremos uma notação com as características até


aqui apontadas como necessárias para integrar interesses de engenheiros de software e

IHC dentro do projeto de interação usuário-sistema.


Nesse capítulo foi apresentado algumas tentativas de integração entre as atividades de

ES e IHC para o desenvolvimento de sistemas interativos. Essas tentativas estão organi-

zadas em dois grupos bem definidos: (i) os que tratam o problema a partir da modelagem

da interação e (ii) os que abordam o problema sobre a ótica do projeto e avaliação da

arquitetura do sistema.

As abordagens definidas a partir da modelagem da interação (UMLi, MoLIC e ALa-

DIM) possuem como benefício o fato de tratarem o problema sem restrição de cenários

como é caso da segunda abordagem. No entanto, verifica-se que algumas características

centrais destas notações tornam-se fatores limitantes para integração de atividades.

Com ênfase na modelagem da interação, apresenta-se no próximo capítulo uma pos-

posta de notação com objetivo de minimizar as deficiências deixadas pelos trabalhos aqui

apresentados.

Capítulo 4

VL4UCD: Notação e Ferramenta

Neste capítulo serão apresentadas e fundamentadas a notação de uma linguagem para

descrever use case e uma ferramenta para apoiar a modelagem da interação usuário-

sistema utilizando práticas compartilhadas entre profissionais de engenharia de software

e interação humano-computador.

4.1 Notação VL4UCD

A Visual Language for Use Cases Description (VL4UCD) foi criada para ser uma

notação capaz de representar os interesses dos profissionais de ES e IHC durante o ciclo

de desenvolvimento de softwares interativos. A linguagem está fundamentada a partir do

conceito de use cases, que são moldados em termos de intenções do usuário e responsa-

bilidades do sistema. Além disso, os elementos da linguagem foram pensados de forma a

serem mais familiares e intuitivos para aqueles que trabalham na modelagem da interação

usuário-sistema.

A linguagem trata a interação entre usuário e sistema como um statechart, no qual a

troca de estados é feita a partir das ações dos usuários sobre os componentes de interface

com o objetivo de acionar alguma funcionalidade do sistema, e as reações do sistema, que

a partir do que foi solicitado e enviado pelo usuário, fará o processamento necessário para

atender tais solicitações.

CAPÍTULO 4. VL4UCD: NOTAÇÃO E FERRAMENTA 48

A representação gráfica de cada elemento da VL4UCD na descrição de um modelo de

interação pode ser visto na figura 4.1 e estão assim definidos:

Transições

Figura 4.1: Elementos gráficos da VL4UCD.

a. Opening Interaction e Closing Interaction: estes elementos representam o início e

encerramento da interação de um use case. Diferentemente de ALaDIM e MoLIC,

aqui esses elementos apoiam a reflexão sobre as restrições de início da interação e

quais condições devem ser alcançadas ao seu final. Isso é alcançado por intermédio

das propriedades precondition e postcondition encontradas, respectivamente, nos

elementos opening interaction e closing interaction. Por meio do elemento opening

interaction, podemos, ainda, representar as seguintes propriedades: actors, brief

description e use case name. Na figura 4.2, visualiza-se a representação destes

elementos no metamodelo da linguagem.

Figura 4.2: Subconjunto do metamodelo da VL4UCD - Elementos OpeningInteraction,ClosingInteraction, Scene e SystemProcess


b. System Process: representa o processamento realizado pelos componentes internos do

software para atender as solicitações dos usuários, realizadas sobre a interface com

o sistema.

c. Scene: representam os momentos em que o usuário pode realizar suas ações de in-

teração para atingir um certo objetivo. Um use case pode conter uma ou mais

scenes. Cada scene possui um conjunto de elementos de interaction e transition.

As interações propiciam ao usuário realizar as ações necessárias para alcançar seus

objetivos, além de permitir a observação dos resultados oriundos do processamento

do sistema. As transições, por sua vez, são responsáveis por ativar os objetos fun-

cionais internos do sistema e trazer informações do sistema para o usuário. Nos

próximos itens, estes elementos são descritos de forma detalhada. A figura 4.3

representa a estrutura dos elementos envolvidos em uma scene em VL4UCD.

Figura 4.3: Subconjunto do metamodelo da VL4UCD - Elementos que compõem umascena.

d. Basic Interaction: em VL4UCD, os elementos de interação básica (enter, select,

perceive, activate) possuem o mesmo conceito existente em ALaDIM, ou seja, re-

presentam as ações escritas em alto nível de abstração para as ações que os usuários

podem executar durante a interação com o sistema. A diferença para ALaDIM estão

nas propriedades inseridas em cada elemento para endereçar algumas preocupações

dos profissionais de ES. Um exemplo disso são as propriedades que especificam


como as informações do modelo de dados da aplicação são usadas no projeto de

interface. Conforme pode ser verificado na figura 4.4, as interações básicas são as

seguintes:

• Enter: usado para especificar uma interação de entrada de informação pelo

usuário. Em termos de interface concreta, este poderia ser codificado, por

exemplo, como uma caixa de texto para entrada de dados. As propriedades

existentes neste elemento permitem configurar o type e size da informação que

será manipulada, além das restrictions sobre essa manipulação. O elemento

enter permite a configuração de tipos numéricos, alfanuméricos e objetos de

domínio, este último quando o projeto já possui modelo de domínio definido;

• Perceive: usado para especificar uma interação de percepção da informação

como um texto não editável. O Perceive, assim como o elemento enter, pos-

sui a propriedade type que permite configurar desde um objeto do modelo de

domínio até uma simples informação textual;

• Select: usado para especificar uma interação a qual o usuário precisa selecio-

nar uma informação. Isso pode, por exemplo, ser traduzido para widgets de

interface do tipo combo-box ou list-box;

• Activate: usado para especificar a ativação de uma das funcionalidades do

sistema ou acionar outra scene. Representam de forma abstrata botões e/ou

link sobre a interface gráfica do usuário.

e. Transitions: As transições representam as trocas de estados entre os elementos scene

e system process ou entre duas scenes. Essas trocas são demandas pelas ações

do usuário em uma determinada scene e as reações do sistema para o que lhe foi

requisitado. Conforme apresentado na figura 4.5, a VL4UCD suporta três tipos de

transições: action, special action e reaction.

As actions transitam entre os elementos scene e system process dentro de um mesmo

use case. Cada action possui um conjunto de propriedades que permite endereçar


Figura 4.4: Subconjunto do metamodelo da VL4UCD - Elementos interação básica.

algumas características, como: business rule, que permite representar a regra de

negócio que o sistema deverá obedecer durante o processamento da funcionalidade

requisitada e a source interaction que permite associar qual interação básica está

demandando a ação.

As transições do tipospecial actions, representam ações que demandam a extensão

ou inclusão de um use case externo, permitindo o acesso a scenes fora do escopo do

use case base. Seu objetivo é possibilitar a representação da visão global da intera-

ção para um determinado objetivo do usuário. Special actions são diferenciadas das

demais actions por meio dos estereótipos «extension» e «inclusion» e da proprie-

dade target use case, responsável por indicar qual use case está sendo acionado. A

special action do tipo extension possui, ainda, a propriedade condition que define

as circunstâncias que levaram ao acionamento do use case.

Quanto às reações do sistema às solicitações do usuário em uma scene, estas podem

ser do tipo reaction success, reaction exception ou synchronous. A reação do tipo

reaction success ocorre quando os objetos internos do sistema conseguem reali-

zar as solicitações do usuário, enquanto as do tipo reaction exception são respostas

do sistema à situações de anormalidade durante o processamento. A existência

desse tipo de elemento da linguagem, tem como objetivo estimular os analistas


a pensarem não apenas em caminhos de sucesso, mas em situações de insucesso

durante a interação.

A reação do tipo synchronous permite a representação de um padrão de interação

do tipo progress indicator [Tidwell 2005], na qual o usuário pode observar o status

de processamento de uma determinada funcionalidade requisitada e até interferir no

processamento, se for o caso. Esse tipo de representatividade é um dos requisitos

propostos por Nielsen [Nielsen 1993] para uma boa usabilidade. No entanto quando

não idealizado durante as fases iniciais do processo de desenvolvimento torna-se um

dos motivos de re-designer da arquitetura interna do sistema [Bass & John 2003].

Neste sentido, o elemento synchronous auxilia na representação de cenários que

possibilitam minimizar os impactos do projeto de interface sobre a arquitetura do

sistema.

f. Operators: Assim como as basic interactions, o conjunto de operadores usados na

VL4UCD são oriundos de ALaDIM. Os operadores são responsáveis pela ordena-

ção do diálogo do usuário dentro de uma scene, proporcionando uma organização

estrutural e temporal da interação. Na VL4UCD, são utilizados quatro operadores:

(i) sequence para indicar a ordem em que as interações devem ocorrer; (ii) repeat

Figura 4.5: Subconjunto do metamodelo da VL4UCD - Transições de estado.


Figura 4.6: Subconjunto do metamodelo da VL4UCD - Operadores de interação.

para determinar que algumas interações devem ser realizadas repetidamente; (iii)

join para indicar que as interações devem ocorrer em conjunto, mas em qualquer

ordem; e (iv) choose que indica uma escolha entre as interações possíveis.

4.2 Projeto de Software e VL4UCD

Devido as diferentes preocupações e níveis de conhecimento dos Stakeholders, um

projeto de software não tem uma representação única. Ao documentar requisitos, geral-

mente é possível distinguir três perspectivas para representar o sistema, a saber : estrutu-

rais, funcionais e comportamentais. Cada uma dessas perspectivas representa o sistema

ou parte dele do ponto de vista de um conjunto de interesses conexos [Pohl & Rupp 2011].

Em abordagens centradas em objeto, use cases são a base para prover essas perspectivas

[Garlan et al. 2010].

Pelo que temos argumentado, os use cases são insuficientes para representar a inte-

ração usuário-sistema. Neste contexto, propõe-se uma atividade de design de interação

entre as atividades de especificação de use cases e a de modelagem dos componentes

internos do sistema. É durante a atividade de design de interação que os modelos de

interação usuário-sistema são produzidos utilizando a notação VL4UCD.

Os modelos construídos com a VL4UCD tem como objetivo permitir uma melhor

compreensão, por parte dos stakeholders, da interação usuário-sistema e, portanto, prover


o suporte as decisões para construção dos demais modelos/perspectivas do projeto. Com

isto, não há intenção de substituir os atuais artefatos (diagramas e modelos textuais) para

especificação de use cases, mas, tão somente, contribuir para organização das informações

necessárias para o desenvolvimento do software.

As subseções seguintes, tratam do passo-a-passo necessário para desenvolver os mo-

delos de interação com VL4UCD e a forma como estes modelos podem ser integrados

com os demais modelos do projeto, além dos benefícios que podem ser obtidos a partir

de seu uso.

Construção dos modelos VL4UCD

Como as descrições textuais, os modelos VL4UCD são desenvolvidos a partir de um

diagrama de use case. O projeto de interação com a VL4UCD pode ser definido em dois

estágios: (i) projeto estrutural da interação e (ii) projeto detalhado da interação. Esses

estágios permitem que os modelos sejam melhorados gradualmente com o amadureci-

mento dos requisitos dentro do processo de desenvolvimento do software. Desta forma,

o modelo de interação usuário-sistema não precisa ser finalizado no estágio inicial, algo

que poderia impedir o fluxo de outras atividades do projeto.

Durante o projeto estrutural, o designer deve concentrar-se na composição da intera-

ção, como: organização das cenas, escolha das interações básicas e mensagens trocadas

entre as cenas e o sistema. Neste momento, é importante definir algumas propriedades

dos elementos já postos no modelo inicial, a saber: (a) nome do use case, atores e pré-

condições existentes no elemento Opening Interaction; (b) tipo e tamanho no elemento

Basic Interaction. Tal modelo inicial permitirá a visualização dos interesses da IHC, bem

como os aspectos de interação que podem ser relevantes para a estrutura interna dos com-

ponentes do sistema.

A figura 4.7 refere-se ao projeto estrutural da interação para o use case Pesquisar

Aluno. Este use case permite que o usuário pesquise por alunos de uma escola. Anali-


sando o modelo apresentado é possível analisar alguns dos interesses de IHC – caminhos

de interação e mensagens trocadas entre o usuário e o sistema – além disso torna-se pos-

sível avaliar os impactos desta solução sobre os componentes internos do sistema. Por

exemplo, para a cena FeedBack existir, os engenheiros de projeto deve fornecer com um

conjunto de componentes para suportar esse tipo de funcionalidade. Daí a necessidade de

termos o projeto estrutural da interação ainda durante a fase inicial do projeto de software.

Figura 4.7: Projeto estrutural da interação - UC: Pesquisar aluno.

Durante o projeto detalhado da interação, os designers devem enfatizar a organiza-

ção da interação do usuário dentro de cada cena. Existem situações em que esta ordem

é importante, como o momento em que o usuário deve decidir se deseja realizar uma

busca pelo nome ou departamento do aluno. A fim de definir a ordem das interações, é

necessário usar os operadores (sequence, repeat, join echoose) da notação.

No modelo da figura 4.7, por exemplo, a cena Efetuar Pesquisa não indica a ordem

das interações ou mesmo se elas são mutuamente exclusivas. Um redesenho deste modelo

é ilustrada na figura 4.8. No novo modelo de interação, supõe-se que o usuário, a fim de

atingir seu objetivo, deve digitar o nome ou o departamento do estudante e só depois

disso ativar a interação básica Consultar. Por esta razão, os operadores sequence e


choose foram utilizados. A figura 4.9, apresenta uma sugestão de protótipo de interface

para a cena Efetuar Pesquisa. No primeiro momento (figura 4.9a), o usuário deve

escolher entre pesquisar por nome ou departamento, selecionando o componente radio

button no formulário. Após selecionar o método de busca, o usuário deve digitar o termo

desejado e ativar o botão Consultar. Seguindo as diretrizes do modelo de interação, este

botão é ativado somente após os dados serem introduzidos na área escolhida (ver a figura

4.9b).

Figura 4.8: Projeto detalhado da interação para o use case Pesquisar Aluno.

A organização das interações em uma cena pode ocorrer em fases mais avançadas

do projeto de software. Isto porque, esse tipo de ajuste impacta tão somente na camada

de apresentação do software. O uso do padrão MVC, por exemplo, é uma das técnicas

utilizadas para assegurar que tais mudanças na interface podem ocorrer e que a estrutura

interna do software não necessita de ser alterada.

Além da organização da interação, é possível, nesta fase, realizar outras configurações

no modelo, tais como: condições de transição, regras de negócio, entre outras configura-

ções que completam a descrição do use case.


Viewpoint de engenharia de software

Do ponto de vista de engenharia de software, a VL4UCD trabalha integrada com os

outros modelos que representam o sistema. Isso é possível porque VL4UCD representa a

“essência” da interação usuário-sistema a partir dos use cases. Assim, os modelos podem

ser mutuamente verificados em termos de sua plenitude e de coerência com os requisitos

modelados. Desse modo, os possíveis custos de alterações no projeto podem ser minimi-

zados. Na sequência são descritos detalhes sobre a integração da VL4UCD com a pers-

pectiva estrutural (diagrama de classe e modelo de dados) e a perspectiva comportamental

(diagrama de sequência) do software.

• Correspondências entre VL4UCD, diagramas de classes e modelo de dados:

Muitos dos elementos de um modelo de interação, desenvolvidos com a notação

VL4UCD, estabelecem relações com modelos de classe e/ou modelos de dados.

Por exemplo, analisando o modelo na figura B.4 (ver apêndice B), elementos de in-

teração básicos, tais como senha, saldo e número da conta podem ser mapeados

para atributos de uma classe Conta. Cada atributo pode ser, ainda, pormenorizado

sobre seu tipo, tamanho e restrições, como é representado na figura 4.4 (metamo-

delo VL4UCD). Além disso, interações básicas do tipo activate, representam uma

funcionalidade do sistema. Assim, seria possível incorporar dentro da uma classe

Conta, métodos para verificar o saldo, sacar, depositar ou encerrar a conta, por

Figura 4.9: Prototipo de interface com usuários - UC: Pesquisar aluno.


exemplo.

• Correspondências entre VL4UCD e diagramas de sequência:

No que diz respeito aos modelos representados por diagramas de sequência e mo-

delos VL4UCD, sua correspondência está centrada sobre as mensagens trocadas

entre os usuários e o sistema. As figuras 4.10 e 4.11 representam os diagramas de

sequência, resumido, referente ao use case Checar Saldo, incluído no modelo de

interação representado na figura B.4. A figura 4.10 representa o caso de sucesso do

cenário, enquanto a figura 4.11, o caso em que o usuário insere dados errados e o

sistema emite um alerta.

Figura 4.10: Diagrama de sequência para o use case Checar Saldo (caso de sucesso).

Nota-se que, em ambos os diagramas de sequência existem mensagens que tam-

bém apresentam-se no modelo criado com a VL4UCD. Alguns elementos, como as

interações básicas, são claramente visíveis durante as trocas de mensagens entre o

usuário e o componente de interface gráfica (GUI), por exemplo: activate:Conta,

activate:senha, perceive:conta inválida. Outros podem ser observados en-


Figura 4.11: Diagrama de sequência: Checar Saldo (caso de falha).

tre os elementos de software, tais como o método saldo(), que existe entre o com-

ponente GUI e o controlador. Este método está representado no modelo da figura

B.4 como uma transição que é disparada através da respectiva interação básica na

cena Fechar conta.

Como é possível verificar, os modelos de interação desenvolvidos com VL4UCD

não estão isolados das demais perspectivas do software. Várias decisões tomadas

sobre o modelo de interação muita das vezes exigem uma correspondência com

outros modelos, mas com foco diferente.

Viewpoint de interação humano-computador

Do ponto de vista IHC, a VL4UCD pode ser considerado um recurso importante para

o desenvolvimento de protótipos de interface. Em geral, a transformação de um modelo

VL4UCD num protótipo de interface pode ser efetuada mapeando-se as cenas para for-

mulários (janelas) do sistema e interações básicas para widgets. Interações básicas do tipo

activate podem ser mapeados para botões ou itens de menu, no caso de ativação de funci-

onalidades, ou hyperlinks, quando se deseja apenas realizar uma navegação. No entanto,


soluções mais sofisticadas podem ser desenvolvidas já que VL4UCD permite uma descri-

ção abstrata da interação, liberando, assim, os designers à concentrar-se em seu processo

criativo.

Os modelos desenvolvidos com a notação VL4UCD podem propiciar, ainda, reflexões

sobre o comportamento de interação usuário-sistema. Assim, com base nos modelos, é

possível avaliar o caminho que o utilizador do sistema deve seguir para atingir seus ob-

jetivos de forma adequada. Uma avaliação das interações nas fases iniciais do desenvol-

vimento do software pode ajudar a encontrar, de forma preventiva, problemas durante a

utilização do sistema.

Ao contrário de algumas propostas orientadas a tarefa, exposta no capítulo 2, a VL4UCD

possui um mecanismo (reaction exception) para estimular os designers a pensar em pos-

síveis situações mal sucedidas durante a interação do usuário. Isso permite projetar inte-

rações (caminhos) que ajudam os usuários a se recuperarem de erros durante a interação

com software. Por exemplo, no modelo representado na figura B.4, a reação de exceção

conta inválida será provocada quando o usuário fornecer o número da conta bancária

errado. Outra maneira de lidar com erros de interação é através do uso dos operadores

da VL4UCD. Em outras palavras, na cena Checar Saldo, o operador sequence informa

que, ao se ativar a funcionalidade Saldo, o usuário deve primeiro ter fornecido a senha.

Essa organização da interação é uma medida preventiva e evita que o usuário possa acio-

nar funcionalidades antes do momento adequado e deve ser codificada na interface pelos

desenvolvedores.

Benefícios para o projeto de software

Como já mencionado neste trabalho, normalmente os problemas de usabilidade são

analisadas apenas em estágios avançados do processo de desenvolvimento do software

[Folmer & Bosch 2008]. Bass & John (2003) mostram que esta prática é perigosa, pois

muitas das decisões do projeto de interface impactam sobre a arquitetura do software


(estrutura interna de componentes). Com o objetivo de entender essa relação causa-feito,

a comunidade científica mapeou alguns padrões de interação que possuem impacto sobre

a arquitetura do software, a saber: feedback , undo , cancel, wizard, entre outros.

Naturalmente, esses padrões de interação não são a única forma de alcançar uma boa

usabilidade. É possível que cada empresa tenha suas próprias diretrizes com padrões de

interação.

Uma boa comunicação entre os profissionais de ES e IHC desde os estágios iniciais

do projeto pode ser um elemento vital para antecipar problemas no projeto de interface e

diminuir o seu impacto no processo de desenvolvimento. É a partir desse contexto que a

VL4UCD pode servir como ferramenta para auxiliar a comunicação e para representar as

possíveis soluções de um projeto de interação.

Após seu desenvolvimento, os modelos de interação devem ser validados, a fim de

verificar se todas as preocupações dos stakeholders do sistema foram abordadas. Entre as

técnicas para validação sugerimos o avaliação por perito e/ou a inspeção. Na primeira

técnica, os modelos desenvolvidos com VL4UCD são apresentados a um especialista para

que o mesmo possa expresar sua opinião sobre a qualidade da interação. Já na técnica

de inspeção, os modelos são avaliados por uma equipe de inspetores, geralmente com

base em uma lista de verificação (checklist). Independentemente de qual técnica é usada,

ao final do trabalho um documento com as observações feitas deve ser escrito para dar

suporte a um possível trade-off entre stakeholders.

Alguns do benefícios para o projeto de desenvolvimento e validação dos modelos de

interação são os seguintes:

• Encontrar possíveis problemas de usabilidade - Neste ponto, não há nenhuma re-

ferência às cores, fontes ou layouts, mas sim para a estrutura do diálogo entre o

usuário e o sistema, por exemplo: avaliar a necessidade de feedback para as ações

dos usuários; avaliar a possibilidade de reverter as ações incorretamente exibidas

ao usuários; e avaliar os mecanismos de prevenção e tratamento de erro durante a


interação;

• Reduzir os impacto do projeto de interação na arquitetura do sistema;

• Integração de requisitos de engenharia de software e de interação humano-computador;

• Compartilhar informações entre o modelos de ES(UML) e IHC (VL4UCD).

4.3 Use Case Description Tool

O uso de ferramentas para auxiliar atividades do processo de desenvolvimento é uma

prática rotineira na engenharia de software [Sommerville 2010]. Nessa direção, como

forma de apoiar as atividades de modelagem da interação usando a VL4UCD, foi desen-

volvida uma ferramenta CASE1 denominada Use Case Description Tool - UCDT. Seu

propósito é auxiliar na manipulação dos elementos da linguagem de forma intuitiva, mi-

nimizando o esforço daqueles que trabalham na modelagem, além de proporcionar ade-

quado ambiente de análise da interação usuário-sistema.

Com o objetivo de potencializar o uso de recursos já existentes para construção de

editores gráficos, a UCDT foi desenvolvida como forma de plugin para a IDE Eclipse2.

A UCDT foi construída sobre o projeto Eclipse Modeling que tem como base os fra-

meworks EMF (Eclipse Modeling Framework), GEF (Graphical Editing Framework) e

GMF (Graphical Model Framework).

A UCDT é composta da área de workbench, files project, properties e tool palette.

Cada uma das áreas em destaque na figura 4.12 possui características de funcionamento

semelhantes as já existentes na IDE Eclipse e consideravelmente utilizadas na maioria

das ferramentas de apoio à construção de software. Para construir um modelo de intera-

ção, o usuário deve criar um diagrama do tipo VL4UCD e passar a editá-lo na área de

workbench. A montagem do modelo deve ser realizada arrastando-se os elementos da

linguagem da tool palette para o workbench.

1Computer-Aided Software Engineering2http://www.eclipse.org


A edição das propriedades dos elementos do modelo é realizada a partir da área de

properties. Em outras palavras, ao selecionar uma transição do tipo Action no modelo, as

propriedades (bussinnes, source basic interaction, etc) desse elemento são apresentadas

na área de propriedades da ferramenta. Isso permite que o modelo fique menos poluído

textualmente, permitindo, assim, que a visão de interação seja ressaltada sem que, para

isto, informações importantes para a construção do sistema sejam perdidas.

4.4 Contribuições da VL4UCD

Como pode ser visto por meio dos metamodelos da VL4UCD (seção 4.1) nossa lin-

guagem apresenta um conjunto de propriedades capaz de capturar não somente aspectos

da interação usuário-sistema, mas, também, expressar detalhes inerentes aos use cases,

sendo isto um diferencial semântico em relação as linguagens apresentadas neste traba-

lho. Embora ALaDIM possua referência aos use cases, a semântica da linguagem não

apresenta elementos para representá-los adequadamente, restringindo-se a delinear partes

do diagrama de interação com áreas hachuradas.

Neste contexto, apresentamos em seguida os principais elementos de use cases que

estão representados na VL4UCD e contam como uma das suas contribuições em relação

as demais notações estudadas e apresentadas nesta tese. Além disso, descrevemos como

esses elementos podem ser representados dentro da VL4UCD.

4.4.1 Atores, objetivo e condições de execução

A documentação de use case geralmente começa pela definição dos seguintes ele-

mentos: atores; descrição de um breve resumo explicando seu objetivo; as pré-condições

necessárias para execução do use case e as pós-condições, ou seja, estado do sistema após

o término da execução do use case.

Na UML os atores podem ser qualquer elemento externo que interaja com o software


(usuários e eventualmente algum hardware ou até mesmo outro software). O modelo de

interação VL4UCD aborda tão somente atores humanos (usuários), já que a linguagem

tem o propósito de representar a interação usuário-sistema. Neste cenário, os atores na

Vl4UCD representam os papéis desempenhados pelos usuários, ou seja, que serviços do

sistema o usuário poderá interagir.

A importância da representação desses elementos dentro da VL4UCD decorre do fato

da linguagem não preocupar-se apenas com o projeto da interação, mas, também, com o

projeto de software como um todo. Isto permite que os projetistas do sistema optem por

usar apenas a notação VL4UCD para documentar os use cases ou, ainda, usar o modelo

de interação para gerar a documentação textual. Desta forma, a VL4UCD não está res-

trita apenas aos designers da interação, mas aberta às necessidades dos engenheiros de

software.

Como mencionado em seções anteriores, estas caraterísticas dos use cases devem ser

configuradas nos elementos Opening Interaction e Closing Interaction a partir da área de

propriedades da ferramenta UCDT.

4.4.2 Regras de negócio

As regras de negócio representam o conjunto de instruções típicas do fazer do usuário

e que devem ser implementadas dentro de um ou mais use cases do software. Restrições,

validações e condições apresentam-se como exemplos clássicos das regras de negócio

e por isso precisam estar presentes na especificação do software. Considerando que o

propósito da VL4UCD é descrever a interação usuário-sistema, mas sem perder o foco nas

experiências trazidas pelos use cases, deixar de representar as regras de negócio traria para

VL4UCD uma séria deficiência do ponto de vista do projeto de engenharia de software.

É importante frisar que representar regras de negócio é diferente de representar requi-

sitos. De forma geral, um requisito reflete uma função usada pelo usuário, normalmente

solicitada explicitamente via interface gráfica. Por exemplo, quando ALaDiM especifica


a função de domínio ela está se referindo a um requisito do sistema e não o detalha-

mento das regras de negócio para que a função possa ser executada. De certa forma,

isto caracteriza-se como uma limitação para representar os interesses dos engenheiros de

software.

Na VL4UCD as regras de negócio estão representadas na propriedade business rule

das transições de estado do tipo action. Desta forma, pode-se expressar de maneira semi-

formal o conjunto de regras de negócio para cada função do sistema solicitada pelo usuá-

rio, sobre a interface gráfica.

4.4.3 Associações de inclusão e extensão

Como vimos no capítulo 2 as associações de inclusão e extensão são utilizadas para

representar cenários, situações ou rotinas que são comuns a mais de um use case. Em-

bora essa estratégia seja importante para o projeto de modelagem dos componentes in-

ternos do software, por exemplo, posibilitando uma visão de reuso de funcionalidades e

consequentemente componentes do software, ela fragmenta a representação da interação

usuário-sistema.

Para resolver esse problema da fragmentação a VL4UCD traz o conceito de ações

especiais. Isso permite que, dependendo do caminho escolhido pelo usuário durante a

interação, outros use cases podem ser apresentados no modelo do use case principal.

Para tanto o designer deve fazer uso das transições Extension e Inclusion.

Além de possibilitar uma representação visual da inclusão desses novos cenários, a

VL4UCD permite informar a condição em que ela ocorre, apresentando-se como mais

um elemento que ajuda a representar os interesses dos engenheiros de software. Isto

porque em um cenário de inclusão de use cases, por exemplo, alguma condição deve ser

estabelecida para que a chamada de uma nova funcionalidade seja efetivada. Desta forma,

a VL4UCD estimula o designer a pensar em que condições use cases são acionados para

complementar ações de outros.


Assim, concluímos essa seção certos de que a VL4UCD possui contribuições signifi-

cativas em relação as linguagens apresentadas nesta tese, em especial AlaDIM, pelo fato

de não somente contemplar aspectos da interação, mas, também, aspectos de interesses

dos engenheiros de software representados nos use cases.

Figura 4.12: Ferramenta de suporte à VL4UCD.

4.5 Modelos VL4UCD

Nesta seção, são elencados os modelos escritos em VL4UCD para representar alguns

use case extraídos em um processo de reengenharia da ferramenta MasterTool XE. Essa

ferramenta oferece suporte ao desenvolvimento de aplicações para sistemas de automação

industrial que utilizam os controladores programáveis da série Nexto, desenvolvido pela

empresa Altus Sistemas de Automação S/A 3. A figura 4.13 representa um subconjunto

3Empresa de desenvolvimento de soluções (software e hardware) para indústria de automação de pro-cessos. Possui sua matriz sediada na Tecnolosinos, São Leopoldo-RS, junto à Universiade do Vale do Riodos Sinos (Unisinos). site: http://www.altus.com.br/


dos use cases do MasterTool que são descritos nesta seção usando a notação da VL4UCD.

Os modelos (VL4UCD) apresentados nesta seção, também, podem ser encontrados no

apêndice “B” em escala ampliada.

Figura 4.13: Subconjunto de uses cases do MasterTool.

Criar projeto MasterTool

Este use case permite criar o ambiente (estrutura) necessário para o desenvolvimento

de aplicações. Durante o processo de criação o usuário deve selecionar a unidade de pro-

cessamento (UP) desejada, os modelos de rack (NX 9001, NX902, NX903), a fonte de

alimentação (NX8000), a configuração de redundância, o perfil do projeto e a linguagem

para as unidades de organização de programas (Structured Text - ST, Gráfico Funcio-

nal Contínuo - CFC, Ladder, Lista de Instruções). A figura 4.14, representa a interação

usuário-sistema deste use case.

Criar POU

Uma POU (Program Organization Unit) é uma unidade de programação da unidade de

processamento. Além das POUs existentes, a partir da criação de um projeto MasterTool,

pode-se acrescentar quantas forem necessárias até o limite da memória determinada pelo


Figura 4.14: Modelo em VL4UCD para o use case criar projeto.

projeto. Assim, para a criação de uma nova POU, o usuário deve entrar com algumas

informações de configuração, como: nome da POU, tipo (programa, bloco funcional ou

função) e bloco funcional. O use case Criar POU é estendido por dois outros use cases:

listar catálogo de classes e listar catálogo de interfaces. A figura 4.15

representa a interação usuário-sistema para o use case.

Figura 4.15: Modelo em VL4UCD para o use case criar POU.


Login

O use case Login é responsável por enviar o projeto para a UP Nextor. Dependendo

do tamanho do arquivo a ser enviado à UP, a operação pode levar alguns segundos até a

conclusão da operação. Caso o projeto que está sendo transferido seja diferente daquele

já existente na UP o usuário deverá escolher entre as seguintes opções:

• Login com alteração online: enviar novo projeto sem que a aplicação atual seja

parada na UP, atualizando as alterações quando um novo ciclo é executado;

• Login com download: executa o login e envia o novo projeto com a UP parada;

• Login sem alteração: executa login sem enviar o arquivo.

Assim como no exemplo anterior o use case login faz uso do mecanismo de extensão,

neste caso estendendo o use case detalhar projetos. Este é encontrado em diversas

partes do MasterTool, sempre permitindo fazer uma comparação entre o código da apli-

cação existente na UP e o que está sendo implementado no editor de códigos. A figura

4.16 apresenta o modelo de interação para referido use case usando a VL4UCD.

A partir dos modelos aqui apresentados,é cabivel observar os seguintes aspectos:

(a) Integração entre use cases:

No que se refere à integração de use case, observa-se que o emprego das transições

do tipo special action propiciam a representação necessária para a comunicação en-

tre scenes de diferentes use cases. Isso fica evidenciado nos diagramas das figuras

4.15 e 4.16, quando os use cases Criar POU e Login demandam pela extensão de

Listar Catálogos de Interfaces/Classes e Detalhar Projetos, respecti-

vamente.

Embora o objetivo final do usuário esteja fragmentado dentro de dois ou mais use

cases, o modelo construído com a VL4UCD permite uma visão global da interação,

possibilitando, assim, que seja realizada uma avaliação da navegabilidade, ainda


Figura 4.16: Modelo em VL4UCD para o use case Login.

em fase de modelagem do sistema, fato que possibilita minimizar problemas como

aqueles relatados na seção 2.3.

(b) Verbosidade textual:

Outro aspecto positivo quanto ao uso da VL4UCD para descrever use case, está re-

lacionado à sensível diminuição de textos desnecessários para expressar a interação

usuário-sistema. Isso é possível por meio da utilização dos elementos basic inte-

raction, que permitem descrever a essência da interação, erradicando, dessa forma,

o excesso de texto desnecessário sem perder as características da natureza do pro-

blema.

A diminuição da verbosidade sobre os modelos são, igualmente, decorrentes do uso

das propriedades dos elementos da VL4UCD. A descrição das regras de negócio,

encapsuladas nas propriedades do elemento action, são um exemplo disso. As pro-

priedades dos elementos, além de deixarem o modelo mais legível e organizado,


orientam os projetistas à medida que eles constroem seus modelos.

(c) Integração entre transições de estado:

Enquanto em uma descrição textual de use case a integração entre as solicitações

do usuário e as repostas que o sistema deve dar ficam a critério de seus escritores,

na VL4UCD toda reação do sistema deve ter uma ação como origem. Isso esti-

mula analistas e designers a pensarem no tipo de resposta para cada solicitação do

usuário.

Essa característica é garantida por meio da propriedade source action existente nas

state transitions do tipo reaction. Independente de reações de sucesso ou falha, a

ferramenta solicitará a ação que originou aquela reação. Dessa forma, é possível,

a partir da área de propriedades da UCDT, identificar, por exemplo, que a reac-

tion success Nova versão da aplicação, que tem como alvo a scene Aplicação

Existente, é originada pela action Login, (ver figura 4.16).

(d) Integração com modelos de engenharia:

A VL4UCD permite, ainda, extrair informações que podem auxiliar na construção

de alguns outros modelos como o de classes e de dados. Por exemplo, do diagrama

da figura 4.15, podemos extrair a entidade POU e seus atributos como nome da

POU, estilo de programa a ser criado, além das características destes atributos como

tipo e tamanho. Como toda modelagem é suportada pela UCDT, não é necessário

usar outro tipo de artefato para registrar tais informações.

(e) Caminhos de exceção:

Para cada use case, deve-se pensar no que pode dar errado (ações de insucesso do

usuário) durante a interação. Essas ações estão relacionadas com violação de regras

de negócio, como entradas inválidas, comparação de valores, impossibilidade de

exclusão de um registro, entre outros.

Esse conceito pode ser encontrado em ALaDIM e templates para descrição de use

cases do RUP (IBM Rational Unified Process R©), e tem como objetivo incentivar o


projeto de caminhos que levam o usuário a recuperar-se de situações inconsistentes

a exemplo de uma falha de comunicação entre a aplicação MasterTool e a UP (ver

figura 4.16).


Como pôde ser constatado nessa capítulo, VL4UCD possui uma notação com alto

nível de abstração e formato legível, que aliada a UCDT possibilita a construção de mo-

delos de interação usuário-sistema sem termos extras, minimizando, assim, a verbosidade

tão comum na descrição de use cases. A linguagem permite, adicionalmente, a obtenção

da visão global da interação por meio dos elementos de transição do tipo special actions.

Isso permite que problemas de navegabilidade, como aqueles apresentados na seção 2.3,

possam ser verificados ainda nas fases iniciais do processo de desenvolvimento. Acredita-

se que esse formato de representação da interação usuário-sistema, seja suficientemente

legível para todos os interessados, profissionais de ES e IHC, durante o ciclo de desen-

volvimento. No próximo capítulo é apresentado um estudo experimental realizado para

avaliar a VL4UCD.

Capítulo 5

Experimentos

Com a finalidade de verificar se a notação proposta neste trabalho apresenta compe-

tências necessárias para auxiliar profissionais de ES e IHC na tarefa de modelagem da

interação usuário-sistema, este capítulo apresenta o estudo experimental realizado com

as notações VL4UCD e CTT. Para isso o experimental deve apresentar respostas para às

questões de pesquisa mencionadas no capitulo 1. A notação CTT foi escolhida por ser

uma das notações baseadas no conceito de modelagem de tarefas e possuir significativo

conteúdo para leitura e capacitação tanto em forma de tutoriais como artigos.

Para apresentar o estudo, o capítulo está dividido em três seções: planejamento expe-

rimental, análise dos resultados e validação do experimento. Na seção de planejamento

são apresentados o método utilizado para avaliar as notações, contexto de avaliação, ins-

trumentos utilizados, descrição das variáveis, formulação das hipóteses e procedimentos.

Na seção de análise são apresentados os resultados obtidos e as respectivas interpreta-

ções. Por fim, são apresentadas as formas de validade esperadas para um experimento de

engenharia de software.

5.1 Planejamento Experimental

O objetivo do nosso experimento é analisar a descrição da interação usuário-sistema

com o propósito de realizar uma avaliação comparativa entre duas notações (CTT e VL4UCD)

CAPÍTULO 5. EXPERIMENTOS 74

com respeito a sua eficiência, facilidade de uso, utilidade e intenção de uso, a partir do

ponto de vista de pesquisador no contexto de estudantes de graduação e profissionais em

desenvolvimento de software.

Para isto, o experimento foi conduzido utilizando-se o Method Evaluation Model

(MEM) [Moody 2003]. O MEM é um modelo teórico que combina aspectos de Rescher’s

pragmatic method [Rescher 1979] e o Davis’s Technology Acceptance Mode (TAM)

[Davis et al. 1989] para avaliar métodos de design de sistemas de informação. A Fi-

gura 5.1, apresenta as construções (constructs) primárias do MEM e suas relações. De

forma resumida, as constructs do modelo estão assim definidas:

• actual efficiency - esforço necessário/exigido para aplicar o método;

• actual effectiveness - grau com que o método alcança seus objetivos;

• perceived ease of use - grau com que as pessoas acreditam que o método é fácil de

usar;

• perceived usefulness - grau com que as pessoas acreditam que o método será eficaz

na concretização dos seus objetivos;

• intention to use - nível de intenção de uso do método;

• actual usage - nível em que o método é utilizado na prática.

Além da definição conceitual do MEM, Moody apresenta sugestões para avaliar cada

construct. Por exemplo, para avaliar perceived ease of use, perceived usefulness e inten-

tion to use é sugerido um questionário de itens adaptado do modelo TAM. Já para medir

actual efficiency e actual effectiveness, Moody orienta levar em consideração os aspectos

de cada método de design a ser avaliado. Assim, ele apresenta apenas orientações ge-

rais sobre medidas de tempo, custo e esforço cognitivo (actual efficiency), quantidade e

qualidade dos resultados (actual effectiveness).

Por se caracterizar como um experimento controlado (in-vitro), a construção actual

usage não faz parte do escopo da avaliação. Este será considerado em trabalhos futuros


Figura 5.1: Method evaluation model, extraído de Moody (2003).

sobre o contexto de um projeto real (experimento de campo).

Com respeito a actual efficacy dos métodos, o experimento endereça a seguinte ques-

tão de pesquisa:

• QP1: Será que VL4UCD permite modelar a interação usuário-sistema com menor

esforço de tempo que CTT?

Com respeito a perceived efficacy dos métodos, o experimento endereça as seguintes

questões de pesquisa:

• QP2: Será VL4UCD mais fácil de usar que CTT para modelar a interação usuário-

sistema?

• QP3: Será VL4UCD considerada mais útil que CTT para modelar a interação

usuário-sistema?

Com respeito a adoption in practice, o experimento endereça a seguinte questão de

pesquisa:

• QP4: Desenvolvedores de software teriam maior intenção de usar VL4UCD do que

CTT?


5.1.1 Contexto da Avaliação

O experimento foi realizado com a participação de trinta e oito indivíduos, divididos

em três grupos. O primeiro grupo foi composto de quinze estudantes de graduação do

curso de Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação Ci-

ência e Tecnologia do Rio Grande do Norte (IFRN). O segundo grupo foi formado por

quinze estudantes do curso de engenharia de computação da Universidade Federal do

Rio Grande do Norte (UFRN). O terceiro grupo foi composto por oito profissionais com

média superior a seis anos de experiência em desenvolvimento de software e atualmente

integrantes da equipe de desenvolvimento do IFRN.

Com o propósito de identificar o background e a experiência dos participantes em aná-

lise e design de software foi aplicado um questionário demográfico (ver Apêndice “C”).

Isto permitiu mapear o perfil de cada participante no que diz respeito a sua formação,

experiência profissional e grau de conhecimento sobre diferentes métodos e técnicas de

especificação da interação usuário-sistema, tais como: descrição de use case, diagramas

de atividade, modelagem de tarefas, entre outros. Em relação aos estudantes, 80% res-

pondeu que tinha pouco conhecimento sobre as técnicas de IHC e 57% respondeu que

tinha pouco conhecimento sobre diagramas UML e descrição de use cases. Em relação

ao grupo de profissionais, 38% deles respondeu que tinha um bom conhecimento sobre

as técnicas de IHC e 100% deles consideram ter um bom conhecimento dos diagramas de

UML e descrição do use cases.

Com o resultado do questionário demográfico foi possível observar que o nível de co-

nhecimento dos participantes do grupo 1 e 2 (estudantes) sobre métodos e técnicas ES e

IHC é relativamente baixo, o que minimiza a influência de conhecimentos prévios sobre

os resultados do experimento. Apenas os participantes do grupo 3 (profissionais de de-

senvolvimento de software) consideram ter bom conhecimento sobre métodos e técnicas

de ES.


5.1.2 Instrumentação

Os instrumentos usados neste experimento incluem o questionário demográfico, já

mencionado na subseção anterior; o objeto experimental (tarefa de modelagem); mate-

rial de treinamento (CTT e VL4UCD) e um questionário pós-tarefa. A participação

dos indivíduos foi anônima (códigos foram usados em vez de nomes) evitando que os

mesmos fossem expostos ou que se sentissem constrangidos por possíveis resultados ne-

gativos durante as atividades do experimento.

O questionário demográfico foi composto de quatorze perguntas e teve como objetivo

avaliar o nível de conhecimento dos participantes sobre suas experiências com métodos e

técnicas usados pelos profissionais de ES e IHC para a modelagem da interação usuário-

sistema.

Como material de treinamento, foi utilizado um conjunto de slides com instruções

sobre CTT e VL4UCD. As instruções sobre CTT são baseadas em conceitos e exem-

plos extraídos dos diversos artigos encontrados no site do grupo de interação humano-

computador do Instituto de Ciência e Tecnologia da Informação, Itália (ver site do grupo1).

Já os slides sobre VL4UCD são de autoria dos autores deste trabalho.

O objeto experimental foi constituído de dois problemas descritos em linguagem na-

tural. O primeiro deles diz respeito a um cenário de reserva de quarto de hotel. O segundo

trata de um cenário em que o usuário necessita realizar o saque de dinheiro em um termi-

nal eletrônico (ver apêndice “D”).

O questionário pós-tarefa é um instrumento composto de dezesseis itens, retirados e

adaptados do estudo realizado por Moody (2003). Cada item do questionário foi medido

utilizando uma escala de Likert de 5 pontos (1- Discordo totalmente , 2-Discordo, 3-

Neutro, 4-Concordo, 5-Concordo Plenamente) de concordância.

Os itens do questionário têm como objetivo avaliar três constructs do MEM: perceived

ease of use (PEOU), que define o grau de esforço exigido para uma pessoa utilizar o

1http://giove.isti.cnr.it/tools/CTT/home


método; perceived usefulness (PU), que mede o grau em que uma pessoa acredita que

um determinado método será eficaz na concretização dos seus objetivos pretendidos; e

intention to use (ITU), que avalia o grau de intenção de utilizar o método em questão.

Os itens do questionário foram os seguintes:

• Q1: O processo de aplicação do método é complexo e difícil de seguir (PEOU).

• Q2: Este método reduz o esforço necessário para documentar/descrever os modelos

de interação usuário-sistema (PU).

• Q3: O método é fácil de aprender (PEOU).

• Q4: Modelos de interação representados usando esse método são mais difíceis para

compreender (PU).

• Q5:As regras do método são claras e fáceis de entender (PEOU).

• Q6: No geral, o método é útil (PU).

• Q7:No geral, o método é difícil de usar (PEOU).

• Q8: É difícil de aplicar o método para descrever a interação usuário-sistema (PEOU).

• Q9: Este método torna mais fácil para os usuários obterem uma visão global da

interação (PU).

• Q10: O treinamento dado foi o suficiente para eu aplicar este método na prática

(PEOU).

• Q11: O uso deste método torna mais difícil descrever modelos de interação usuário-

sistema (PU).

• Q12: Eu, definitivamente, não usaria esse método na prática para documentar/descrever

a interação usuário-sistema (ITU).

• Q13: Eu pretendo usar este método se tiver que trabalhar com modelagem da inte-

ração usuário-sistema (ITU).

• Q14: No geral, este método é uma melhoria do padrão de descrição da interação

usando casos de uso (PU).

• Q15: No geral, este método não fornece uma solução eficaz para o problema de


representar a interação usuário-sistema (PU).

• Q16: Usando este método é mais fácil comunicar modelos de interação entre Eng.

Software e profissionais de IHC (PU).

Com o objetivo de garantir o equilíbrio do questionário, metade dos itens são com-

postos de frases afirmativas e a outra metade de frases negativas. Este tipo de estratégia

é utilizada para que os participantes possam estar mais atentos ao que é solicitado a cada

item [Hu et al. 1999]. Além disso, para reduzir qualquer risco de repostas monótonas por

parte dos participantes, as questões foram dispostas de forma aleatória, sendo seis itens

destinados a medir a perceive ease of use, oito itens a perceived usefulnes e dois itens a

intention use

5.1.3 Variáveis

Variáveis independentes (factors): Em nosso estudo, o método de descrição da in-

teração usuário-sistema foi identificado como uma variável que poderia afetar as variá-

veis de resposta. Dois tratamentos foram considerados: (1) CTT - ConcurTaskTree e

VL4UCD - Visual Language for Use Case Description.

Variáveis dependentes (outcomes): actual efficiency (AE), actual effectiveness (AES),

perceived ease of use (PEOU), perceived usefulness (PU) e intention to use (ITU) foram

identificadas como outcomes do experimento.

• Actual efficiency foi medida com base no tempo gasto para completar a tarefa de

modelagem.

• Actual effectiveness foi avaliado a partir de observações qualitativas evidenciadas

no resultado de modelagem das tarefas do objeto experimental.

• Perceive ease of use foi medida usando seis itens (Q1, Q3, Q5, Q7, Q8 e Q10) do

questionário pós-tarefa de modelagem.


• Perceived usefulnes foi medido usando oito itens (Q2, Q4, Q6, Q9, Q11, Q14, Q15

e Q16) do questionário pós-tarefa de modelagem.

• Intention use foi medido com dois itens (Q12 e Q13) do questionário pós-tarefa de

modelagem.

5.1.4 Hipótese

A relação das hipóteses com as questões de pesquisa, formulada no início da seção

5.1 (Planejamento Experimental), são as seguintes:

• Hipótese A (relativo a QP1)

– Null Hypothesis (H0A): VL4UCD e CTT são igualmente vistas com actual

efficiency.

– Alternative Hypothesis (H1A): VL4UCD é percebido como mais actual effi-

ciency que CTT.

• Hipótese B (relativo a QP2)

– Null Hypothesis (H0B): VL4UCD e CTT são igualmente vistas como easy to

use.

– Alternative Hypothesis (H1B): VL4UCD é vista como easier to use que CTT.

• Hipótese C (relativo a RQ3)

– Null Hypothesis (H0C): VL4UCD e CTT são igualmente visto como useful.

– Alternative Hypothesis (H1C): VL4UCD é vista como mais useful que CTT.

• Hipótese D (relativo a QP4)

– Null Hypothesis (H0D): VL4UCD and CTT são igualmente vistas com inten-

tion to use.

– Alternative Hypothesis (H1D): VL4UCD é vista com mais intention to use

que CTT.


5.1.5 Procedimentos Experimentais

O experimento foi aplicado em cada grupo de participante, descrito na subseção

5.1.1(Contexto da Avaliação), e teve uma duração total de seis horas, ocorrendo três en-

contros de duas horas para cada grupo (ver figura 5.2). O primeiro e segundo encontro

foram destinados ao treinamento dos participantes. Este treinamento teve uma duração

de quatro horas, sendo duas horas destinadas à notação CTT e outras duas destinadas à

capacitação em VL4UCD. Para cada notação foi possível apresentar suas características

conceituais e realizar os exercícios planejados no material de treinamento.

No terceiro e último dia foram aplicados o objeto experimental e o questionário pós-

tarefa. Para essas atividades os participantes tiveram duas horas. No primeiro momento

foi passado aos participantes o objeto experimental com os dois problemas a serem mo-

delados com as notações CTT e VL4UCD. Após conclusão da atividade de modelagem

(objeto experimental), foi solicitado aos participantes que respondessem ao questionário

pós-tarefa para tomar suas impressões quanto às suas percepções sobre cada notação.

A distribuição das tarefas foram realizadas de maneira que, metade dos participantes

começassem a modelagem pela linguagem CTT e a outra metade usando a VL4UCD.

Isto tem como objetivo proporcionar a ambas notações um equilíbrio sobre as tenções

e relativo cansaço que por ventura a atividade de modelagem pudessem influenciar no

desempenho do participante e consequentemente nos resultados do experimento.

Após conclusão do experimento com os participantes, passou-se à fase de análise e

interpretação dos dados, conforme apresenta-se na seção seguinte.

5.2 Análise e Interpretação dos Resultados

Nesta seção são apresentados os resultados obtidos por meio da avalição empírica

entre CTT e VL4UCD. Um resumo dos resultados são apresentados de forma descritiva e

analítica por meio de tabelas. Um t-test uni-caudal à direita foi aplicado com objetivo de


G1 –Estudantes IFRN

1º Encontro (2h) 2º Encontro (2h)

Treinamento VL4UCD

+ Questionário Demográfico

G2 –Estudantes UFRN

G3 -Profissionais

Treinamento CTT +

Questionário Demográfico

Treinamento VL4UCD

+ Questionário Demográfico

Grupos

Objeto Experimental +

Questionário Pós-tarefa

Treinamento CTT

Treinamento VL4UCD

Treinamento CTT

3º Encontro (2h)





Figura 5.2: Esquema de procedimento experimental

analisar as hipóteses mencionadas na seção 5.1. As tabelas com os resultados analíticos

possuem as seguintes representações: média, variância, graus de liberdade (gl), nível

descritivo (P), hipótese da diferença de médias e os valores: estatístico calculado (t stat)

e crítico ( t critical).

Um resultado tem significância estatística se for improvável que tenha ocorrido por

acaso. Esta significância está relacionada ao nível de confiança ao se rejeitar a hipótese

nula. Historicamente a comunidade de estatística tem aceito como estatisticamente sig-

nificativos os níveis de P≤0.05, ou seja, até cinco por cento (5%) [Faber 2010]. Isso

significa dizer que se o valor estatístico calculado (t stat) exceder o valor crítico (t criti-

cal), então o resultado é significativo ao nível de 5%, o que nos leva a descartar a hipótese

nula.

Na próxima subseção, relatamos os resultados alcançados.

a. Actual Efficiency

Este construct foi o único avaliado com base na medida de tempo. Um indivíduo

dentro do experimento foi responsável por realizar medição do tempo de modelagem.

Durante análise dos dados foram descartadas quatro tomadas de tempo, sendo duas refe-


rentes à notação CTT e duas referentes à VL4UCD. Isso porque esses tempos descartados

apresentaram uma significativa discrepância em relação aos demais. O que nos leva a crer

que houve um erro durante os registros de tempo. No entanto, é importante ressaltar que

apenas essas quatro anotações de tempo mostraram-se com problema.

As figuras 5.3, 5.4 e 5.5 apresentam o gráfico do tempo médio gasto pelos participan-

tes para realizar a modelagem da interação usuário-sistema para as atividades constantes

do objeto experimental. Nela podemos observar que a notação VL4UCD apresentou uma

média de tempo menor para conclusão das atividades propostas no objeto experimental

para ambos os grupos. Isso nos traz evidências de que os conceitos da VL4UCD foram

mais acessíveis aos participantes.

24,29

15,4 13

11,4

0

5

10

15

20

25

30

A+vidade 1

A+vidade 2

Tempo

(em m

inutos)

Tempo médio de modelagem (Grupo 1)

CTT

VL4UCD

Figura 5.3: Duração média de modelagem por atividade (G1)

11,25

9,82 9,92 8,91

0

2

4

6

8

10

12

A,vidade 1

A,vidade 2

Tempo

(em m

inutos)


CTT

VL4UCD



10 10,71

8,63 9,29

0

2

4

6

8

10

12

A-vidade 1

A-vidade 2

Tempo

(em

minutos)


CTT

VL4UCD


Como podemos ver na análise estatística apresentada na tabela 5.1, existe uma di-

ferença (P=0,035) significativa entre CTT e VL4UCD, com relação ao esforço de tempo

necessário para realizar a modelagem da interação usuário-sistema. Portanto, isto nos leva

a rejeitar H0A com mais de 95% de confiança e aceitar a hipótese alternativa H1A. Desta

forma, podemos dizer que VL4UCD é percebida como mais eficiente que CTT, quando

se leva em consideração o tempo modelagem.

Tabela 5.1: t-Test: amostras presumindo variâncias diferentes para o construct (AE)VL4UCD CTT

Média 15,77 21,50Variância 88,05 201,16Observações 34 34Hipótese@da@diferença@de@média 0gl 52Stat@t F1,847P(T<=t)@uniFcaudal 0,035t@crítico@uniFcaudal 1,676

b. Actual Effectiveness

Este foi o único construct avaliado de forma qualitativa. O objetivo neste caso não

foi contabilizar os erros cometidos com nenhuma das notações utilizadas. Isso porque, o

tempo destinado para o treinamento não permitiria que os participantes se apropriassem


dos conceitos de cada notação ao ponto de alcançarem a perfeição na modelagem das

atividades. Quando avaliados, todos os modelos produzidos possuem alguma divergência

em relação aos modelos de referência.

No que diz respeito a notação CTT ficou evidenciado os erros decorrentes ao tipo de

tarefa a ser utilizada para determinadas situações. Os participantes confundiram o uso

da tarefa abstrata com a tarefa de interação. Ficou evidente que alguns dos participantes

tiveram dificuldade em representar composições de tarefas. Outra dificuldade observada

diz respeito a representação da interação em forma de árvore. Um número considerável

de participantes apresentou dificuldade neste tipo de representação.

Com relação a notação VL4UCD podemos destacar a dificuldade em usar alguns dos

operadores. O operador choose foi o mais empregado de forma equivocada. No geral, os

modelos apresentados possuíam os elementos esperados para representar os cenários des-

critos nas atividades. Ao contrário do CTT, os modelos descritos com a VL4UCD apre-

sentaram uma maior consistência quanto ao uso dos elementos e conceitos da notação.

Como exemplo, podemos citar um consenso no uso dos elementos de início (OpeningIn-

teraction) e fim (ClosingInteraction) da interação. Além disso, o emprego das transições

de ação (Action) e reação (Reaction) entre as cenas (Scene) e núcleo operacional do sis-

tema (SystemProcess) foram os elementos da notação mais explorados corretamente pelos

participantes.

c. Perceived ease of use

Para verificar este construct, inicialmente calculamos as pontuações atribuídas por

cada participante do experimento ao longo das seis questões (Q1, Q3, Q5, Q7, Q8 e

Q10) relevantes para determinar perceived ease of use. Na Tabela 5.2, apresentamos uma

estatística descritiva calculada para ambas as notações (CTT e VL4UCD).

Note que, em uma escala Likert que vai de 1 a 5 pontos, a notação VL4UCD obteve

médias superiores as da notação CTT em todos os grupos de participantes. Além disso,


Tabela 5.2: Estatística descritiva para o construct (PEOU)

VL4UCD CTT VL4UCD CTT VL4UCD CTTN 15 15 15 15 8 8Média 3,81 2,91 3,43 2,89 4,17 3,02Desvio6padrão 0,15 0,52 0,3 0 0,26 0,62Mínimo 3,67 2,6 2,87 2,40 3,75 2,38Máximo 4,07 3,2 3,67 3,07 4,50 4,13

Estátisticas Grupo&1 Grupo&2 Grupo&3

os desvios-padrão comprovam que as médias obtidas para o uso das duas notações são

representativas.

Como podemos ver na tabela 5.3, existe uma diferença estatística (P=0,000; P=0,015

e P=0,001) altamente significativa entre CTT e VL4UCD, com relação ao construct per-

ceived ease of use para realizar a modelagem da interação usuário-sistema. Portanto, isso

nos leva a rejeitar H0B com mais de 95% de confiança e aceitar a hipótese alternativa

H1B. Desta maneira, podemos dizer que VL4UCD é mais facil de usar que CTT.

Tabela 5.3: t-Test: amostras presumindo variâncias diferentes para o construct (PEOU).

VL4UCD CTT VL4UCD CTT VL4UCD CTTMédia 3,81 2,91 3,43 2,89 4,17 3,02Variância 0,85 0,58 0,77 1,07 0,31 1,34Observações 90 90 90 90 48 48Hipótese@da@diferença@de@média 0 0 0gl 172 173 68Stat@t 7,145 3,817 6,176P(T<=t)@uniNcaudal 0,000 0,015 0,001t@crítico@uniNcaudal 1,654 1,654 1,668

Grupo&3Grupo&2Grupo&1

As respostas aos itens desse construct apontam que ambos os grupos tiveram uma

percepção de facilidade de usar a notação VL4UCD. Analisando os itens Q3, Q7 e Q10, é

possível fornecer uma visão mais detalhada desse resultado. O gráfico da figura 5.6 mostra

que apenas três participantes discordaram que a notação VL4UCD é fácil de aprender.

Este resultado reflete-se também em Q7, onde apenas quatro participantes relataram que

o método era difícil de utilizar (ver figura 5.7).

Outra importante reflexão é sobre o item Q10. Por meio do gráfico da figura 5.8,

podemos notar que, globalmente, o treinamento para uso da VL4UCD foi considerado


0

2

0

8

5

0 1

4

9

1 0 0

1

4 3

Discordo totalmente Discordo Neutro Concordo Concordo plenamente

Q3 -‐ O método é fácil de aprender.

G1 G2 G3

Figura 5.6: Respostas ao item 3 do questionário pós-tarefa.

3

8

2 2

0 1

10

2 2

0 1

6

1 0 0


Q7 -‐ No geral, o método é di2cil de usar.

G1 G2 G3


suficiente pela maioria dos participantes. Apenas cinco deles (estudantes) pensam o con-

trário. É importante ressaltar que um treinamento com o objetivo de realizar uma ativi-

dade experimental não reflete as necessidades/exigências das rotinas diárias de equipes de

desenvolvimento de software.

d. Perceived usefulness

Para verificar este construct, tomou-se a pontuação atribuída a cada questão (Q2, Q4,

Q6, Q9, Q11, Q14, Q14, Q15 e Q16). Uma estatística descritiva para ambos as nota-

ções foi então calculada, conforme apresenta-se na tabela 5.4. Outra vez observa-se que

a VL4UCD apresenta uma pontuação média superior a obtida pelo CTT em ambos os

grupos. Mesmo tomando a menor média (3.64) obtida pela VL4UCD, esta apresenta-se


0 0 2

13

0 1

4 6

4

0 0 0 0

4 4


Q10 -‐ O treinamento dado foi o suficiente para eu aplicar este método na prá9ca .

G1 G2 G3


acima da média da escala utilizada.

Tabela 5.4: Estatística descritiva para o construct (PU)

VL4UCD CTT VL4UCD CTT VL4UCD CTTN 15 15 15 15 8 8Média 3,95 3,18 3,64 3,03 4,13 2,91Desvio6padrão 0,34 0,53 0,23 0,17 0,25 0,37Mínimo 3,33 2,27 3,2 2,67 3,63 2,25Máximo 4,33 3,87 4 3,27 4,38 3,38


Após análise dos dados, percebe-se que existe uma diferença estatística (P=0,000;

P=0,002 e P=0,000) altamente significativa entre CTT e VL4UCD, com relação percei-

ved usefulness, para realizar a modelagem da interação usuário-sistema (ver tabela 5.5).

Portanto, isso nos leva a rejeitar H0C com mais de 95% de confiança e aceitar a hipótese

alternativa H1C. Isto nos permite dizer que a VL4UCD é percebida com mais utilidade

que CTT.

Neste construct, é possível destacar a avaliação dos participantes sobre as questões

relacionadas com a comunicação entre profissionais ES e IHC e a visão global da inte-

ração usuário-sistema, as quais são base de motivação para este trabalho. Em relação a

comunicação, apenas quatro participantes foram neutros ao responder sobre a facilidade

de comunicar a interação usuário-sistema usando VL4UCD (ver figura 5.9). Já na fi-

gura 5.10, é possível notar que apenas dois participantes consideram que a VL4UCD não


Tabela 5.5: t-Test: amostras presumindo variâncias diferentes para o construct (PU)


Grupo&1 Grupo&2 Grupo&3

permite obter uma visão global da interação.

0 0 0

15

0 0 0

4

9

1 0 0 0

5 3


Q16 -‐ Usando este método é mais fácil comunicar modelos de interação entre engenheiros de so;ware e profissionais de IHC.

G1 G2 G3


0 0

3

7 5

0 1

2

12

0 0 1

0

3 4


Q9 -‐ Este método torna mais fácil para os usuários obterem uma visão global da interação.

G1 G2 G3


De forma geral, os participantes consideraram a VL4UCD um método útil e indica-

ram que a notação é uma melhoria para o padrão de descrição da interação usado pela

comunidade de ES. Este resultado pode ser observado nos nas figuras 5.11 e 5.12, res-


pectivamente. Uma possível interpretação para estes resultados é que a VL4UCD permite

uma descrição da interação de maneira mais formal, evitando textos desnecessários. Os

elementos que compõem VL4UCD são empregados como peças vitais para tal resultado.

0 0 0

10

5

0 0 0

15

0 0 0 0

7

1


Q6 -‐ No geral, o método é ú2l.

G2 G2 G3


0 0 0

13

2 0

1

6 7

0 0 0 0

5 3


Q14 -‐ No geral, este método é uma melhoria do padrão de descrição da interação usando use cases.

G1 G2 G3


e. Intention to use

Para este construct foram utilizados os itens Q12 e Q13 do questionário pós-tarefa.

A Tabela 5.6 apresenta um resumo da estatística descritiva desta questões. Mais uma

vez, as médias obtidas pela notação VL4UCD são superiores àquelas obtidas pelo CTT.

O desvio padrão calculado para cada uma das notações avaliadas indica que as médias

obtidas possuem significativa representatividade.


Tabela 5.6: Estatística descritiva para o construct (ITU)

VL4UCD CTT VL4UCD CTT VL4UCD CTTN 15 15 15 15 8 8Média 3,73 3,10 3,30 2,73 3,63 1,88Desvio5padrão 0,19 0,24 0,24 0,28 0,18 0,35Mínimo 3,60 2,93 3,13 2,53 3,50 1,63Máximo 3,87 3,27 3,47 2,93 3,75 2,13


Como podemos observar na Tabela 5.7, os participantes expressaram a intenção de

usar a VL4UCD na prática para descrever a interação usuário-sistema. A diferença das

médias apresentou um nível de significância estatística médio, como observa-se P=0,025.

No entanto, isso ainda nos permite rejeitar a hipótese nula H0D e aceitar a hipótese alter-

nativa H1D, ou seja, VL4UCD é vista com mais intenção de uso que o CTT.

Tabela 5.7: t-Test: amostras presumindo variâncias diferentes para o construct (ITU)


Grupo&1 Grupo&2 Grupo&3

A partir do gráfico da figura 5.13, podemos observar que nenhum dos participantes

foram contrários ao uso da VL4UCD quando perguntados sobre a possibilidade de usa-lá

na prática. Embora os profissionais tenham um background capaz de influenciar contra a

adoção de novas métodos, este sentimento não foi verificado quando comparado com as

repostas dos estudantes de graduação.

5.3 Validade do experimento

Uma das premissas com relação aos resultados apresentados é o quanto são válidos.

Os resultados precisam ser válidos para a amostra populacional que participou do expe-


0

13

2 0 0 0

10

5

0 0 0

6

2 0 0


Q12 -‐ Eu, defini.vamente, não usaria esse método na prá.ca para documentar/descrever a interação usuário-‐sistema.

G1 G2 G3


rimento para que possam ser generalizados. Nesta seção, discutiremos a validade dos

resultados do experimento, discutindo algumas ameaças e a confiabilidade dos indicado-

res encontrados. A seguir são discutidos os quatro tipos de validade previstas por Wohlin

et al. (2012) no livro Experimentation in Software Engineering.

5.3.1 Validade interna

Os problemas relacionados a este tipo de validade estão ligados aos participantes.

Fatores como cansaço, desânimo, sentimento de obrigatoriedade durante a atividade são

exemplos de fatores que influenciam na validade interna do experimento.

Para evitar tais riscos, os participantes do experimento foram convidados a partici-

par do estudo de forma voluntária, não recebendo nenhum tipo de pro labore ou outras

vantagens. Uma ameaça para validade do experimento poderia ser a experiência dos

participantes. No entanto, conforme apresentamos na subseção 5.1.1 (Contexto da ava-

liação) os participantes possuem homogeneidade no que diz respeito aos conhecimentos

sobre métodos e técnicas usados pelos grupos de ES e IHC. Uma possível heterogenei-

dade no perfil dos participantes poderia causar maior variabilidade nas medidas. Apenas

uma pequena parte dos participantes (Grupo 3) apresentou-se com conhecimentos sobre

diagramas da UML.


Durante a execução do objeto experimental metade dos participantes foram orientados

a começar usando CTT e a outra metade a VL4UCD. Está distribuição foi feita de forma

aleatória. Após concluírem a primeira rodada, o emprego da notação entre os grupos foi

invertido. Isto tem como objetivo proporcionar a ambas notações um equilíbrio sobre as

tenções e relativo ao cansaço que por ventura a atividade de modelagem pudesse influen-

ciar no desempenho do participante e consequentemente nos resultados do experimento.

5.3.2 Validade externa

A validade externa define as condições limitantes para generalizar os resultados obti-

dos no experimento para a população representada pelos participantes (população amos-

tral). Para se alcançar uma validade externa deve-se levar em consideração o perfil dos

participantes, o lugar e o tempo de aplicação do experimento. Problemas podem ocorrer

quando os participantes não representam a população sob interesse, ou quando os instru-

mentos são inadequados à prática cotidiana, ou quando o experimento é executado em dia

e tempo que venham afetar os resultados.

Como já mencionado anteriormente os participantes do experimento podem ser con-

siderados representativos para a população de estudantes da área de desenvolvimento de

software. Claramente, usar estudantes de graduação para avaliar métodos (como no ex-

perimento laboratorial) não é o mesmo que usar profissionais com experiência na área.

No entanto, Runeson (2003) argumenta que, ocasionalmente, os resultados obtidos com

essa categoria de participantes podem ser generalizados para os profissionais da indústria.

Isto é o que temos observado aqui, mesmo com um quantitativo pequeno de profissionais

participantes. Em todo caso, estamos conscientes de que mais experimentos devem ser

construídos e com maior número de profissionais participantes.

Por ser um experimento controlado, o quesito temporalidade não foi um fator limite

para os resultados alcançados, pois todos os encontros foram planejados e acordados entre

participantes e condutor do processo experimental. Por outro lado, deve-se destacar que


um ambiente real de desenvolvimento poderia influenciar nos resultados, já que coloca-

ria o experimento dentro da rotina diária das equipes envolvidas no desenvolvimento de

software.

5.3.3 Validade de construção

A validade de construção de um experimento diz respeito aos artefatos usados e os

fatores humanos envolvidos no projeto. Ameaças decorrentes de comportamentos ina-

dequados tanto por parte dos participantes quanto dos pesquisadores podem fragilizar o

trabalho. Problemas como sub-representação da teoria que envolve o experimento, parti-

cipantes envolvidos em mais de um estudo e experimentos projetados para dar resultados

já esperados; tudo isso, são exemplos de fatores que influenciam a validade da construção.

Quanto à validade dos problemas apresentados no objeto experimental, podemos di-

zer que estes são artefatos já trabalhados em sala de aula pelos autores deste trabalho,

além de poderem ser encontrados em livros da área de desenvolvimento de software. Isto

nos leva a crer que os problemas apresentados possuem, no mínimo, considerável signifi-

cância para o processo ensino-aprendizagem. Além disso, para evitar um desequilíbrio de

conhecimento sobre as notações avaliadas, tempos iguais de treinamento sobre as mesmas

foram praticados com os participantes.

Devido à inexistência de pessoas experientes em lidar com VL4UCD, apenas o autor

deste estudo esteve envolvido na condução das atividades do experimento. Estamos cons-

cientes da possibilidade de sobrevalorizar de um ou outro método avaliado. É por isso

que, para os próximos estudos, outros profissionais previamente treinados em VL4UCD

devem ser convidados para conduzir o experimento ou acompanha-lo como árbitro do

processo. Entretanto, a fim de evitar erros na interpretação e análise dos dados coletados,

um especialista em estatísticas foi convidado a apoiar o processo de análise de dados.


5.3.4 Validade de conclusão

Este tipo de validade está relacionado com as ferramentas que permitem chegar em

uma conclusão correta a respeito do que é pesquisado. Possíveis ameaças podem ser

atribuídas ao baixo potencial estatístico utilizado na análise dos dados, podendo levar a

conclusões errôneas. Para minimizar este problema um profissional em estatística esteve

presente durante a execução do estudo para garantir a correta captura de dados e imple-

mentação dos tratamentos.

Para garantir a validade da conclusão foi utilizado o t-test como ferramenta para ana-

lisar as hipótese apresentadas. O t-test é uma ferramenta para realizar testes de hipótese

onde se deseja rejeitar ou não uma hipótese nula. Todos os testes realizados apontam

para um valor de P≤0,05 o que nos permite generalizar os resultados alcançados para

respectiva população.

Uma análise de confiabilidade foi realizada sobre os itens do questionário pós-tarefa.

Esta análise foi construída usando uma técnica conhecida como Alpha de Chrobach [Cronbach

1989]. Altos níveis de confiabilidade foram encontrados sobre todos os constructs avali-

ados pelo questionário. Valores igual ou superior a 70% indicam que os itens do questio-

nário são adequadamente confiáveis. A tabela 5.8 representa os valores encontrados para

o indicador Alpha de Chronbach durante o experimento.

Tabela 5.8: Relação de confiabilidade dos itens

Perceived(Ease(of(Use 0,88Perceived(Usefulness 0,86Intension(to(Use 0,81

Construct Cronbach's-α



Neste capítulo foi apresentado um estudo experimental com propósito de avaliar com-

parativamente as notações VL4UCD e CTT durante a tarefa de modelagem da intera-

ção usuário-sistema. Para realizar esse estudo foi utilizado o Method Evaluation Model

[Moody 2003], o que nos permitiu, por meio dos seus constructs, verificar, comparativa-

mente, a actual efficacy, perceived efficacy e adoption in practice das notações envolvidas.

A partir dos resultados apresentados foi constatado que a VL4UCD obteve um de-

sempenho significativamente melhor em relação a notação CTT em todas as variáveis

dependentes. Este resultado foi observado tanto no grupo de alunos quanto no grupo de

profissionais. Isso nos permite concluir que, os conceitos existentes na VL4UCD não são

obstáculos para aqueles que já possuem experiência com outras ferramentas de modela-

gem e também para os que, ainda, estão em fase de construção do seu conhecimento.

Para avaliar as hipóteses relacionadas às questões de pesquisa foi aplicado um t-test.

Em todos os casos, os resultados apresentados no t-test foram favoráveis a rejeição das

hipóteses nulas e aceitação das respectivas hipóteses alternativas, conforme apresentada

na quadro resumo (ver tabela 5.9). O que nos permite concluir que a VL4UCD apresentou

melhor aceitação em relação ao CTT, para modelagem da interação usuário-sistema.

Tabela 5.9: Grau de significância dos resultados.Variáveis Grupo-1 Grupo-2 Grupo-3Perceived(Ease(of(Use 0,000 0,015 0,001Perceived(Usefulness 0,000 0,002 0,000Intention(to(Use 0,025 0,024 0,000

Portanto, os resultados do experimento habilitam a VL4UCD a compor o rol de ferra-

mentas empregadas no processo de desenvolvimento de software. Isto poderá contribuir

para evitar que aspectos da interação, relevantes para arquitetura do sistema, sejam desco-

bertos tardiamente, como apresentado por Bass & John (2003) e Folmer & Bosch (2004).

Capítulo 6

Considerações finais

Este capítulo apresenta as contribuições desta tese bem como os trabalhos necessários

para evoluir à pesquisa apresentada.

6.1 Contribuições

Este trabalho apresentou uma proposta de integração das atividades de engenharia de

software e IHC durante a fase inicial do projeto de software interativo com o objetivo

de minimizar os impactos gerados pelas decisões do design da interação sobre o pro-

jeto arquitetural do sistema. Para isso, foram descritas e debatidas as preocupações dos

profissionais de engenharia de software e IHC durante o processo de análise e modela-

gem da interação usuário-sistema como forma de entender suas necessidades (capítulo

2). Apresentou-se, igualmente, que o problema não é recente e que muitos trabalhos vêm

sendo realizados com o intuito de minimizar as dificuldades decorrentes da lacuna entre

as atividades de engenharia e IHC (capítulo 3).

Como proposta à solução do problema, foi apresentada uma linguagem para modela-

gem da interação, com base em conceitos de ambos os grupos, e foram descritos alguns

cenários de aplicação da linguagem (capítulo 4). A VL4UCD tem como objetivo mini-

mizar as deficiências deixadas pelos use cases no que se refere às preocupações de usa-

bilidade do sistema, transformando-os em uma referência para integrar preocupações dos

CAPÍTULO 6. CONSIDERAÇÕES FINAIS 98

profissionais de IHC e ES. A linguagem combina a essência dos use cases à características

relevantes para o projeto de IHC. Dentre as características da VL4UCD destacamos:(i) o

elemento special actions, que permite obter uma visão global da interação, promovendo

uma melhor avaliação da navegabilidade do sistema, que era previamente comprometida

pela fragmentação dos casos de uso; (ii) os elementos basic interaction, que possibilitam

uma descrição clara e objetiva da interação, eliminando o uso de textos vagos e proli-

xos; (iii) a estruturação das interações através de operadores; (iv) redução de conceitos

particulares da comunidade de IHC e distantes da formação da maior parte da equipe de

desenvolvimento.

Com o objetivo de identificar as percepções dos potenciais utilizadores da VL4UCD,

um estudo experimental foi realizado com 38 indivíduos: 30 alunos de graduação e oito

desenvolvedores de software experientes. A fim de implementar o estudo experimental, o

framework teórico Method Evaluation Model foi utilizado.

Os resultados significativamente positivos foram alcançados pela VL4UCD durante

o estudo experimental. Os participantes apontaram que a linguagem proposta é fácil de

usar e útil para o processo de desenvolvimento de software. Como características da

sua utilidade, os participantes perceberam a VL4UCD como uma ferramenta que pode

melhorar a comunicação entre os profissionais de ES e IHC. Além disso, os participantes

também apontaram que a VL4UCD torna possível obter uma visão global da interação.

Quando comparada a outra linguagem de modelagem da interação a VL4UCD apre-

sentou resultados superiores. Para fins do estudo experimental a VL4UCD foi confrontada

com a notação CTT (baseada em modelagem de tarefas do usuário). Neste contexto, fo-

ram elaboradas um conjunto de hipóteses de avaliação. Como resultado tivemos todas as

hipóteses nulas rejeitadas com nível de confiança superior a 95% para o contexto do es-

paço amostral (estudantes de graduação e profissionais de desenvolvimento de software).


6.2 Trabalhos futuros

Durante este trabalho alguns questionamentos com vistas a melhoria da linguagem

sugiram e poderão ser tratados nos próximos passos dessa pesquisa.

Em primeiro lugar é necessário realizar o aperfeiçoamento da ferramenta UCDT, de-

senvolvida para apoiar a modelagem da interação usando a notação VL4UCD. Para fins

desse trabalho a ferramenta foi desenvolvida como plun-in para a IDE Eclipse. Os fra-

meworks utilizados proporcionaram um desenvolvimento rápido por utilizar toda infra-

estrutura existente na IDE. Porém durante a utilização (modelagem da interação) verifica-

se que a ferramenta possui certa instabilidade. Por exemplo, com a inclusão e retirada

de interações básicas e operadores de uma cena durante o processo de modelagem. Para

isto, deve-se realizar um estudo mais aprofundado sobre o framework EMF, já que pela

documentação disponibilizada no site do projeto não foi o suficiente.

Ainda sobre o uso da ferramenta UCDT, seria importante que a mesma estivesse in-

tegrada com ferramentas de modelagem de diagramas UML, por exemplo, ArgoUML 1.

Como vimos, no capítulo 4, elementos da VL4UCD também estão presentes em outras

perspectivas do projeto de software e vice-versa. Esta integração proporcionaria não so-

mente diminuição do tempo de trabalho, mas uma possível diminuição em conflitos de

requisitos do sistema. Podemos, ainda, apresentar a necessidade de geração da descrição

narrativa dos use cases a partir de modelos construídos com a notação VL4UCD.

Com relação ao estudo experimental realizado, tivemos como projetista e avaliador

do processo apenas o autor desta tese. Seria importante e necessário realizar um experi-

mento onde outros profissionais capacitados possam participar trazendo suas experiências

em modelagem da interação usuário-sistema e condução de casos experimentais. Desta

forma, estaremos melhorando a qualidade dos resultados e a validade de construção do

experimento.

Os cenários apresentados para atividade de modelagem correspondem a um domínio1Ferramenta de modelagem UML Open Source - http://argouml.tigris.org/


simples. É interessante a realização de estudo sobre casos de domínios mais complexos,

o que levará a necessidade de maior utilização dos recursos da VL4UCD e da própria

ferramenta (UCDT) de apoio. Os principais objetivos desse estudo devem ser a máxima

exploração dos recurso da linguagem bem como a capacidade de compreensão dos mo-

delos descritos. Modelos com maior quantidades de use cases estendidos acarretará em

maior número de cenas e interações, o que poderá acarretar em complexidade de entendi-

mento da interação.

Por fim, este trabalho apresentou um estudo experimental controlado, ou seja, em

laboratório. É necessário que a VL4UCD seja colocada em produção em ambiente de de-

senvolvimento real. Assim, pode-se avaliar as capacidades da VL4UCD a partir do ponto

de vista dos diversos perfis profissionais, existentes em uma equipe de desenvolvimento

de software.

Referências Bibliográficas

9126-1, ISO/IEC (2000), ‘Iso/iec 9126-1 software engineering – product quality – part 1:

Quality model.’.

9241-11, ISO (1998), ‘Iso 9241-11 ergonomic requirements for office work with visual

display terminals (vdts) – part 11: Guidance on usability.’.

Abran, Alain, Pierre Bourque, Robert Dupuis & James W. Moore, eds. (2004), Guide to

the Software Engineering Body of Knowledge - SWEBOK, IEEE Press, Piscataway,

NJ, USA.

Ahmed, Seffah & Eduard Metzker (2004), ‘The obstacles and myths of usability and

software engineering’, Commun. ACM 47(12), 71–76.

URL: http://doi.acm.org/10.1145/1035134.1035136

Ahmed, Seffah & Gaffar Ashraf (2007), ‘Model-based user interface engineering with

design patterns’, Journal of Systems and Software 80(8), 1408 – 1422. The Impact

of Barry Boehm’s Work on Software Engineering Education and Training.

Alexander, C. (1979), The Timeless Way of Building, Oxford University Press.

Annett, J. & K. D. Duncan (1967), ‘Task analysis and training design’, Journal of Occu-

pational Psychology 41, 211–221.

Bass, Len & Bonnie E. John (2003), ‘Linking usability to software architecture patterns

through general scenarios’, Journal of Systems and Software 66(3), 187 – 197. Soft-

ware architecture – Engineering quality attributes<.

URL: http://www.sciencedirect.com/science/article/pii/S0164121202000766

101

REFERÊNCIAS BIBLIOGRÁFICAS 102

Bass, Len, Paul Clements & Rick Kazman (2003), Software Architecture in Practice, 2a

edição, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Borchers, Jan O. (2000), A pattern approach to interaction design, em ‘Proceedings of the

3rd Conference on Designing Interactive Systems: Processes, Practices, Methods,

and Techniques’, DIS ’00, ACM, New York, NY, USA, pp. 369–378.


Card, Stuart K., Allen Newell & Thomas P. Moran (1983), The Psychology of Human-

Computer Interaction, L. Erlbaum Associates Inc., Hillsdale, NJ, USA.

Cockburn, Alistair (2000), Writing Effective Use Cases, 1sta edição, Addison-Wesley

Longman Publishing Co., Inc., Boston, MA, USA.

Constantine, Larry L. & Lucy A. D. Lockwood (2001), Object modeling and user in-

terface design, em M.Van Harmelen, ed., ‘.’, Addison-Wesley Longman Publishing

Co., Inc., Boston, MA, USA, capítulo Structure and style in use cases for user inter-

face design, pp. 245–279.

URL: http://dl.acm.org/citation.cfm?id=374136.374159

Costa Neto, Macilon Araújo (2013), Uma linguagem de modelagem da interação para

auxiliar a comunicação designer-usuário., Tese de doutorado, Programa de Pós-

graduação em Sistemas e Computação - UFRN.

Coutaz, Joëlle (1987), ‘Pac: An object oriented model for implementing user interfaces’,

SIGCHI Bull. 19(2), 37–41.


Cronbach, Lee J. (1989), ‘Coefficient alpha and the internal structure of tests’, Psycho-

metrika 16(3), 297–334.

URL: http://dx.doi.org/10.1007/BF02310555


da Silva, André Constantino, Junia Coutinho Anacleto Silva, Rosângela Aparecida Del-

losso Penteado & Sérgio Roberto Pereira da Silva (2005), Integrando visões de ihc

e de es por padrões no desenvolvimento por prototipação descartável, em ‘Proce-

edings of the 2005 Latin American conference on Human-computer interaction’,

CLIHC ’05, ACM, New York, NY, USA, pp. 223–234.


Davis, Fred D., Richard P. Bagozzi & Paul R. Warshaw (1989), ‘User acceptance of

computer technology: A comparison of two theoretical models’, Manage. Sci.

35(8), 982–1003.

URL: http://dx.doi.org/10.1287/mnsc.35.8.982

de Souza, Clarisse Sieckenius (2005), The Semiotic Engineering of Human-Computer

Interaction (Acting with Technology), The MIT Press.

Faber, L. (2010), Estatística Aplicada, 4rda edição, Pearson Education.

Fitts, P. M. (1954), ‘The information capacity of the human motor system in controlling

the amplitude of movement’, Journal of Experimental PSychology 74, 381–391.

Folmer, Eelke & Jan Bosch (2003), Usability patterns in software architecture, em ‘Proce-

edings of the Human Computer Interaction International (HCII)’, Conference Pro-

ceedings, pp. 93–97.

Folmer, Eelke & Jan Bosch (2004), ‘Architecting for usability: a survey’, Journal of

Systems and Software 70(1-2), 61–78.


Folmer, Eelke & Jan Bosch (2008), ‘Experiences with Software Architecture Analysis of

Usability’, International Journal of Information Technology and Web Engineering

3(4), 129.


Folmer, Eelke, Jilles van Gurp & Jan Bosch (2004), Software architecture analysis of usa-

bility, em ‘Proceedings of the Joint Working Conferences on Engineering Human

Computer Interaction and Interactive Systems (EHCI-DSVIS)’, Springer LNCS,

pp. 38–58.

URL: http://www.eelke.com/research/ehci2004.pdf

Gamma, Erich, Richard Helm, Ralph Johnson & John Vlissides (1995), Design Pat-

terns: Elements of Reusable Object-oriented Software, Addison-Wesley Longman

Publishing Co., Inc., Boston, MA, USA.

Garlan, David, Felix Bachmann, James Ivers, Judith Stafford, Len Bass, Paul Clements

& Paulo Merson (2010), Documenting Software Architectures: Views and Beyond,

2nda edição, Addison-Wesley Professional.

Hick, W. E. (1952), ‘On the rate of gain of information’, Quarterly Journal of Experimen-

tal Psychology 4(1), 11–26.

URL: http://dx.doi.org/10.1080/17470215208416600

Hofmeister, Christine, Robert Nord & Dilip Soni (2000), Applied software architecture,

Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Hu, Paul J., Patrick Y. K. Chau, Olivia R. Liu Sheng & Kar Yan Tam (1999), ‘Examining

the technology acceptance model using physician acceptance of telemedicine tech-

nology’, J. Manage. Inf. Syst. 16(2), 91–112.

URL: http://dx.doi.org/10.1080/07421222.1999.11518247

Hyman, Ray (1953), ‘Stimulus information as a determinant of reaction time’, Journal of

Experimental Psychology 45, 188–196.

URL: http://psycnet.apa.org/index.cfm?fa=search.displayRecord&uid=1954-

00412-001


Jacobson, Ivar (2004), Object-Oriented Software Engineering: A Use Case Driven Ap-

proach, Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA.

Krasner, Glenn E. & Stephen T. Pope (1988), ‘A cookbook for using the model-view

controller user interface paradigm in smalltalk-80’, J. Object Oriented Program.

1(3), 26–49.


Mayhew, Deborah J. (1999), The usability engineering lifecycle: a practitioner’s hand-

book for user interface design, Morgan Kaufmann Publishers Inc., San Francisco,

CA, USA.

Moody, D.L. (2003), The method evaluati1on model: a theoretical model for validating

information systems design methods, em ‘11th European Conference on Information

Systems, Naples, Italy’, Citeseer.

Moran, T. (1981), ‘The command language grammar: a representation for the user inter-

face of interactive computer systems’, International Journal of Machine Studies 15

pp. 3–50.

Neto, Costa, Alessandro Souza & Jair Leite (2011), Identificando problemas de usabi-

lidade através de inspeção no modelo de interação, em ‘Proceedings of the 10th

Brazilian Symposium on Human Factors in Computing Systems and the 5th Latin

American Conference on Human-Computer Interaction (IHC+CLIHC ’2011)’, Per-

nambuco, Brazil, pp. 124–133.

Nielsen, Jakob (1993), Usability Engineering, Morgan Kaufmann Publishers Inc., San

Francisco, CA, USA.

Nielsen, Jakob (1994), Usability inspection methods, John Wiley & Sons, Inc., New York,

NY, USA, capítulo Heuristic Evaluation, pp. 25–62.



OMG (2013), ‘Unified modeling language specification’.

URL: http://www.omg.org/spec/UML

Paterno, F., C. Mancini & S. Meniconi (1997), Concurtasktrees: A diagrammatic notation

for specifying task models, em ‘.’, Chapman and Hall, pp. 362–369.

Paula, Maíra Greco (2003), Projeto da Interação Humano-Computador Baseado em Mo-

delos Fundamentados na Engenharia Semiótica: Construção de um Modelo de Inte-

ração., Tese de doutorado, Programa de Pós-graduação em Informática da PUC-Rio.

Pohl, Klaus & Chris Rupp (2011), Requirements Engineering Fundamentals: A Study

Guide for the Certified Professional for Requirements Engineering Exam - Founda-

tion Level - IREB compliant, 1sta edição, Rocky Nook.

Rescher, N. (1979), ‘Methodological pragmatism: systems-theoretic approach to the the-

ory of knowledge’, The Philosophical Review 88(3), 490–496.

Rogers, Yvonne, Helen Sharp & Jenny Preece (2011), Interaction Design: Beyond Hu-

man - Computer Interaction, 3rda edição, Wiley Publishing.

Runeson, Per (2003), Using students as experiment subjects – an analysis on graduate and

freshmen student data, em ‘Proceedings 7th International Conference on Empirical

Assessment & Evaluation in Software Engineering’, pp. 95–102.

Shneiderman, Ben (1997), Designing the User Interface: Strategies for Effective Human-

Computer Interaction, 3rda edição, Addison-Wesley Longman Publishing Co., Inc.,

Boston, MA, USA.

Silva, Bruno Santana (2005), MoLIC Segunda Edição: revisão de uma linguagem para

modelagem da interação humano-computador., Tese de doutorado, Programa de

Pós-graduação em Informática da PUC-Rio.


Silva, Paulo Pinheiro Da & Norman W. Paton (2003), Improving uml support for user

interface design: A metric assessment of umli, em ‘Workshop on Bridging the Gaps

Between Software Engineering and Human-Computer Interaction at International

Conference on Software Engineering (ICSE ’2003)’, pp. 76–83.

Sommerville, Ian (2010), Software engineering (9th ed.), Addison-Wesley, Boston, MA,

USA.

Somé, Stéphane S. (2006), ‘Supporting use case based requirements engineering’, Infor-

mation and Software Technology 48(1), 43 – 58.


Tidwell, Jenifer (2005), Designing Interfaces: Patterns for Effective Interaction Design,

Vol. 2008, O’Reilly Media, Inc.

Welie, Van (2016), ‘A pattern library for interaction design’.

URL: http://www.welie.com/patterns/

Wohlin, Claes, Per Runeson, Martin Hst, Magnus C. Ohlsson, Bjrn Regnell & An-

ders Wessln (2012), Experimentation in Software Engineering, Springer Publishing

Company, Incorporated.

Apêndice A

Matriz de benefícios/táticas

Composição da matriz de benefícios de usabilidade e táticas arquiteturais propostos

por Bass & John (2003).

Legenda

1. Aggregating data

2. Aggregating commands

3. Canceling commands

4. Using applications concurrently

5. Checking for correctness

6. Maintaining device independence

7. Evaluating the system

8. Recovering from failure

9. Retrieving forgotten passwords

10. Providing good help

11. Reusing information

12. Supporting international use

13. Leveraging human knowledge

14. Modifying interfaces

15. Supporting multiple activities

16. Navigating within a single view

17. Observing system state

18. Working at the user’s pace

19. Predicting task duration

20. Supporting comprehensive searching

21. Supporting undo

22. Woking in an unfamiliar context

23. Verifying resources

24. Operating consistently across views

25. Making views accessible

26. Supporting visualization

27. Supporting personalization

APÊNDICE A. MATRIZ DE BENEFÍCIOS/TÁTICAS 109

Figura A.1: Matriz de benefícios de usabilidade vs. táticas arquiteturais, extraído de Bass& John (2003)

Apêndice B

Imagens ampliadas do capítulo 4

Figura B.1: Modelo em VL4UCD para o use case criar projeto.

APÊNDICE B. IMAGENS AMPLIADAS DO CAPÍTULO 4 111

Figura B.2: Modelo em VL4UCD para o use case criar POU.


Figura B.3: Modelo em VL4UCD para o use case Login.


Figura B.4: Modelo em VL4UCD para o use case “Fechar conta”.

QUESTIONÁRIO DE PERFIL DO PARTICIPANTE

Através deste questionário procuraremos conhecer melhor o perfil de cada participante da pesquisa em curso. Pedimos que preencha com atenção e clareza os dados solicitados abaixo. Caso tenha alguma dúvida, entre em contato conosco. FORMAÇÃO ACADÊMICA 1) Você possui algum curso técnico? ( ) Sim. Especifique: __________________________________________________________________ ( ) Não 2) Você possui algum curso de graduação? ( ) Sim. Especifique : __________________________________________________________________ ( ) Não 3) Você possui algum curso de pós-‐graduação? ( ) Sim. Especifique : __________________________________________________________________ ( ) Não 4) Há quantos anos você concluiu a graduação (apenas para graduados)? ( ) De 1 a 2 anos ( ) De 3 a 5 anos ( ) De 6 a 8 anos ( ) Mais de 9 anos DADOS PROFISSIONAIS 5) Você já trabalhou com desenvolvimento de software? ( ) Sim. Quanto tempo? _________ ( ) Não 6) Se sua resposta foi SIM na questão anterior, então marque as áreas em que atuou no desenvolvimento. (Aqui você pode marcar mais de uma opção) ( ) Análise de requisitos ( ) Arquiteto de software ( ) Codificação ( ) Teste de software ( ) Interface com o usuário ( ) Outro: ______________________________________________________________________________

Apêndice C

Questionário Demográfico

114

FAMILIARIDADE COM IHC 7) Qual o nível de conhecimento que você considera ter sobre IHC? ( ) Muito pequeno ( ) Pequeno ( ) Médio ( ) Grande ( ) Muito Grande 8) Qual o nível de conhecimento que você considera ter sobre análise de tarefas? ( ) Muito pequeno ( ) Pequeno ( ) Médio ( ) Grande ( ) Muito Grande 9) Quais das técnicas abaixo você utiliza/utilizou para identificar requisitos de IHC? (Aqui você pode marcar mais de uma opção) ( ) Entrevistas e questionários ( ) Focus groups ( ) Card sorting ( ) Estudos de campo ( ) Investigação contextual ( ) Outros: ___________________________________________________________________________ __________________________________________________________________________________________ 10) Quais das técnicas abaixo você utiliza/utilizou para descrever o usuário e como seus objetivos podem ser alcançados durante a interação com o sistema? (Aqui você pode marcar mais de uma opção) ( ) Cenários ( ) Personas ( ) CTT ( Concur Task Trees ) ( ) GOMS ( Goals, Operators, Mehods e Selection Rules ) ( ) HTA ( Hierarchical Task Analysis ) ( ) Outros: ___________________________________________________________________________ __________________________________________________________________________________________

FAMILIARIDADE COM ENG. DE SOFTWARE 11) Qual o nível de conhecimento que você considera ter sobre Engenharia de Software? ( ) Muito pequeno ( ) Pequeno ( ) Médio ( ) Grande ( ) Muito Grande 12) Qual o nível de conhecimento que você considera ter sobre os diagramas da UML? ( ) Muito pequeno ( ) Pequeno ( ) Médio ( ) Grande ( ) Muito Grande 13) Qual o nível de conhecimento que você considera ter sobre descrição de Casos de Uso? ( ) Muito pequeno ( ) Pequeno ( ) Médio ( ) Grande ( ) Muito Grande 14) Com quais processos de software você teve/tem experiência profissional? (Aqui você pode marcar mais de uma opção) ( ) RUP ( ) Scrum ( ) PSP ( ) XP ( ) Outros: __________________________________________________________________________ _________________________________________________________________________________________

Modelagem de Cenários usando VL4UCD

Atividade 1 – Reservar quarto de hotel. Desenhe um diagrama, usando a notação VL4UCD, que represente a tarefa de reservar quarto de hotel. Neste cenário os usuários devem acessar o sistema via browser e escolher o tipo de quarto desejado, que pode ser duplo ou simples. Após escolher o tipo de quarto, o sistema apresenta as disponibilidades de quartos para o tipo escolhido. Então o usuário seleciona o quarto e confirma a reserva. Hora de início: Hora de término:

Apêndice D

Objeto Experimental

117

Modelagem de Cenários usando CTT

Atividade 2 – Sacar dinheiro em terminal eletrônico. Desenhe um diagrama, usando a notação VL4UCD, que represente a tarefa de sacar dinheiro em um terminal eletrônico. Neste cenário os usuários devem habilitar seu acesso inserindo o cartão magnético e digitando a senha da conta. Após isso, o usuário seleciona a opção SAQUE, o sistema apresenta os possíveis valores a serem sacados, o usuário decide qual valor sacar e entra com a informação. Então o sistema processa a informação e entrega o dinheiro para o usuário que confere e encerra o acesso eletrônico ao banco. Hora de início: Hora de término:


NOTAÇÃO Visual Language For Use Case Description -‐ VL4UCD

Elementos Gráficos

Abrir Interação

Representam o inicio da interação.

Fechar Interação

Representam o fim da interação.

Processamento do

Sistema

Representa o processamento interno do software para atender as solicitações dos usuários.

Cena

Representa os momentos em que o usuário pode realizar suas ações de interação para atingir um certo objetivo.

Ação /Reação de

sucesso

Representam ações do usuário sobre a interface e as reações/respostas positivas do sistema para cada ação do usuário.

Reação de Erro

Representam as respostas do sistemas a anormalidades durante o processamento.

Sincronização

Permite representar o status do processamento interno do sistema para uma funcionalidade requisitada. Seria equivalente a um progress bar.

OPERADORES Sequence Indica a ordem em que as interações devem acontecer Choose Indica a possibilidade de escolha entre as interações possíveis. Repeat Determina que algumas interações devem ser realizadas de

forma repetida. Join Indica que as interações devem ocorrer em conjunto

Interações Básica

Perceive Apresentação de dados como, por exemplo, um texto não editável.

Enter Representa uma entrada de dados como, por exemplo, uma caixa de texto (edit).

Select Usado para representar uma seleção de dados, por exemplo, list-‐box ou como-‐box.

Active Usado para representar a ativação de uma das funcionalidades do sistema.


Atividade 1 – Reservar quarto de hotel. Desenhe um diagrama, usando a notação CTT, que represente a tarefa de reservar quarto de hotel. Neste cenário os usuários devem acessar o sistema via browser e escolher o tipo de quarto desejado, que pode ser duplo ou simples. Após escolher o tipo de quarto, o sistema apresenta as disponibilidades de quartos para o tipo escolhido. Então o usuário seleciona o quarto e confirma a reserva. Hora de início: Hora de término:


Atividade 2 – Sacar dinheiro em terminal eletrônico. Desenhe um diagrama, usando a notação CTT, que represente a tarefa de sacar dinheiro em um terminal eletrônico. Neste cenário os usuários devem habilitar seu acesso inserindo o cartão magnético e digitando a senha da conta. Após isso, o usuário seleciona a opção SAQUE, o sistema apresenta os possíveis valores a serem sacados, o usuário decide qual valor sacar e entra com a informação. Então o sistema processa a informação e entrega o dinheiro para o usuário que confere e encerra o acesso eletrônico ao banco. Hora de início: Hora de término:


NOTAÇÃO Concurrent Task Tree -‐ CTT

TAREFAS

Tarefa do Usuário

Representa as tarefas realizadas fora do sistema.

Tarefa da Aplicação

Representa o processamento interno do sistema

Tarefa Abstrata

Não são tarefas em se, mas uma composição que auxilia a decomposição

Tarefa de Interação

Representam os diálogos entre usuário e sistema.

OPERADORES Ativação T1 >> T2

Significa que a T2 só pode iniciar após T1 terminar.

Escolha T1 [] T2

Significa que apenas uma das tarefas, T1 ou T2, será executada.

Ativação com passagem de parâmetros T1[] >> T2

Significa que até de T2 só poder ser ativa a após conclusão de T1, a informação produzida em T1 é passada para T2.

Tarefas concorrentes T1|||T2

Significa que as tarefas podem ser realizadas em qualquer ordem ou ao mesmo tempo.

Tarefas concorrentes e comunicantes T1|[]|T2

Significa que, além das tarefas poderem ser realizadas em qualquer ordem ou ao mesmo tempo, elas podem trocar informações.

Tarefas independentes T1|=|T2

Significa que as tarefas podem ser realizadas em qualquer ordem, mas quando uma delas é iniciada, precisa terminar para que outra possa ser iniciada.

Desativação T1[>T2

Significa que a tarefa T1 é completamente interrompida por T2.

Suspenção-‐Retomada T1 |> T2

Significa que a tarefa T1 pode ser interrompida por T2 e é retomada do ponto que parou quando T2 finalizar.

uma linguagem visual para descrição de use cases. · uma linguagem visual para descrição de use...

Documents