Projeto de interface com o usuário no processo de desenvolvimento

O desenvolvimento de sistemas interativos é um processo eminentemente multidis- ciplinar requerendo idealmente o trabalho de uma equipe formada por profissionais das várias áreas envolvidas (como p.ex. Design Visual e Gráfico, Ergonomia e Engenharia de Software entre outras). Na prática do desenvolvimento, contudo, é reconhecida a enorme dificuldade de comunicação e integração entre estes membros de equipes multi- disciplinares, devido provavelmente à dificuldade de integração de conceitos de suas disciplinas: cada uma possui seu vocabulário específico, suas expressões e notações, suas formas de organizar o desenvolvimento, etc. Inúmeros trabalhos de pesquisa (IC- SE, 2003; Seffah et al., 2005) convergem para a idéia central de que para desenvolver sistemas interativos que sejam úteis e usáveis tem-se necessidade de uma integração sistemática e correspondências explícitas entre a variedade de teorias, modelos, técnicas e ferramentas das diferentes áreas e que possibilite concretamente um desenvolvimento em equipe mais efetivo. Nosso trabalho nos últimos anos tem sido um esforço interdis- ciplinar de integração das áreas de Engenharia de Software (abreviada ES) e Interação Humano-Computador (abreviada IHC) e segue uma tendência atual de mudança de ati- tude da ES em face de fatores humanos.

A interseção entre as áreas de ES e IHC não é ainda nem natural nem objetiva. En- tretanto, as comunidades de ES e IHC são unânimes em reconhecer que um sistema interativo só é bem sucedido se atende às expectativas de seus usuários (Denning, 1994); Cox, 1993). No âmbito da ES, o termo "expectativas" tem sido tipicamente entendido como sinônimo de "requisitos funcionais", dando pouca ou nenhuma atenção aos requisitos não funcionais de usabilidade ou de interação. Claramente, enfoques tra- dicionais da ES e mesmo os enfoques orientados a objeto mais atuais (p.ex. Processo Unificado (PU) (Kruchten, 2000), e outros baseados na notação UML) mostram-se fre- qüentemente inoperantes e inadequados para desenvolver sistemas interativos, não con-

48

templando o ponto de vista do usuário e não prevendo explicitamente o projeto das in- terfaces com o usuário (abreviadas IU) como uma de suas etapas. Esta lacuna está na origem de um problema de integração multidisciplinar que se manifesta desde o início do planejamento do sistema e continua durante todo o ciclo de vida do sistema interati- vo (Barthet, 1988): cada área considera aspectos diferentes e muitas vezes disjuntos do sistema sem nenhuma correspondência explícita e sistematicamente estabelecida entre eles. Sem esta correspondência, não há interação nem integração possível entre os espe- cialistas de cada área (projetista de software e designer de interface). Entretanto, o pro- jeto de IUs é uma atividade importante que necessita muito esforço da equipe e é consi- derada como um fator crítico de sucesso nos projetos de software da atualidade (Procac- cino et al., 2005). Portanto, devem-se propor estratégias em que esta atividade esteja mais claramente descrita no processo de desenvolvimento.

Tendo como referência o Processo Unificado (PU), o projeto de IU ocorre após a de- finição dos requisitos funcionais do sistema que, na UML, são representados pelo mo- delo de casos de uso.

O papel dos casos de uso na especificação de interfaces com o usuário ainda é uma questão em aberto. Existem ainda muitas dificuldades e carências de métodos e técnicas para se obter interfaces com qualidade/usabilidade a partir de uma especificação de caso de uso. Em particular, um dos problemas é de que a engenharia de requisitos tem usu- almente priorizado sua atenção para os requisitos funcionais dando pouca ou nenhuma atenção aos requisitos de usabilidade ou de interação. Assim, mesmo enfoques orienta- dos a objetos mais atuais mostram-se freqüentemente inoperantes e inadequados para desenvolver sistemas interativos: a principal reclamação que se pode fazer a estes enfo- ques tradicionais é que eles não incitam os analistas a complementar sua visão orienta- da ao sistema com o ponto de vista do usuário. Conseqüentemente eles são levados a deduzir a concepção da interface a partir da lógica de funcionamento das funções da aplicação e não a partir da lógica de utilização do sistema como um suporte à realização de tarefas dos usuários (Pimenta, 2000).

Um caso de uso passa por fases (e correspondentes níveis de abstração e de refina- mento de descrição) ao longo do seu ciclo de vida: inicialmente, a descrição de um caso de uso consiste de um enunciado sucinto de seu objetivo. A partir daí, faz-se o detalha- mento desta descrição do caso de uso com a definição dos passos do fluxo principal e fluxos alternativos, bem como os possíveis relacionamentos (inclusão, extensão e gene- ralização) com outros casos de uso. Estas são algumas das atividades que constituem a modelagem de casos de uso (Bittner & Spence, 2003).

Em um processo de desenvolvimento dirigido por casos de uso, é a partir das descri- ções dos casos de uso que se desenvolve o projeto da IU. Atualmente, é senso comum que estas descrições devem estar no grau de abstração essencial (Constantine & Lock- wood, 1999; Cockburn, 2005). Na narrativa essencial, são explicitadas as interações entre o ator e o sistema sem descrever detalhes de como e onde estas interações serão realizadas.

A partir da descrição dos casos de uso essenciais, constrói-se um protótipo da inter- face com o usuário. O objetivo do protótipo é ajudar a validar os requisitos funcionais especificados nos casos de uso e validar se a interface está implementando adequada- mente as interações necessárias para que o caso de uso atinja o objetivo.

Para construir um protótipo, o ambiente de interação deve ser definido, isto é, devem ser identificados os elementos de interação que vão ser utilizados (a tecnologia da inter-

49

face) e o contexto no qual se dará a interação. Entretanto, a tecnologia de implementa- ção destas interfaces não precisa necessariamente ter sido definida. Pode-se por exem- plo fazer o projeto de interface de uma aplicação gráfica desktop a ser executada no ambiente Gnome/Linux sem saber qual a linguagem de programação e a arquitetura da aplicação que serão utilizadas para a sua construção.

O protótipo é, então, apresentado para um ou mais usuários que podem simular a e- xecução das tarefas que serão suportadas pelo sistema e, a partir daí, fazer críticas acer- ca de uma ou outra característica. Além do feedback dos usuários, a equipe do projeto pode observar os usuários em ação e, com isso, identificar eventuais dificuldades na realização das tarefas, no uso das interfaces, bem como identificar discrepâncias nos requisitos funcionais. O protótipo é então corrigido ou refinado de acordo com tais críti- cas. Esse processo de revisão e refinamento continua iterativamente até que o protótipo atinja um nível satisfatório e seja aceito pelos usuários.

Os protótipos e as especificações das IUs constituem um conjunto de artefatos que chamamos de casos de uso apresentados. Os casos de uso apresentados são a forma visual e perceptível da descrição dos fluxos dos casos de uso essenciais. Eles ainda não fazem referência aos objetos de negócio do sistema, pois representam um nível interme- diário entre a narrativa conceitual definida no modelo de casos de uso e os objetos e suas colaborações definidos na fase de realização dos casos de uso.

A fase que agrupa o conjunto das atividades necessárias para a obtenção dos casos de uso apresentados é chamada de apresentação de caso de uso (use case presentation).

Com os casos de uso apresentados definidos e validados, passa-se para a atividade de projeto OO, onde são traduzidos os elementos da IU em termos de objetos e classes e é especificado como esses objetos e classes colaboram entre si para a realização do caso de uso. Esta fase é chamada de realização do caso de uso (use case realization) (Jacob- son et al., 1992).