A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário

A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário Jair Cavalcanti Leite Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte Campus Universitário - Lagoa Nova 59072-970 - Natal RN jair@dimap.ufrn.br Resumo A teoria semiótica revela que uma das possíveis causas da baixa usabilidade dos sistemas computacionais é que desenvolvedores e usuários possuem visões distintas da aplicação. Os usuários possuem uma visão externa, obtida a partir da interface de usuário, enquanto desenvolvedores possuem uma visão interna que é obtida a partir de linguagens de especificação ou de programação. Estas linguagens são baseadas em modelos computacionais e descrevem o funcionamento do sistema. Diversos pesquisadores argumentam que é preciso introduzir no desenvolvimento de software a atividade de design na qual designers e usuários compartilhem a mesma visão do produto [Winograd 96]. A Engenharia Semiótica é uma abordagem que considera que o design de software é um processo metacomunicativo no qual o designer envia uma mensagem para os usuários cujo conteúdo é o modelo conceitual da aplicação [De Souza 93]. A expressão desta mensagem é composta todas as mensagens trocadas entre usuário e sistema através da interface de usuário. Neste trabalho vamos mostrar que o design de software deve ser conduzido como um processo comunicativo e deve possibilitar que ambos compartilhem o mesmo modelo conceitual da aplicação. Neste processo o designer deve representar elementos do domínio da aplicação não como tipos de dados de uma linguagem de programação, mas como signos de interface. A funcionalidade do software é determinada pelo repertório de funções de aplicação que operam sobre objetos. Objetos e funções de aplicação são comunicados ao usuário através dos signos de interface que formam a mensagem do designer. Palavras-chaves: Design de Software, Design de Interfaces de Usuário, Semiótica Computacional, Interação Humano-Computador. 1. Introdução A utilidade de um sistema computacional deve ser considerada em três níveis distintos. No nível do computador a ênfase está no hardware e software do sistema. É preciso definir como os procedimentos podem ser automatizados e como as informações podem ser codificadas. Neste nível é importante avaliar a qualidade dos diversos elementos do computador como confiabilidade, segurança, eficiência dentre outras. No nível da interação humano-computador a ênfase está nas atividades que os usuários devem fazer e na forma como as informações são percebidas ou produzidas por eles. Neste nível, as tarefas do domínio devem determinar metas para cada usuário que devem poder ser realizadas utilizando o sistema. É neste nível também que se avalia a usabilidade do sistema, isto é, a facilidade de uso e de aprendizado, produtividade e satisfação do usuário, dentre outras qualidades. No nível do contexto todos o componentes podem ser visualizados de forma integrada. Neste nível o hardware e o software são visto como um componente único que interage com os diversos usuários de maneira a permitir que as tarefas do domínio possam ser realizadas. Neste nível avalia-se o quanto o sistema resolve os problemas da organização, isto é, a sua aplicabilidade. O foco da ciência da computação está no nível do computador. Na engenharia de software, tradicionalmente um campo científico pertencente à ciência da computação, alguns métodos e técnicas de desenvolvimento abordam apenas o conhecimento necessário para o desenvolvimento com foco no nível do computador sem dar a devida importância ao nível da

interação e do contexto. Na década de 80, alguns autores ressaltaram a importância de desenvolver sistemas centrado-no-usuário com o objetivo de produzir sistemas que atendessem às necessidades de usuários e melhorassem a sua usabilidade [Norman & Draper 86]. Recentemente diversos autores argumentaram sobre a necessidade de trazer para o desenvolvimento de software a atividade de design, no mesmo sentido do papel que a atividade de design industrial desempenha para o desenvolvimento de artefatos em geral, ou que a arquitetura desempenha para a construção civil [Winograd 86]. Segundo David Liddle, "o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário" [Liddle 86]. Neste sentido, design compreende as atividades de concepção, especificação e prototipagem de um artefato interativo cuja matéria prima são os signos que o formam. A experiência do usuário surge da interação com o sistema através destes signos. Na perspectiva de design o software deve ser visto como um artefato virtual e como tal ele é um produto a ser aplicado com utilidade num certo contexto e por isso chamado de aplicação de software. Este artefato virtual é algo que possui um modelo conceitual próprio a sua funcionalidade e a sua interatividade. A funcionalidade determina aquilo o que ele faz e que o torna útil para resolver problemas dos usuários. A interatividade determina a maneira como o usuário deverá utilizar o software. A perspectiva de design precisa ampliar o foco e considerar não apenas o computador, mas também os níveis da interação e do contexto. Este trabalho discute a importância da perspectiva de design de software e apresenta um framework conceitual que orienta como esta atividade deve ser desempenhada. No framework o design de software compreende a concepção, especificação e prototipagem da partes externas, internas e conceituais do software. A parte externa compreende a interface de usuário. A parte interna compreende a arquitetura de componentes de software e os algoritmos e estruturas de dados que implementam estes componentes. A parte conceitual corresponde aos modelos mentais obtidos das diferentes perspectivas que usuários, programadores e designers possuem quando interpretam o software. O framework permite o design do software em termos dos seus elementos externos, internos e conceituais, possibilitando a integração das diferentes perspectivas. Nosso trabalho está fundamentado em teoria semiótica e segue a abordagem denominada de Engenharia Semiótica [de Souza 93]. Ele faz parte de um contexto mais amplo que aplica teoria semiótica no design de interfaces e programação para usuário-final. Modelos e formalismo para o design de interfaces forma descritos em [Leite 98]. Na seção seguinte vamos apresentar um exemplo que mostra diferentes perspectivas de uma aplicação, diferenciando a importância da perspectiva de design. Na seção 3 apresentamos a fundamentação teórica que explica estas diferentes perspectivas e discutimos as suas conseqüências para o design. A seção 3 introduz a abordagem da Engenharia Semiótica para o design de software. Na seção 4 apresentamos o framework conceitual para o design que distingue os elementos conceituais, computacionais e de interface, de acordo com a teoria estudada. Na última seção discutiremos a importância da perspectiva de design e da teoria semiótica na engenharia de software.

2. As diferentes perspectivas em um software Usuários e programadores normalmente possuem diferentes perspectivas de um software. A perspectiva do usuário de uma aplicação de software está em como ele pode resolver os problemas do usuário. A perspectiva de um programador está em como uma certa solução é resolvida por algoritmos. No design centrado-no-usuário o designer precisa ter uma perspectiva que seja a mais próxima possível daquela que o usuário tem do sistema. Nesta seção vamos discutir as perspectivas do usuário e do programador. Na seção 4 discutiremos a perspectiva do designer. Para exemplificar as diferentes perspectivas do usuário e do programador, vejamos o exemplo de um programa simples que, com pequenas alterações no programa que não alteram a essência do algoritmo, pode ser visto como aplicações de software de distintas. Vamos supor que um usuário esteja utilizando uma aplicação de software. Vejamos o seguinte trecho de interação entre o usuário (U) e o sistema (S). S: Forneça um número: U: 5.3 S: Você deve digitar apenas números inteiros: U: 5 S: Forneça outro número: U: 8 S: O resultado é 3 Observando a interação do usuário com o sistema podemos concluir que o software realizou uma subtração. Assim, a funcionalidade deste software é realizar subtrações de dois números inteiros. Vejamos, agora o algoritmo que poderia gerar este software. escreva("forneça um Número:"); leia A; enquanto A não for inteiro faça escreva( Você deve digitar apenas números inteiros: ) leia A; escreva("forneça outro Número:"); leia B; C = A - B; escreva("o resultado é ", C); Vejamos agora o que acontece se modificarmos as linhas 1, 6 e 9 deste algoritmo para escreva("forneça o valor de venda"); escreva("forneça o valor de compra"); escreva("o lucro é",c); Para o programador muito pouca coisa mudou, mas para o usuário este software agora é visto como uma aplicação de cálculo de lucros de vendas. As alterações no programa foram bastante pequenas, mas produziu um efeito significativo. A perspectiva de software como artefato deve considerar como o usuário vê a aplicação. Os modelos conceituais da funcionalidade do software são distintos. Desta forma, temos softwares distintos com aplicações em domínios distintos. O programa nos fornece uma visão de funcionamento. O usuário possui apenas a visão de funcionalidade. Podemos modificar as mesmas linhas do programa e teremos novas possibilidades de aplicação. escreva("saldo atual"); escreva("valor de saque"); escreva("saldo resultante",c);

Estas diferentes perspectivas ocorrem pelas diferentes interpretações que usuários e programadores fazem do software. Programadores interpretam o software a partir da linguagem de programação. A semântica da linguagem de programação possibilitar interpretações do software em termos de transformações de estados de variáveis de armazenamento de dados. A interpretação que o usuário tem do sistema é obtida a partir dos elementos da interface de usuário. A esta interpretação damos o nome de modelo conceitual da aplicação. Cada signo utilizado no processo de interação vai permitir ao usuário construir o seu modelo conceitual da aplicação. Vejamos a seguir com a teoria semiótica explica estas diferenças de perspectivas. 3. O modelo conceitual da aplicação O modelo conceitual é uma entidade abstrata que existe na mente dos usuários quando eles estão interagindo com o sistema. Este modelo conceitual determina, para o usuário, quais os quais os objetos da aplicação, suas propriedades, relacionamentos e estados. Além disso, ele determina também o que o usuário pode fazer com a aplicação (a funcionalidade) e como ele pode interagir com a aplicação (a interatividade). Ao utilizarmos um sistema operacional, como o Unix ou o MS DOS, sabemos que podemos construir, armazenar e organizar arquivos de software. Um arquivo é na verdade uma seqüência de bits como começo e fim definidos. Para o usuário o arquivo é algo conceitual que se refere a documentos, programas, dados, etc. Esta entidade conceitual surge na mente do usuário e tem como propriedades um nome, um tipo, uma data de criação e um tamanho em bytes. Arquivos são armazenados em discos em trilhas e setores e podem ser localizados a partir de uma tabela que associa o seu nome ao local físico. Para o usuário, arquivos são colocados "dentro" de uma outra entidade conceitual: o diretório. Arquivos e diretórios são os objetos da aplicação e podem ser criados, destruídos ou modificados por diversas funções da aplicação. Estas funções são, por exemplo, copiar arquivo, apagar arquivos, construir diretórios, remover diretórios, colocar arquivos em um diretório, mover arquivo de um diretório para outro, etc. Estas funções são também entidades virtuais representadas por um nome que devem indicar, para o usuário, o que o sistema faz. Por exemplo, o sistema operacional não coloca arquivos dentro de um diretório. Isto só existe na mente do usuário. O que o sistema faz é trocar o endereço físico do arquivo na tabela de arquivos e diretórios. Entretanto, a visão de que diretórios são recipientes que armazenam arquivos é muito mais útil para o usuário. Ela permite ao usuário criar na sua mente conceitos da aplicação que permitem a ele entender o que fazer com o sistema e raciocinar melhor sobre ele. O sucesso de uma aplicação vai depender justamente da criação deste modelo conceitual. Quanto mais claros forem os conceitos e as operações que se pode fazer com eles, mais o usuário vai saber como aplicá-los na resolução de seus problemas. O sucesso de sistemas como o Apple Macintosh deve-se à construção de modelos conceituais mais familiares para os usuários. Os conceitos de pastas e documentos e a representação deles através de janelas e ícones permitem ao usuário criar imagens mentais mais claras e que são familiares as atividades que eles realizam num escritório. O conceito de pasta como recipiente é mais claro que o de diretório (que na verdade é uma lista de índices). No Macintosh o usuário move objetos (documentos, aplicativos, figuras, etc.) de uma pasta para outra e para o topo-de-mesa (desktop) como faria nos seus escritórios.

A perspectiva de design requer que designer e usuários compartilhem o mesmo modelo conceitual. Na próxima mostraremos que o design de software precisa ser visto como um processo comunicativo entre designer e usuário para que o modelo conceitual seja comum a eles. 4. A fundamentação semiótica para as diferentes perspectivas A semiótica é a disciplina que estuda os signos e os processos de comunicação e significação [Eco 76]. Um signo é definido por Peirce como aquilo que, sob certo aspecto ou modo, representa algo para alguém. Dirige-se a alguém, isto é, cria na mente dessa pessoa um signo equivalente, ou talvez um signo mais desenvolvido. Ao signo assim criado denomino interpretante do primeiro signo [Peirce 31]. O signo é produto de uma relação entre três elementos: a expressão que é aquilo que representa; o objeto aquilo que é representado; e o seu interpretante a capacidade mental no contexto do processo do signo. O relacionamento entre estes três elementos está na figura 1. Expressão E I Interpretante Objeto O Figura 1: O Signo de Peirce Signos podem ser produzidos a partir de diferentes sistemas de signos. Exemplos são as palavras ou sentenças de uma língua, os comandos de uma linguagem de programação ou símbolos de sinalização, dentre inúmeros outros. Diferentes tipos de códigos permitem produzir diferentes tipos de signos e diferentes interpretações para cada um deles. Numa aplicação de software, programas são construídos por signos de uma linguagem de programação e utilizados através de signos de interface. Os signos de interface normalmente são produzidos a partir de palavras e elementos gráficos de diferentes tipos de códigos. A semiótica nos ajuda a entender alguns problemas no desenvolvimento de software e revela o importante papel que as linguagens possuem na interpretação software. Designers, programadores, e usuários do sistema utilizam diferentes sistemas de signos para produzirem e/ou entender a aplicação. Vamos considerar que a aplicação é um signo no sentido proposto por Peirce. Para o usuário a expressão deste signo é formada pelas diferentes mensagens de interação veiculadas pelos signos de interface. O interpretante deste signo é o modelo conceitual que ele adquire e permite-lhe compreender o que fazer e como interagir com a aplicação. O objeto deste signo é as diferentes aplicações do programa na resolução de problemas. Na perspectiva do programador a expressão é o programa fonte que deve ser interpretada de acordo com a semântica da linguagem de programação. Desta forma, o objeto deste signo é o conjunto de todos os caminhos possíveis de execução e transformação nos estados de dados e espaços de memória, que é definido formalmente pela semântica da linguagem de programação [Meyer 86]. O programa fonte gera como interpretantes mais imediatos o funcionamento do programa. Apenas programadores que conheçam a fundo a semântica da

linguagem e consigam realizar abstrações a partir de algoritmos e estruturas de dados codificadas conseguirão chegar a interpretantes de usabilidade. Por utilizarem expressões diferentes, os interpretantes do designer, do programador e do usuário não são idênticos ao modelo semântico determinado pela linguagem de programação. A figura 2 (a) e (b) a seguir representam as diferentes perspectivas para o exemplo do programa subtração que ocorrem quando o intérprete é o programador (figura 3a) e quando é o usuário (figura 3b). Para o programador, a linguagem de programação restringe os interpretantes em torno dos conceitos de transformação de estados de dados e espaços de memória, dificultando a interpretação da aplicação do software. Para o usuário, os signos de interface devem comunicar como ele pode aplicar o programa na resolução de problemas. Programa fonte, em linguagem de programação. E Signos da Interface de Usuário E Transformação de estados de dados e espaços de memória. I Compreensão do funcionamento do programa. Modelo conceitual da aplicação subtração I Compreensão e utilização do modelo conceitual da aplicação O O Figura 2: Signos da Aplicação Subtração: (a) interpretado pelo programador e (b) interpretado pelo usuário Com base na discussão da seção anterior podemos concluir que a atividade de design de software, no sentido mencionado na introdução, requer notações que permitam ao designer uma perspectiva próxima daquela que o usuário terá. Isto significa que os modelos conceituais adquiridos pelo usuário e pelo designer devem ser bastante semelhantes. Os métodos de design de software devem utilizar-se apenas de modelos que permitam antecipar a usabilidade. Os cenários, esboços e protótipos são exemplos de modelos que auxiliam o designer a compartilhar a mesma perspectiva do usuário. Notações mais tradicionais da engenharia de software como diagramas da arquitetura do software, algoritmos descritos em linguagem natural estruturada, modelos gráficos de estruturas de dados, linguagens de especificação funcional, dentre outras, visam descrever abstratamente o funcionamento e não a usabilidade. Entretanto, não basta apenas utilizar a mesma notação que será utilizada pelo usuário. É preciso ter a garantia de que mesmo utilizando expressões iguais, as interpretações do designer e do usuário serão compatíveis entre si. Para atingirmos este objetivo o processo de design de software deve ser visto como um processo comunicativo no qual o designer elabora uma mensagem expressa através da interface de usuário cujo conteúdo é o modelo conceitual da aplicação. Será preciso utilizar uma notação para a elaboração do modelo conceitual e regras que permitam correlacionar elementos do modelo com os signos da interface de usuário.

5. A Engenharia Semiótica A Engenharia Semiótica é uma abordagem na qual sistemas são considerados como artefatos de metacomunicação [de Souza 93]. Nesta perspectiva a interface é vista como uma mensagem unidirecional e indireta de designers para usuários. Esta mensagem se caracteriza pela sua capacidade de, ela própria, enviar e receber mensagens durante o processo de interação entre o usuário e o sistema. Quando o usuário entra em contato visual (ou, mais genericamente, sensorial) com a interface, ele realiza um esforço de interpretação e compreensão a respeito do significado de todos os seus dispositivos e da informação que eles veiculam. O conceito de signo como apresentado por Peirce mostra-nos que a mensagem que o designer envia para os usuários têm como expressão a interface de usuário e como conteúdo a funcionalidade e o modelo de interação definidos pelo programa que implementa o sistema [Peirce 31]. O interpretante deste signo é, para o usuário, o modelo conceitual que ele adquire a partir da interpretação da interface - que é a expressão do sistema - durante o processo de interação. Por exemplo, o usuário, quando observa um widget na interface, precisa saber como pode utilizá-lo e qual será o comportamento do sistema após a sua ação. O que está sendo interpretado pelo usuário, mesmo sem perceber, é o que o designer quis dizer sobre aquele widget. A interpretação que a Engenharia Semiótica oferece para este processo é a de que a interface está transmitindo uma mensagem para o usuário, do tipo Eis aqui um botão. Aperte-o e ele realizará tal operação. A interface, isto é, os diversos elementos que a formam (mouse, teclado, widgets, menus, caixas de diálogo, instruções, avisos, comandos, etc) é, pois, uma mensagem formada por outras mensagens. A abordagem da engenharia semiótica nos mostra que as perspectivas do designer e do usuário podem ser aproximadas pela utilização de signos de interfaces que gerem as mesmas interpretações. Neste processo comunicativo é preciso formular o conteúdo e gerar a expressão que permita ao designer interpretar o mesmo conteúdo. Neste caso é preciso que o designer especifique o modelo conceitual da aplicação e que possa mapeá-lo em signos de interface. Neste caso temos uma correlação semântica entre expressão e conteúdo, no qual signos de interface têm como significado elementos do modelo conceitual. O modelo conceitual da aplicação funciona como uma representação da semântica do software. 6. Um framework para o design de software Com base na fundamentação teórica discutida anteriormente e na abordagem proposta pela Engenharia Semiótica vamos apresentar um framework conceitual para o design de software. Neste framework diferenciamos a visão do usuário da visão do programador, de acordo com o que foi discutido na seção 3 e mostramos como a abordagem da engenharia semiótica pode ser posta em prática. De acordo com a abordagem da Engenharia Semiótica, o design do software é um processo comunicativo, no qual o designer envia uma mensagem para o usuário cuja expressão é a interface de usuário. Neste processo ambos devem compartilhar o mesmo conteúdo que é o modelo conceitual da aplicação. Assim, designer e usuário compartilham a mesma perspectiva do software. O modelo conceitual funciona como elemento que une as perspectivas do usuário e do designer e serve de base para a implementação computacional do sistema. A seguir vamos mostrar como o design do software requer a especificação de signos que atendam as diferentes perspectivas.

6.1 O processo de design Na abordagem da Engenharia Semiótica, o design e a prototipação da interface de usuário devem ser vistos como a produção de uma mensagem num processo iterativo que deve ser complementado por um processo de avaliação. A produção da mensagem deve ser conduzida em três etapas: a formulação do conteúdo, a especificação abstrata da mensagem e a elaboração da expressão da mensagem do designer para o usuário. A elaboração da expressão é feita através da construção do protótipo. Na primeira destas etapas, a formulação do conteúdo, deve-se conceber e especificar os componentes do modelo conceitual da aplicação. Deve-se especificar os signos conceituais que representam os objetos e as funções da aplicação e os comandos de função. Na segunda etapa, o designer precisa complementar esta especificação considerando que estes componentes são parte do processo comunicativo existente entre o designer e o usuário. Ele deve realizar a especificação de cada componente do modelo conceitual como parte da mensagem global que é enviada ao usuário. Na terceira e última etapa a expressão da mensagem deve ser concebida e especificada para que possa ser apresentada ao usuário durante o processo de interação. Os signos de interface possuem características de interatividade e podem ser acionados pelos usuários através da ferramenta de acionamento. Os signos têm como expressão preferencial os widgets disponíveis na maioria das ferramentas de interfaces. Seus significados (conteúdo da mensagem) são os elementos do modelo conceitual da aplicação. Isto significa que o design da interface de usuário deve estar associado semanticamente com a especificação deste modelo. 6.2 Os signos da aplicação O framework para o design prevê a representação de objetos da aplicação de três formas distintas de acordo com as diferentes perspectivas. Na perspectiva do usuário os objetos da aplicação estão representados como signos de interface, codificados através de elementos gráficos como os ícones e os widgets de interface. A interface de usuário é composta por signos de interface. Na perspectiva do programador os objetos da aplicação estão representados como signos computacionais, codificados em linguagens de programação. O programa é, portanto, formado pelo conjunto de signos computacionais que implementam a aplicação e descrevem o seu funcionamento. Na perspectiva conceitual os objetos da aplicação estão representados através de signos conceituais que são diagramas de representação que permitem descrever cada um dos objetos da aplicação, suas propriedades e relacionamentos de maneira abstrata. A visão conceitual permite uma visão lógica da aplicação independente da linguagem na qual ela será programa ou do estilo de interface que será utilizado. O conjunto de signos conceituais forma o modelo conceitual da aplicação. A figura 3 mostra estas diferentes visões. 6.3 Especificando o modelo conceitual da aplicação Nos sistemas computacionais interativos o modelo conceitual da aplicação é formado por alguns tipos de conceitos que são comuns a maioria deles. Evidentemente, é o designer quem deve determinar quais conceitos são úteis para a aplicação que ele está projetando. Vamos

utilizar alguns tipos pré-definidos de conceitos. Eles são os objetos da aplicação, as funções da aplicação e os comandos de função. Usuário Signos de Interface Designer Signos Conceituais Signos Computacionais Programador Figura 3: as diferentes perspectivas representadas por diferentes tipos de signos da aplicação Os objetos da aplicação são definidos em termos de propriedades e relacionamentos devem ser representados no sistema para que os usuários possam operar sobre eles. Estas operações - as funções da aplicação - permitem que os conceitos sejam criados, transformados, destruídos, etc. Os comandos de funções permitem ao usuário controlar a execução de uma função pelo computador. As funções da aplicação são responsáveis por operações com os objetos da aplicação. Elas devem determinar quais transformações ocorrem no sistema e quais são os conceitos que são modificados, criados ou destruídos. A funções modificam o estado do sistema. Uma determinada função da aplicação pode levar o sistema de um estado p de para um estado q. Os estado inicial que o sistema está antes que uma determinada função seja executado é também chamado de pré-condição. O estado final, isto é, após a função da aplicação ter sido executada é chamado de pós-condição. Na especificação do modelo conceitual não estamos interessados ainda em como eles vão ser representados computacionalmente, isto é, qual estrutura de dados será utilizada para representar o conceito numa linguagem de programação. Também não vamos representar ainda como o conceito será visto pelo usuário - se na forma de um ícone, de uma tabela, de uma lista, etc. Por enquanto estamos interessados em fazer uma especificação abstrata dos conceitos da aplicação. A execução de cada função da aplicação deve ser controlada por comandos de função. Este conceito refere-se ao conjunto de ações que o usuário deve desempenhar para que uma determinada função seja iniciada, interrompida ou cancelada, por exemplo. As ações que o usuário deve fazer são aquelas que ele desempenha com os dispositivos da interface de usuário, como pressionar tecla X, escrever um nome com o teclado, pressionar com o mouse, mover com o mouse, etc. Existem diferentes formas de interação que determinam comandos de função distintos. No MS DOS, os comandos são elaborados pela digitação de sentenças. Este estilo é chamado de linguagem de comando. No Windows 95/98, os comandos são desempenhados pelo acionamento de objetos da interface num estilo chamado de manipulação direta. A especificação do modelo conceitual pode ser descrita em linguagens diagramáticas como a Unified Modeling Language (UML) [Booch et al. 99].

6.4 Exemplificando com um cadastro de clientes Para exemplificarmos a aplicação do framework e as diferentes perspectivas do software vamos descrever os signos elaborados no design de parte de uma aplicação Sistema de Biblioteca. Vamos nos limitar à função de cadastrar cliente e consultar arquivo de clientes. Para permitir o cadastro de clientes da biblioteca, a aplicação deve possuir objetos como registro de clientes que contém informações sobre cada cliente. Cada registro de cliente é composto por dados para o nome, a matrícula e para informar se o cliente possui livros emprestados. Os registro de clientes são armazenados em um arquivo de cliente. Para que o usuário possa cadastrar as informações de cliente será necessário introduzir um objeto de interface que permita ao usuário fornecer os dados. Este objeto é o formulário de registro, que possui os objetos CampoNome, CampoMatricula, BotãoEmpréstimos, BotãoGravar e BotãoCancelar. Para que o usuário possa visualizar o arquivo de registro de clientes, o objeto tabela de registros é responsável pela sua representação Estes objetos estão representados de forma abstrata usando diagramas de classes UML. O diagrama representa também os relacionamentos entre elas, como mostrado na figura 4. Arquivo de usuários armazena 1 representa 1 Tabela de registros 0..* Registro de usuário 0..* representa Formulário de usuário 1 1 1 1 1 1 1 1 nome matricula livros emprestados Campo Botão Nome emprestimo Campo Botão Matricula gravar Botão cancelar Figura 4: Signos conceituais para a aplicação cadastrar cliente usando diagramas de classes UML O diagrama de classes permite uma visão abstrata e estática dos objetos da aplicação. Para visualizarmos o modelo de interação é preciso diagramas que possibilitam uma visão dinâmica. O diagrama de atividades é utilizado para descrever as atividades do usuário e do sistema durante o processo de cadastramento. O diagrama de atividades UML descrito na figura 5 é o elemento conceitual que descreve a funcionalidade e o modelo de interação desta função da aplicação cadastrar cliente.

Sistema Usuário Escolher cadastrar usuário exibir formulário de usuário Ler registro usuário do formulário Fornecer dados Pressionar gravar gravar registro na tabela apagar formulário de usuário Figura 5: Signos conceituais para a aplicação cadastrar cliente usando diagramas de atividades UML Os signos conceituais descrevem de forma abstrata os objetos que deverão ser percebidos pelo usuário do sistema através de signos de interface. A figura 6 mostra dois possíveis signos de interfaces associados aos objetos tabela de registro e formulário de registro e seus respectivos componentes. Os outros objetos como arquivos de clientes e registro e cliente são possuem signos de interfaces correspondentes uma vez que não são visualizados pelo usuário. Tabela de registro de clientes Nome Matrícula Empréstimos Adriana Silva 0023456 Sim Ana C Pereira 00298765 Não Formulário de registro de clientes Nome: Matrícula: Possui livros emprestados? Sim Não Gravar Cancelar Figura 6: Signos de Interface para a aplicação cadastrar cliente Para que a aplicação seja implementada, os signos conceituais e os signos de interface devem ser codificados como signos computacionais de uma linguagem de programação. Os objetos da aplicação Tabela de registros, Registro de cliente e Formulários de registro de cliente - descritos anteriormente na forma de signos conceituais e de interface podem ser descritos como estruturas de dados em uma linguagem de programação (estilo linguagem C), como mostra a figura 7.

Struct Tabela { Registro cliente; } TabelaRegistros[100]; Struct Registro { Char nome; Int matricula; Boolean empréstimos; } Struct Form { Textbox CampoNome; Numbox CampoMatricula; RadioButton Empréstimos; PushButton Gravar; PushButton Cancelar; } Formulário registro; Figura 7: Signos computacionais para a aplicação cadastrar cliente 7. Conclusão Este artigo mostrou um framework que descreve como incorporar a atividade de design no desenvolvimento de software de maneira a integrar as diferentes perspectivas que usuários, designers e programadores possuem em relação a uma aplicação. Discutimos com base em teoria semiótica que a perspectiva de programação é inadequada ao design, pois a interpretação obtida do código fonte do programa descreve o funcionamento da aplicação. Usuários interpretam a aplicação a partir de signos veiculados pela interface de usuário. Durante este processo de interação o usuário adquire o modelo conceitual da aplicação. Para que a atividade de design seja realizada adequadamente, designer e usuários precisam compartilhar modelos conceituais semelhantes. A Engenharia Semiótica é uma abordagem na qual o design é visto como um processo de produção de signos. Ela considera que o sistema computacional veicula uma mensagem através da interface, compostas por signos de interface, cujo conteúdo é o modelo conceitual da aplicação. Neste processo comunicativo o designer deve formular o modelo conceitual e expressa-lo através dos signos de interface. O framework apresentado neste trabalho mostra que o processo de produção de signos durante do design envolve a especificação dos signos conceituais que descrevem o modelo conceitual e dos signos de interface que serão vistos pelo usuário. Os signos de interface devem estar semanticamente relacionados com os primeiros uma vez que a interpretação do usuário deve convergir em torno do modelo conceitual pretendido pelo designer. Em [Leite 98] apresentamos uma Linguagem para Especificação da Mensagem do Designer (LEMD) que permite a descrição da interface de maneira abstrata como sendo uma mensagem enviada do designer para o usuário. Mostramos ainda como os elementos desta descrição podem ser mapeados em signos de interface disponíveis nas principais interfaces gráficas, como botões, caixa de texto, menus e vários outros. Atualmente estamos aplicando este método no re-design de uma aplicação de software para telemarketing. Vamos comparar esta versão com a já existente através de testes de usabilidade com o objetivo de avaliar as vantagens de nosso framework. Nosso próximo objetivo é desenvolver uma ferramenta de apoio ao design que permita ao designer integrar os diferentes signos conceituais, com signos de interface e signos computacionais. Esta ferramenta inclui ainda recursos para a construção de modelos de tarefas e cenários de uso. 8. Referências Booch, G.; Rumbaugh, J. & Jacobson, I. The Unified Modeling Language, Addison-Wesley, 1999.

De Souza, C.S. The Semiotic Engineering of User Interface Languages. International Journal of Man-Machine Studies 39. Academic Press. 1993. pp. 753-773. Eco, U. A Theory of Semiotics. Bloomington, IN. Indiana University Press. 1976. Edição brasileira: Tratado Geral de Semiótica, coleção estudos 73, ed. Perspectiva, 2a. Edição, São Paulo 1991. Leite, J. Modelos e Formalismos para a Engenharia Semiótica de Interfaces de Usuário. Tese de doutorado, Pontifícia Universidade Católica do Rio de Janeiro, 1998. Liddle D. Design of the Conceptual Model in Winograd, T. (Ed.) Bringing Design to Software. Addison-Wesley, 1996. Meyer B. A Theory of Programming Languages. Prentice-Hall, 1986. Peirce, C.S. 31-58. Collected Papers (1931-1958). Edição brasileira: Semiótica. São Paulo, Ed. Perspectiva (coleção estudo, n.46) 1977. Winograd, T. (Ed.) Bringing Design to Software. Addison-Wesley, 1996.