Monografia - Ciência da Computação - UFCG

Universidade Federal de Campina Grande
Centro de Engenharia Elétrica e Informática
Curso de Ciência da Computação

Dalton Cézane Gomes Valadares
Diego Renato dos Santos
Thiago Gondim Ribeiro
WUT2S (Web Usability Test Task Scheduler)
Ferramenta web para realização de testes de usabilidade

Campina Grande
2007

Dalton Cézane Gomes Valadares
Diego Renato dos Santos
Thiago Gondim Ribeiro

WUT2S (Web Usability Test Task Scheduler)
Ferramenta web para realização de testes de usabilidade

Monografia apresentada ao Curso de
Ciência da Computação da UFCG, como
requisito para a obtenção parcial do grau
de BACHAREL em Ciência da
Computação.

Orientador: Jacques Philippe Sauvé
Doutor em Engenharia Elétrica - University of Waterloo

Campina Grande
2007

Introdução

O WUT2S (Web Usability Test Task Scheduler) surgiu da necessidade de
informatização do processo de realização de testes de usabilidade do Laboratório
de Interface Homem-Máquina (LIHM) do Parque Tecnológico da Paraíba
(PaqTc-Pb).
Um teste de usabilidade, no contexto da computação, é um método para
verificar a facilidade de uso de uma interface para os seus usuários finais.
Possíveis usuários do produto a ser testado devem utilizar o mesmo em um
ambiente monitorado. As ações desses usuários, ao utilizarem o produto, são
gravadas e anotadas para depois serem analisadas por um avaliador. Os testes
seguem um roteiro que possuem várias tarefas a serem executadas no produto
(através das interfaces do mesmo). Os usuários são instruídos para se sentirem à
vontade em relação ao produto testado: devem falar ou expressar qualquer
desconforto que venham a sentir. Após a análise dos resultados obtidos durante
o teste, algumas recomendações são geradas em relação a possíveis problemas
encontrados nas interfaces do produto.
O Laboratório de Interface Homem-Máquina, do PaqTc-Pb, presta
serviços de projeto e avaliação caracterizados por uma série de atividades
voltadas para uma integração mais efetiva da Universidade com o setor
empresarial, em especial com a indústria. Dessa forma, tem oferecido às
organizações interessadas uma gama de serviços de consultoria a projetos,
iniciativas de implantação de tecnologias e/ou recomendações relativas a
tomadas de decisões quanto à estruturação/aperfeiçoamento de ambientes e
contextos de trabalho. Nesses serviços estão incluídos os testes de usabilidade
para avaliação de produtos (sistemas desktop, sistemas web ou aplicações
móveis).
O projeto é um sistema web para informatizar o trabalho de obtenção de
informação a respeito de testes relacionados com a área de Interface Homem-

Máquina. Os testes de usabilidade são realizados para se ter uma idéia do grau
de satisfação do usuário ao utilizar o produto (software) testado.
Todos os testes, atualmente, são realizados de forma manual, o que faz
com que o processo de colheita de dados, resultantes da observação dos testes, e
a análise dos mesmos demandem um pouco mais de trabalho e de tempo, se
comparado ao mesmo processo estando informatizado, já que grande parte da
informação fica armazenada no computador, ao invés de vários papéis com
formulários preenchidos, observações e outros dados relevantes à análise da
ferramenta testada.
Os testes de usabilidade são realizados por pessoas que provavelmente
utilizarão o produto em questão, ou que apresentam um perfil semelhante, e são
observados por alguns avaliadores. Os avaliadores observam todo o
comportamento do usuário que está testando o produto e registram tudo o que
acontece durante o teste, como: número de erros do usuário para executar
determinada tarefa com o produto, tempo que o usuário leva para realizar todo o
roteiro de teste, etc. Toda a informação obtida dos testes fica registrada em
papéis que contêm formulários. Ao término de várias sessões de testes, cada
avaliador tem uma grande quantidade de formulários que devem ser
armazenados para depois serem analisados.
Pode-se entender como problema a grande quantidade de informação a ser
tratada “manualmente” e armazenada em vários arquivos físicos (vários
formulários - como já citados -, notas de observação, etc.). Esse problema vem a
ser solucionado com a construção do sistema web, pois este passa a armazenar
toda a informação no computador, automatizando grande parte do processo de
acompanhamento de testes de usabilidade realizados no LIHM do PacTc.
O sistema permite cadastrar e consultar usuários, produtos, tarefas e
outras “entidades” envolvidas em um teste de usabilidade, bem como
acompanhar todo o teste, registrando as informações de maior relevância
observadas durante a execução deste.

Para construção do sistema foi utilizada a linguagem ASP .NET que faz
parte do framework .NET 2.0 da Microsoft. A parte lógica foi desenvolvida na
linguagem C#, também utilizando o .NET 2.0. Para o desenvolvimento o
ambiente utilizado foi o Visual Studio 2005, também da Microsoft, e a
persistência de dados é feita através do sistema de banco de dados MySQL.
Algumas funcionalidades apresentadas na interface web foram desenvolvidas
em JavaScript utilizando AJAX.
O documento se encontra divido em cinco seções: na primeira é
apresentado o contexto do projeto, citando, por exemplo, o perfil dos usuários e
o ambiente de execução; na segunda seção, a fundamentação teórica é abordada,
mostrando os principais conceitos e métodos utilizados no desenvolvimento do
projeto; a terceira seção descreve a metodologia aplicada durante todo o projeto,
com os processos e as ferramentas utilizadas; a penúltima seção apresenta os
resultados obtidos com o projeto, desde o início do desenvolvimento até a
conclusão do mesmo; e, por fim, a última seção é uma conclusão sobre tudo que
foi obtido, envolvendo nível de satisfação do cliente, possíveis dificuldades
encontradas, etc.

Contexto do Projeto

Eustáquio Rangel, doutor em Engenharia Elétrica pela Universidade Federal da
Paraíba – UFPB, é avaliador no Laboratório de Interface Homem-Máquina –
LIHM, localizado no Parque Tecnológico da Paraíba. Entre as atividades
comuns, está a realização de baterias de testes (convencionais) de usabilidade.
Nesses testes de usabilidade, indivíduos que representam uma classe de
usuários em potencial de um determinado produto (comumente software)
possam experimentar a sua utilização. O grau de facilidade com que esses
usuários de teste conseguem lidar com o produto é um indicativo da qualidade
de sua interface. Para que os resultados possam ser representativos para a
precisão da avaliação, é necessária a realização do mesmo teste com uma
quantidade mínima de usuários, e em cada teste é necessária a coleta de
informações relacionadas ao tempo (duração, freqüência de determinados
eventos, etc.), assim como em relação ao “espaço”, por exemplo a posição da
tela onde o usuário tem maior dificuldade de encontrar algum controle, etc.
Esses testes comumente geram um volume elevado de dados coletados,
inclusive para uma quantidade pequena de testes. O modo tradicional de coleta
desses dados é através de filmagem, mas também através de forma manuscrita.
Não é incomum situações em que o mesmo avaliador era responsável por
manusear mais de um cronômetro convencional, formulário em papel, e ainda
ter necessidade de utilizar o microfone para se comunicar com o usuário de
teste.
Para diminuir os riscos de perda de informação, há a necessidade de uma
ferramenta integrada para aumentar a produtividade do avaliador em sua
operação de coleta de dados. A forma mais desejável era através de um sistema
computacional.
De preferência, o sistema deveria ser executado através do browser,
através da web, devido a diversos motivos:

• possibilidade de essa aplicação poder ser utilizada em ambientes
distintos do LIHM;
• não haver necessidade de instalação em diversas máquinas,
bastando ser instalado em uma quantidade inferior de servidores;
• possibilidade do compartilhamento de informações em localidades
distantes geograficamente.
Apesar de o sistema desejado ter de ser via web, ele não poderia ser
significativamente lento, pois quanto maior a diferença de tempo entre um
evento observado e seu registro, menos precisos são os resultados que serão
avaliados após o teste. O cliente, em experiências semelhantes com equipes
anteriores, recomendou fortemente evitar a utilização de JSP (Java Server
Pages), se essa tecnologia causasse perda de desempenho em relação ao termpo
de resposta.
Uma restrição inerente de o sistema executar através da web é a
impossiblidade da garantia de interação do sistema de coleta através de
processos em execução na máquina do usuário de teste, como por exemplo aviso
de que o tempo previsto para uma tarefa foi encerrado.
Além disso, também há o interesse de essa ferramenta servir como uma
agenda de atividades, para uso no LIHM e em outras instituições que não
necessariamente realizem testes de usabilidade.
Outra característica dispensável, porém atrativa era o desenvolvimento da
ferramenta por alunos da Universidade Federal de Campina Grande, devido ao
histórico de cooperação entre essa instituição e o Parque Tecnológico,
fomentando a atuação de alunos em diversos problemas, incentivando o
desenvolvimento do seu conhecimento na realização de sistemas utilizáveis em
situações reais.
Por essas características, o problema de construir a ferramenta de
execução de testes de usabilidade foi disponibilizada no rol de alternativas para
a disciplina de Projeto 1 e, por conseguinte, Projeto 2, sendo conduzida por:

• Eustáquio Rangel, como cliente;
• Dalton Cézane Gomes Valadares, Diego Renato dos Santos e Thiago
Gondim Ribeiro, como desenvolvedores;
• Francilene Garcia, como professora da disciplina Projeto 1;
• Jacques Sauvé, como professor da disciplina Projeto 2.

Ferramentas semelhantes

Existem outras ferramentas de software que serve para acompanhar a
realização de testes de usabilidade. O Usability Test Data Logger é um software
baseado em macros do Microsoft Excel que permite a execução de todo o cliclo
dos testes de usabilidade, desde o planejamento e a realização, até a síntese de
dados. É inegável que ele possui características úteis para a os testes do LIHM,
porém não é adaptável a um sistema distribuído através da rede, além de não é
bastante flexível para se adaptar ao processo de realização de testes adotado pelo
LIHM.

Uma das telas do Usability Datalogger

A empresa TechSmith também desenvolve ferramentas para a realização
de testes de usabilidade, chamadas de Morae (modo standalone) e UserVue
(web). Porém, ambas não são gratuitas, contrariando a prioridade por
ferramentas não-proprietárias no LIHM. O mesmo vale para a UTE, um sistema
para o mesmo fim, produzida pela MindDesign Systems.
Em relação às operações de cadastro de atividades, estilo agenda, foi
utilizada como referência a ferramenta TaskTimer. Ela permite o gerenciamento
de atividades por categoria, relevância, além de ter um banco de dados integrado
para o intercâmbio de informações entre os diversos usuários do sistema.
Adicionalmente, ainda há a funcionalidade de integrar essas informações na
forma de projeto, e assim avaliar o desempenho de funcionários através do

cumprimento de metas. Infelizmente, a ferramenta também é proprietária,
permitindo seu uso gratuito apenas para uma quantidade finita de vezes.
Atuando em campos semelhantes na área de avaliação de interface
homem-máquina, há outras ferramentas desenvolvidas por alunos da
Universidade Federal de Campina Grande,:
O WebQuest, que também é uma ferramenta acessível pela web
responsável pela obtenção de dados subjetivos sobre a percepção de um usuário
de teste sobre o produto a ser testado. Com o auxílio do WebQuest, é possível se
traçar um perfil de usuário e na sondagem da satisfação subjetiva de usuários de
sistemas interativos.
O Fermint também é outra ferramenta que facilita é útil como um aliado
da realização de testes de usabilidade. O Fermint permite se avaliar diretamente
as possíveis falhas existentes em interfaces do produto-alvo, tal como um
software. Associada ao WUT2S, pode auxiliar o planejamento do roteiro de teste.

Fundamentação Teórica

Plataforma .NET

Utilizamos a plataforma .NET, a qual oferece uma alternativa de ambiente para
produzir aplicações Windows e Web, executando-as nos mais diversos
dispositivos (PCs, Palms, telefones celulares, etc). A Microsoft torna a infra-
estrutura de suporte ao .NET amplamente disponível. O framework de suporte
pode ser baixado e instalado livremente.

O framework .NET

O framework .NET, base da plataforma .NET, é uma plataforma de programação
para desenvolvimento de aplicações essencialmente composto de duas partes:

· Uma engine de execução chamada CLR;

· Uma biblioteca de classes que disponibiliza as principais funções de
programação.

O código das aplicações .NET é compilado para MSIL (Microsoft Intermediate
Language) e é armazenado em um arquivo chamado assembly. Em tempo de
execução, o assembly é compilado para o seu estado final pela CLR. Enquanto
está ativa, a CLR proporciona checagem de tipo (type-safety checks) e outras
tarefas de run-time.

Aplicações que rodam sob o CLR são chamadas aplicações de código
gerenciado porque o CLR responsabiliza-se por tarefas que normalmente seriam
de responsabilidade da aplicação. O assembly possui todas as informações de

que o CLR precisa para rodar a aplicação. O CLR cuida dinamicamente do
registro de componentes

Introdução ao ASP.NET

O ASP.NET é uma parte importante do framework .NET, mas trata-se
simplesmente de uma parte. Faz-se necessário entender o restante do framework.

Usa-se o ASP.NET para criar aplicações Web e Web Services que rodam sob o
IIS (Internet Information Services). O que torna o ASP.NET especial é o fato
dele ser fortemente integrado com ferramentas de programação, acesso à dados e
segurança.

O ASP.NET proporciona um alto nível de consistência no desenvolvimento de
aplicações. Como já ressaltado, O ASP.NET, como já dito, é parte do framework
.NET e composto de diferentes componentes:

· Visual Studio .NET Web Development tools. Inclui ferramentas visuais para
desenvolvimento de páginas Web, templates de aplicação e ferramentas de
deployment;

Oferece tudo o que é preciso para qualquer tipo de aplicação para Web, seja
Design, código, componente, Web Service, camada de aplicação ou negócio;

Incorpora nativamente diversas linguagens de programação, tais como: Visual
Basic, Visual C++, J#, Cobol (inclusive) e C# (a qual usamos ao longo do
desenvolvimento deste projeto).

· System.Web namespaces. Fazem parte do frameWork .NET e incluem classes
que tratam ítens específicos do mundo Web, tais como requisições HTTP,
respostas (responses), browsers e e-mail;

Organizada em namespaces, sua biblioteca de classes fornece acesso a todas as
funcionalidades da CLR . Cada namespace contém um grupo de classes
relacionadas. A tabela abaixo sintetiza os namespaces de maior interesse aos
programadores Web.

Categori
Namespaces Utilização
a

Todos os tipos
comuns de
dados,
incluindo
strings, arrays
e tipos
númericos.
Estas classes
incluem
Tipos métodos para
System
Comuns conversão de
tipos,
manipulação
de strings e
arrays,
funções
matemáticas e
geração
aleatória de
números.

Acesso à System.Data, Estas classes

Dados System.Data.Common, incluem
System.Data.OleDb, métodos de
System.Data.SqlClient, conxão à
System.Data.SqlTypes bancos de
dados,
execução de
comandos,
recuperação e
modificação
de dados.

Classe para
Debuggin
System.Diagnostics Debugging e
g
tracing.

Métodos para
acesso so
sistema de
arquivos.
Incluem
System.IO,
Acesso ao métodos de
System.IO.IsolatedStor
Sistema leitura e
age,
de escrita de
System.DirectoryServic
Arquivos arquivos e
es
outras
operações
sobre o
sistema de
arquivos.

Comunicação
através da
internet
utilizando
protocolos de
baixo nível,
System.Net, tais como
Rede
System.Net.Sockets TCP/IP. Estas
classes são
utilizadas para
criação de
aplicações
ponto-a-ponto
(peer-to-peer).

System.Security,
System.Security.Crypto Autenticação e
graphy, autorização de
Seguranç
System.Security.Permis usuários além
a
sions, de encriptação
System.Security.Policy, de dados.
System.Web.Security

System.Web, Classes para
System.Web.Caching, criação e
System.Web.Configurat publicação de
Aplicaçõe
ion, componentes
s WEB
System.Web.Hosting, que podem ser
System.Web.Mail, acessados
System.Web.SessionSta através da

te, System.Web.UI, internet. São
System.Web.UI.Design, as principais
System.Web.UI.WebCo classes
ntrols, utilizadas para
System.Web.UI.HtmlC a criação de
ontrols Web Services
ASP.NET.

System.Windows.Form Classes para
Aplicaçõe
s, criação de
s
System.Windows.Form aplicações
Windows
s.Design Windows.

System.Xml,
Criação e
System.Xml.Schema,
acesso a
XML System.Xml.Serializati
arquivos
on, System.Xml.Xpath,
XML.
System.Xml.Xsl

· Server Controls e HTML Controls . São componentes visuais utilizados para
obter informações e proporcionar respostas aos usuários da aplicação.

Adicionalmente, O ASP.NET também utiliza componentes de programação mais
gerais. Eles não fazem parte do ASP.NET mas são ítens chave para a sua
utilização:

· Microsoft Internet Information Services (IIS). Hospeda as aplicações Web.
Todo o processamento é feito no servidor, onde encontra-se o Internet
Information Server (IIS)

· Visual Basic.NET, linguagens de programação Jscript e C# (a qual usamos
ao longo do desenvolvimento do projeto). Estas três linguagens têm suporte
integrado no Visual Studio.NET.

· FrameWork .NET. É um conjunto completo de classes. Elas incluem classes
ASP.NET, propriamente ditas, bem como outras classes de acesso a arquivos,
conversão de tipos, manipulação de arrays e strings e assim por diante

· ADO.NET. Este componente fornece acesso ao Microsoft SQL Server e outros
bancos de dados acessados via ODBC.

· Microsoft Application Center Test (ACT) . Este componente do Visual
Studio.NET fornece um meio automatizado para fazer testes de stress com a
aplicação.

Ferramentas adicionais

No ASP .NET, mais especificamente no Visual Studio .NET, contamos
com o Server Explorer e com o Solution Explorer.

- Server Explorer: excelente recurso, com o qual pode-se verificar todos
os recursos existentes no computador. Com ele, pode-se, inclusive, criar banco
de dados, tabelas, consultas, funções e Stored Procedures, e até, fazer a
nanutenção de todos os registros de uma tabela. Utilizando-se de qualquer BD
disponível.

- Solution Explorer: ferramenta que permite administrar todos os arquivos
contidos na solução.

OOP

A programação Orientada a Objetos (OOP) é padrão em todas as
linguagens .NET e permite desenvolvimento estruturado, reaproveitamento de
códigos, rotinas, classes e objetos.

Deployment

O processo de distribuição (Deploy) de uma aplicação ASP .NET é
simples: copia-se os arquivos necessários para o servidor e cria-se o diretório
virtual.

Provedores

Faz-se necessário ter Windows 2000 ou superior e, o Framework instalado.

Onde rodar

Em qualquer navegador, independentemente de fabricante ou versão

Principais pontos envolvidos no processo de compilação de uma aplicação
ASP.NET 2.0:

Modelo de Código no ASP.NET 2.0

O ASP.NET 2.0 suporta dois modelos de código, code-inline e code-behind.

Com relação ao modelo code-behind, no ASP.NET 2.0 o arquivo de código é
uma implementação “parcial”. O arquivo code-behind segue o novo modelo de

Partial Class. As classes parciais contém todo código implementado pelo
desenvolvedor e omite o código gerado automaticamente pelo Visual Studio.
Quando uma página ASPX com o novo modelo de code-behind é chamada, o
ASP.NET 2.0 combina o arquivo ASPX (a qual contém a interface gráfica) e a
classe parcial numa única classe ao invés de duas classes separadas.
As classes parciais usam uma palavra-chave (Partial no C#) para indicar que o
código nesta classe deve ser mesclado com outra classe quando em modo
runtime. De maneira semelhante o arquivo ASPX utiliza uma diretiva
CompileWith para indicar o arquivo de código associado.

O modelo de herança é simplificado porque o arquivo de código (code-behind)
não precisa conter as definições dos controles da página ASPX. Desta forma, o
arquivo de código pode acessar automaticamente qualquer controle na página
sem a necessidade de código declarativo. Isto é possível porque o Runtime do
ASP.NET 2.0 insere automaticamente as declarações exigidas para os controles
e eventos no arquivo compilado ao final do processo, desta forma o
desenvolvedor não precisa preocupar-se com isso.

Com esse novo modelo, o arquivo de código e a página ASPX são mesclados e
compilados numa única e completa classe em runtime eliminando a
complexidade do processo de compilação. A sincronização entre o arquivo de
código e o arquivo ASPX é automática, mas ainda assim é possível que o código
seja alterado no arquivo ASPX e não atualizado no arquivo de código, contudo o
desenvolvedor poderá localizar o problema de forma muito mais rápida uma vez
que o ASP.NET 2.0 gerará uma Exception muito mais detalhada.

Modelos de compilação no ASP.NET 2.0
O ASP.NET 2.0 suporta diferentes modelos de compilação para uma aplicação

Web, apresentados abaixo:

Default: (ASP.NET 1.x)
Neste modelo de compilação, os arquivos de código são compilados num
assembly e armazenados na pasta /bin da aplicação. As páginas ASPX são
compiladas por demanda. Este modelo funciona bem para a maioria dos
websites. Contudo, este processo de compilação torna a primeira requisição de
qualquer página da aplicação mais lenta do que as requisições subsequentes.

Não existe nenhum procedimento manual para realizar a compilação default. O
Runtime do ASP.NET 2.0 se encarregará de realizar a compilação quando
receber a primeira requisição para a aplicação. Se alguma alteração for feita, no
próximo request da página alterada, o Runtime do ASP.NET 2.0 determinará as
dependências do arquivo alterado e realizará a compilação apenas para os
arquivos envolvidos na alteração.

Vantagens:
· Simples, pois o Runtime do ASP.NET faz todo o trabalho para você.
· É a melhor opção para a fase de desenvolvimento da sua aplicação
Web, pois evita as etapas necessárias para realizar pré-compilações.

In-Place Compilation (Pré-Compilação no Servidor de Produção)
Pode-se usar a ferramenta ASP.NET Compilation Tool (Aspnet_compiler.exe),
localizada na pasta C:WINDOWSMicrosoft.NETFrameworkv2.0.50727,
para pré-compilar aplicação. O processo é semelhante ao que ocorre em tempo
de execução. A ferramenta provoca vários requests para o website provocando a
compilação do mesmo. Se altera-se a página da aplicação, deve-se repetir o
processo de pré-compilação, caso contrário o Runtime do ASP.NET 2.0 terá que

fazer a compilação em tempo de execução na próxima requisição do arquivo
alterado.

Vantagens:
· Tmpo de resposta para o primeiro request da aplicação é reduzido.
· Não é necessário executar nenhum procedimento especial para o
deployment após a compilação.

Deve-se usar esse modelo quando houver necessidade de frequentes alterações
nas páginas e/ou quando quiser reduzir o tempo de resposta do primeiro request,
mas deve-se lembrar que os arquivos de código estarão disponíveis para todos
que tiverem acesso à pasta da aplicação.

Deployment Pre-Compilation
Este modelo inserido no ASP.NET 2.0 permite ao desenvolvedor fazer a
compilação completa da sua solução antes de fazer o deployment. Com a
compilação completa, todos os arquivos code-behind, páginas ASPX, HTML,
recursos gráficos, são compilados em um ou mais assemblies, dependendo do
tamanho da aplicação e da configuração da compilação. Os assemblies contém o
Website completo, com exceção do arquivo Web.config. Este modelo de
compilação oferece a melhor performance e segurança se comparado com os
outros modelos, porém remove a capacidade de qualquer alteração no Website
após feito o deployment. Se trabalha-se em um website altamente visado, ou que
exige alto nível de segurança, este modelo é a melhor opção para o deployment
final. Contudo, se desenvolve-se um pequeno website, trabalhando numa
intranet local, e o projeto requer frequentes mudanças, este modelo de
compilação porde tornar-se inviável.

Pre-Compilation com camada de apresentação atualizável
Com a utilização do parâmetro –u da ferramenta ASP.NET Compilation, o
desenvolvedor pode pré-compilar os arquivos de código (*.vb ou *.cs) e os
arquivos de recursos (*.resource), deixando o código da camada de
apresentação (HTML) disponível para atualizações. Depois de realizar o
deployment do website no servidor de produção, os arquivos ASPX podem ser
modificados sem a necessidade de recompilar a aplicação.

Vantagens:
· Tempo de resposta para o primeiro request da aplicação é reduzido.
· Os designers podem modificar a aparência do Website sem
necessidade de recompilar a aplicação.
· A propriedade intelectual é protegida pois os arquivos de código ficam
disponíveis neste modelo de compilação.

Pre-Compilation com camada de apresentação não atualizável
A ferramenta ASP.NET Compilation pode compilar todo código-fonte de uma
aplicação, incluindo os arquivos de interface (ASPX, ASCX), encapsulando-os
em assemblies que são publicados na pasta /bin da aplicação.

Vantagens:
· Tempo de resposta para o primeiro request da aplicação é reduzido.
· A propriedade intelectual é completamente protegida pois todos os
arquivos de código-fonte e arquivos de apresentação são compilados em
*.dlls.

Metodologia

Este capítulo visa apresentar a metodologia usada. Como a equipe de
desenvolvimento trabalhou para o desenvolvimento do projeto, quais e como foi
o processo de desenvolvimento, como foram feitos o controle de versão, o
ambiente de desenvolvimento, a comunicação com o cliente e entre os membros
desenvolvedores, etc. E por fim, é apresentado comentários relevantes.

Durante o desenvolvimento do projeto, correspondente à disciplina
Projeto1 e Projeto2, o processo de desenvolvimento utilizado foi o XP1. A
seguir, uma descrição do processo seguido:

Definições

- Iteração

É a unidade de planejamento detalhado, durando, em XP1, duas semanas.
O
escopo é variável, sendo definido na fase de planejamento.
- Release

É a liberação e instalação de uma versão do software para avaliação do
cliente.
Um release em XP1 é composto de iterações, preferencialmente poucas,
entre 2
e 5.

Atividades

As atividades realizadas em XP1 podem ser brevemente descritas da
seguinte maneira:

- Planejamento: abrange a escrita de User Stories (funcionalidades),
levantamento de requisitos não funcionais, planejamento de releases e de
iteração;

- Projeto: se divide em projeto arquitetural e refatoramento constante;

- Testes: inclui a elaboração de testes de aceitação e de unidade, assegurando
que o software se comporta de maneira desejada a cada situação testada;

- Integração: quando se utiliza o controle de versão, garantindo que o software
com o qual o programador vai trabalhar está em sua versão mais atualizada.
Assegura-se isto fazendo check-out (adquirir a versão mais atualizada do projeto
para desenvolver uma tarefa) antes de iniciar o desenvolvimento e fazendo
check-in (atualizar o projeto, acoplando a tarefa que acabou de ser desenvolvida)
ao finalizar o desenvolvimento;

- Acompanhamento: atividade que assegura a manutenção do progresso do
projeto,
sendo desempenhada pelo gerente.

Gestão do Código

Durante todo o período de desenvolvimento do projeto, o código foi
compartilhado entre seus desenvolvedores. No planejamento, cada

funcionalidade tornava-se responsabilidade

de um desenvolvedor especíco, porém com o compartilhamento do código
incentivado, de forma que todos os desenvolvedores poderiam ajudar em
qualquer parte implementada, mesmo que não fosse, à priori, de sua
responsabilidade.

Para tanto, manteve-se o código atualizado em uma base de dados segura,
um repositório de código-fonte de fácil acesso. No nosso caso, à princípio,
tentamos o Concurrent Versions System (CVS) do www.cvsdude.com, porém
obtivemos problemas de configuração e migramos para o “Subversion” (sistema
de controle de versão, também conhecido svn ou SVN, desenhado
especificamente para ser um substituto moderno do CVS, que se considera ter
alguns defeitos) do GoogleCode.

Ambiente de Desenvolvimento

O ambiente de desenvolvimento escolhido foi o VisualStudio.NET. Os
desenvolvedores do projeto o escolheram, pois além de sua familiaridade, o
VisualStudio .NET também é uma ferramenta poderosa, de fácil utilização, alta
portabilidade, muito flexível para utilização de plugins e uma das mais
completas IDE´s da atualidade. Possui integração com o banco de dados
escolhidos (MySQL), Nunit e todas as demais ferramentas por nós utilizadas.

Para testes, usamos o NUnit e o EasyAcceptToNUnit. O primeiro como
um framework para confecção de testes automáticos de software e, o segundo,
como uma ferramenta para automatizar testas de aceitação para projetos em
.NET. Ambos de fundamental importância para o êxito do projeto por facilitar a

implementação e execução dos testes de software, tornando um processo leve e
de fácil aceitação.

Comunicação

A comunicação, como em todas as áreas, é parte vital para o sucesso de
um projeto.
Na primeira metade do projeto, não havia reuniões presenciais mas, virtuais.
Estas se davam através de correio eletrônico e mensageiros instantâneos.
Pessoalmente, discutíamos antes e após as reuniões semanais com o cliente.

Porém, percebeu-se a importância e necessidade de reuniões presenciais e,
semanalmente, aos sábados, passamos a nos reunir, durante praticamente toda a
tarde. Na reunião discutíamos questões pendentes e trabalhávamos
conjuntamente no código propriamente dito.

É importante ressaltar que a comunicação virtual continuou existindo ao
longo de todo o processo e que dávamos continuidade ao código
individualmente, em nossos domicílios.

Todos estavam livres para tirar qualquer dúvida sobre a implementação
com os outros integrantes e/ou com o próprio cliente. O qual demonstrou grande
disponibilidade e prestatividade para esclarecer eventuais questões. Muitas
dúvidas, quanto ao projeto como um todo, foram clarificadas durante as reuniões
semanais com o mesmo. Reuniões tais que foram de indubitável importância,
chegando a durar aproximadamente 1 hora, se necessário.
Desta maneira, o cliente estava sempre como um membro da equipe de
desenvolvimento, acompanhando de perto cada passo e validando as

funcionalidades recém-implementadas por meio de demonstrações por parte dos
desenvolvedores. Com isto, a qualquer momento da implementação do projeto,
o cliente tinha noção do nível de progresso que estava havendo.

Outro fator positivo quanto ao cliente foi que este era da área de
computação e,
conseqüentemente, sabia explicar (inclusive com termos técnicos) o que
desejava.
Portanto, suas especificações tinham maior chance de serem corretamente
interpretadas e executadas pelos desenvolvedores.

Responsabilidades

Os integrantes da equipe puderam desempenhar três papéis: cliente,
desenvolvedor ou gerente.

O cliente foi responsável por descrever as user stories (US), ou seja,
funcionalidades, os requisitos não-funcionais, os testes de aceitação, o plano de
releases e a distribuição das user stories por cada iteração, não podendo estimar
o tempo em que as user stories deveriam ser concluídas. O cliente também se
dispôs a tirar dúvidas dos desenvolvedores quando/se surgissem.

Os desenvolvedores, por sua vez, apoiaram o cliente na definição de user
stories e requisitos não-funcionais, elaboraram o projeto arquitetural e
estimaram o tempo de desenvolvimento das user stories durante o planejamento
de releases. Durante a fase do planejamento de iteração, dividiram as user stories
daquela iteração em tarefas, escolheram quais tarefas iriam desenvolver e
estimaram precisamente o tempo de desenvolvimento de cada tarefa. Também

desenvolveram o esquema lógico e testes de unidade para cada tarefa, sempre
fazendo integração.

Já o gerente foi responsável por cobrar o andamento do projeto, conduzir
as atividades de planejamento, descobrir riscos e traçar estratégias para lidar
com os mesmos.Cada um dos alunos foi gerente durante uma release e o gerente
acumulava também as responsabilidades de desenvolvedor.

Prazos de entrega

Em datas definidas pelas ministrantes das disciplinas, as equipes entregam
algum
resultado de seu trabalho. Existem três tipos de entrega:

- Apresentação de planejamento: devem-se entregar artefatos resultantes da
análise do sistema, ou seja, requisitos funcionais e não-funcionais, projeto
arquitetural e o planejamento de releases e iterações, distibuindo as
funcionalidades nas mesmas.

- Apresentação de iteração: artefatos de acompanhamento devem ser
apresentados, como big charts, tabela de cumprimento de atividades, etc;

- Apresentação de release: além dos artefatos mencionados acima, deve-se ter
uma versão do sistema disponível para apresentação à ministrante e ao cliente.

Demonstrações das Funcionalidades

Sempre que funcionalidades significativas eram implementadas, nós as
mostravam ao cliente durante as reuniões semanais.

Comentários

- A ferramenta EasyAcceptToNUnit foi uma adaptacao implementada
exclusivamente para este projeto. Já existia o EasyAccept, a qual tem a mesma
funcionalidade mas trabalha com a linguagem Java;

- Um dos integrantes (Thiago Gondim) não possuía familiaridade com a
linguagem e plataforma utilizadas, pois este projeto é uma continuidade do
projeto da disciplina LES (Laboratório de Engenharia de Software), do qual ele
não fazia parte. Este membro fazia parte de outro projeto porém decidiu mudar
para este por ter achado a proposta interessante e por desejar ampliar seus
horizontes, aprendendo algo como .NET

Resultados

O WUT2S é um sistema web que apresenta toda sua interface desenvolvida
em ASP .NET. Toda a lógica do sistema foi implementada na linguagem C#,
utilizando o Visual Studio como ambiente de desenvolvimento. Algumas
funcionalidades da interface foram desenvolvidas com JavaScript, utilizando a
biblioteca ASP .NET AJAX (antigo ATLAS).
A interface do sistema apresenta abas com o intuito de aproximar o uso
deste com o uso de determinados sistemas desktop. Menus são utilizados em
cada aba, seguindo um padrão para facilitar a utilização das funcionalidades do
sistema.
A escolha das linguagens se deu após se ter tomado conhecimento dos
servidores Windows que se encontram no LIHM e baseado em certa
familiaridade dos integrantes do projeto com as mesmas. Além disso, a escolha
dessa tecnologia de geração de páginas com conteúdo dinâmico (ASP .NET/C#)
se deve ao fato da mesma ser mais veloz que outras tecnologias (por exemplo,
JSP, ASP).

Por que ASP .NET?
Benefícios do ASP .NET:
• Código compilado não interpretado, com isso são evitados erros em
design-time e as aplicações rodam mais rápido.
• Melhor tratamento de erro através de controles de validação e blocos try-
catch.
• Controles desenvolvidos pelo usuário permitem maior reuso de código.
• Controles muito similares aos controles de Windows permitindo uma
maior facilidade do usuário.
• Habilidade de fazer cache de toda a página ou só de algumas partes dela
para aumentar o desempenho.

• Usa o conceito de code-behind que separa o código da lógica com a
apresentação.
• Recupera-se de memory leak e crashs.
• Uso de master pages que permitem definir um modelo de página
principal, onde todas as outras páginas podem seguir esse modelo.
• Uso de temas (pode-se usar também CSS) para definir o look-and-feel de
toda a página Web.
• Código totalmente OO sem preocupações com Scripts.
• Event-driven model em desenvolvimento Web.
• Suporte total aos padrões HTML 4.0, XHTML 1.0 e 1.1 e suporte
extensivo a CSS.
• Modelo de adaptive render onde os componentes detectam a cultura do
seu browser e a partir de então usam o padrão correto para seu browser,
suportando inclusive padrões HTML, WML, XHTML, e CHMTL; alguns
desses padrões para dispositivos móveis.
• Todos os controles possuem grande customização.

Benefícios para o usuário:
• A aplicação vai funcionar corretamente no seu browser.
• Experiência semelhante à de usar uma aplicação desktop graças aos
controles do ASP .NET.
• Maior velocidade de resposta graças à pré-compilação feita no servidor e
ao sistema de caching (podendo ser automático ou manual).
• Alguns controles:
o Controle de Log In:
o Facilita ao usuário a operação de Login; outros controles associados
a Login, como criação de novo usuário e recuperação de senha,
também estão presentes.

• File Upload: permite ao usuário fazer o upload de um arquivo.

• DataGridView: ideal para visualização de dados de um BD, operações de
CRUD como editar e remover podem ser realizadas no próprio controle.

• Menu semelhante ao menu principal de vários aplicativos desktop.

• Calendário

• Vale sempre lembrar que esses e os demais controles são customizáveis
permitindo mudança de cores de texto, de plano de fundo, entre outros.

• Existe também a possibilidade de se combinar vários controles para se
criar um novo controle, como, por exemplo, um controle de
preenchimento de data de nascimento.
• Controles totalmente novos também podem ser criados.

Desvantagens do ASP.NET:
• Portabilidade: Só roda em algumas versões do Windows.
• Algumas exceções globais não tratadas podem gerar falhas muito
dificilmente detectadas.
• O modelo de adaptive render nem sempre funciona corretamente, algumas
vezes é necessário “estender” Browser capabilities para que os controles
gerem o padrão HTML correto.
• O primeiro acesso à aplicação pode ser mais lento devido à compilação
ser executada no mesmo, outros modelos de compilação podem resolver o
problema.
• Apesar de o seu uso ser gratuito, não é open source.
• Nem todos os SGBDs fornecem um conector .NET, no entanto é possível
se conectar via ODBC.
• Estudos comparativos e links:
o http://www.brillianceweb.com/betterwebdesign/tips_52.aspx
o http://www.gotdotnet.com/team/compare/
o http://p2p.wrox.com/topic.asp?TOPIC_ID=47496 desvantagens do
.NET e do ASP .NET.
o http://www.linhadecodigo.com.br/artigos.asp?id_ac=957 mostra os
vários modelos de compilação do ASP .NET.

Requisitos
Os principais requisitos da aplicação foram:

• Funcionais
o Permitir autenticação de usuários e o controle de seu acesso.
o Permitir o agendamento de tarefas e eventos, e o registro de sua
execução.
o Consultar dados de testes anteriores, inclusive a observação de
estatísticas sobre os dados de testes, como tempo, número de erros,
reincidência de erros, perfil dos usuários e comentários adicionais.
• Não-funcionais
o Ser disponível para se usar via web, em servidor Windows.
o Usar ferramentas livres.
o Tempo de resposta não pode ser demorado.

Projeto Arquitetural
A arquitetura do sistema é baseada no padrão MVC (Model-View-
Controller), a diferença é que a mesma apresenta um Web Service atuando como
façade permitindo uma maior flexibilidade caso seja necessário realizar
mudanças.
A figura abaixo apresenta um modelo da arquitetura utilizada:

Uma vantagem dessa arquitetura é que ela pode ser facilmente adaptada
para aplicações desktop ou mesmo para dispositivos móveis.
Para dispositivos móveis, a arquitetura é apresentada a seguir:

É interessante observar que o esforço de migração é mínimo, uma vez que
toda a lógica de negócio se mantém e o acesso via Web Service pode ser feito da
mesma maneira.
Para aplicações desktop, a figura abaixo apresenta uma arquitetura
possível:

E ainda, caso seja necessário se optar por outra tecnologia ao invés do
.NET, o modelo e o acesso a ele se mantêm:

É válido observar, também, que a única mudança se dá na camada de
aplicação, pois com essa arquitetura são mantidas a lógica e o acesso à mesma.
A persistência dos dados é realizada com o sistema de banco de dados
MySQL, por ser gratuito e por apresentar eficiência satisfatória.
Há a possibilidade (interesse do cliente) de integrar, no futuro, a ferramenta
WUT2S ao Fermint e ao WebQuest (já mencionados anteriormente na
contextualização do projeto), mas não se tem tanta certeza, pois seus códigos
nem foram vistos ainda. Uma possibilidade de integração pode se dar através do
web service (diagrama acima) ou pelo compartilhamento da base de dados.

User stories
As user stories desenvolvidas durante o período de curso da disciplina
Projeto I foram as seguintes:
• Login de usuários:
o Entrar com login e senha válidos, e o sistema levar o usuário à tela
principal.

o Entrar com login e senha inválidos, e o sistema mostrar mensagem
de erro.
• Cadastro de tarefas:
o Criar, alterar, remover e consultar tarefas
• Cadastro de usuários participantes de testes:
o Criar, alterar, remover e consultar usuários participantes
• Cadastro de usuários avaliadores:
o Criar, alterar, remover e consultar usuários avaliadores
• Cadastro de eventos (posteriormente alterados para indicadores de
usabilidade):
o Criar, alterar, remover e consultar eventos (indicadores de
usabilidade)
• Cadastro de projetos:
o Criar, alterar, remover e consultar projetos
• Cadastro de produtos:
o Criar, alterar, remover e consultar produtos
• Cadastro de sessões de teste:
o Criar, alterar, remover e consultar sessões de teste
• Cadastro de roteiros de teste:
o Criar, alterar, remover e consultar roteiros de teste

Durante a disciplina Projeto II, foram implemantadas a seguintes user
stories:
• Alteração do roteiro de teste:
o Configuração de ordem de tarefas e indicadores de usabilidade
o Visualização, remoção de tarefas e indicadores de usabilidade

• Alteração de sessões de teste:
o Vinculação entre usuários e sessões de teste
• Execução de testes de usabilidade:
o Inicialmente com cronômetro síncrono e apenas uma quantidade
fixa de indicadores de usabilidade
• Criação da apresentação de resultados:
o Por sessão
o Por projeto
o Por usuário em cada sessão
• Reformulação do código:
o Interface
o Código da lógica de negócio
• Implementação de políticas de visualização por tipo de usuário
• Criação do help on line e manual

Além dessas user stories, no início do projeto e no decorrer do mesmo
também foram criadas outras, porém com uma “menor” relevância para o
escopo do sistema, levando em consideração o tempo para finalização deste. Por
isso, estas user stories não foram implementadas, mas ficaram guardadas para
que, com uma possível solicitação do cliente, as mesmas incorporem mais
funcionalidades e características ao sistema.

Big chart

Data Módulos Classes Classes Classes Classes Páginas Páginas
de de lógica de ASP ASP
lógica alteradas interface .NET .NET
alteradas
LES 8 24 8 0 20 20 0
Iteração 12/03/2007 8 35 8 0 26 26 8
01 - P1
Iteração 26/03/2007 10 40 10 0 28 28 8
02 - P1
Iteração 09/04/2007 11 48 14 3 31 31 15
03 - P1
Iteração 23/04/2007 11 50 15 5 35 35 18
04 - P1
Iteração 14/05/2007 12 56 18 6 38 38 20
05 - P1
Iteração 25/06/2007 12 66 21 10 45 45 24
01 - P2
Iteração 09/07/2007 13 75 24 12 51 51 26
02 - P2
Iteração 22/07/2007 13 78 28 15 57 57 29
03 - P2
Iteração 05/08/2007 13 81 29 17 59 59 34
04 - P2
Iteração 19/08/2007 15 95 32 21 63 63 38
05 - P2
Iteração 03/09/2007 15 98 33 25 64 64 47
06 - P2

Data Java Testes de Testes de aceitação
Script Unidade (linhas)
(métodos)
LES 4 18 56
Iteração 01 - 12/03/2007 4 22 68
P1
Iteração 02 - 26/03/2007 4 25 82
P1
Iteração 03 - 09/04/2007 4 29 87
P1
Iteração 04 - 23/04/2007 4 33 97
P1
Iteração 05 - 14/05/2007 4 38 122
P1
Iteração 01 - 25/06/2007 4 44 165
P2
Iteração 02 - 09/07/2007 15 51 227
P2
Iteração 03 – 22/07/2007 15 53 254
P2
Iteração 04 - 05/08/2007 16 58 303
P2
Iteração 05 - 19/08/2007 17 69 341
P2
Iteração 06 - 03/09/2007 17 75 425
P2

Interface
O sistema apresenta uma tela de login como tela inicial. Nesta tela o
usuário deve entrar com seu login e sua senha válidos, a fim de obter acesso às
funcionalidades da ferramenta. A tela inicial é mostrada na figura abaixo:

É válido mencionar que a figura ainda está com o antigo logotipo do
sistema, o Platinum Test.
Após o usuário ser validado (login e senha corretos), a tela principal do
sistema aparece. Esta tela apresenta abas para facilitar a navegação do usuário
pelo sistema. Dependendo do que se quer fazer, três abas podem ser
selecionadas (além de apresentar a aba inicial que mostra a saudação ao
usuário): Cadastro, Consulta ou Execução de teste. Cada uma apresenta um
menu contendo opções referentes ao que se quer cadastrar, consultar ou
executar.
Na aba Cadastro e na aba Consulta, o menu contém as seguintes opções:
Usuário (na aba Consulta, a opção Usuário apresenta, ainda, duas opções:
Avaliador e Participante de teste), Projeto, Produto, Tarefa, Indicador de

usabilidade, Roteiro de teste e Sessão de teste. A aba Execução de teste
apresenta informações relacionadas aos roteiros de teste cadastrados.
As duas figuras abaixo apresentam, respectivamente, a tela principal na
aba Início e na aba Cadastro:

Conclusões

Ao término dessa disciplina, o sistema pode ser considerado pronto para
ser utilizado no LIHM do PaqTc-Pb. Durante o período de dois semestres letivos
foram desenvolvidas as funcionalidades da ferramenta citada neste documento.
Seguindo a metodologia mencionada anteriormente, a equipe
desenvolvedora dividiu todas as tarefas a serem executadas, em cada user storie,
e, em alguns momentos, também fez prática de pair programming, ficando dois
desenvolvedores resolvendo um mesmo problema.
Alguns desafios apareceram e foram superados, como, por exemplo: a
falta de conhecimento em AJAX, já que algumas funcionalidades na interface
precisaram ser desenvolvidas em JavaScript (com o uso de AJAX os resultados
obtidos foram satisfatórios). Além disso, houve um rigor maior relacionado à
interface do sistema, já que o cliente trabalha diretamente na área de “Interface
Homem-Máquina” e o sistema é voltado para um público que também trabalha
nessa área. Como ninguém da equipe que desenvolveu o projeto tinha formação
(bons conhecimentos) nesta, foi gasto um tempo maior do que o esperado com
problemas relacionados à interface.
No decorrer do desenvolvimento, também foram sugeridas modificações
em alguns pontos que já haviam sido discutidos, o que impôs certo atraso
também no andamento do projeto. Mas tudo isso serviu de aprendizado e
mostrou que, com um bom planejamento e uma boa organização de tarefas, os
problemas quando aparecem são mais fáceis de tratar e não atrasam tanto quanto
se não houvesse um bom planejamento anteriormente.
Cada integrante da equipe passou por um período de gerência do projeto,
o que fez com que cada um ganhasse certa experiência, também, em relação ao
conhecimento de gerenciamento de projetos, já que todos não ficaram apenas na
visão de desenvolvedores do sistema.

Pode-se dizer que o cliente está de acordo com tudo o que foi feito, pois
todas as funcionalidades que tinham prioridade foram implementadas de acordo
com o que foi pedido. Funcionalidades extras podem ser desenvolvidas, segundo
a vontade do cliente, desde que haja mais tempo para tal.
Trabalhos futuros podem fazer a integração entre este sistema e outros já
citados ao longo deste documento, sem grandes complicações, acredita-se.

Referências Bibliográficas

LOBO, R. C. L. & QUEIROZ, J. E. R. & TURNELL, M. F. Q. V. WebQuest: Uma
ferramenta Web configurável para o delineamento do perfil e a sondagem da satisfação
subjetiva do usuário. Disponível em:
http://grise.upm.es/rearviewmirror/conferencias/jiisic04/Papers/11.pdf.

MOBRIPRO. Tasktimer. Disponível em:
http://www.mobipro.com/products.asp?pID=1.
TECHSMITH. Morae. Disponível em: http://www.techsmith.com/morae.asp.
_______. UserVue. Disponível em: http://www.techsmith.com/uservue.asp.

USERFOCUS. Usability Test Data Logger tool v4.2. Disponível em:

http://www.userfocus.co.uk/resources/datalogger.html.

WEBQUEST. Disponível em: http://www.lihm.paqtc.org.br/webquest/.

Apêndice 1 – Glossário de termos mais utilizados na plataforma .NET
Como toda nova tecnologia, a plataforma .NET inclui uma série de novos termos. Os mais
comuns estão listados abaixo:
CLR – Sigla de Common Language Runtime. Base comum a todas as linguagens escritas
para a plataforma. O CLR é o ambiente que gerencia a execução de código escrito em
qualquer linguagem. O CLR faz parte do framework .NET.

FRAMEWORK .NET – É a estrutura da plataforma .NET para construir, instalar e rodar
qualquer aplicação, seja ela desenvolvida para desktop ou internet. Para executar qualquer
programa .NET é preciso ter o framework instalado.

IDE – Ambiente integrado de desenvolvimento (Integrated Development Environment) do
Visual Studio .NET. Diferentes linguagens usam o mesmo ambiente para desenvolvimento
(editor de código, depurador) e compilam executáveis na linguagem MSIL. Além das
linguagens nativas suportadas existem pelo menos outras vinte que foram portadas para este
ambiente (Perl, Cobol, Pascal, etc).

MSIL – Microsoft Intermediate Language. Toda aplicação .NET compilada é convertida para
uma linguagem intermediária, a MSIL. Ela é um conjunto de instruções independentes de
CPU. Na hora da execução do programa, um novo compilador chamado Just-in-time
Compiler (JIT), converte o MSIL para código nativo, específico para o processador da
máquina.

MANAGED CODE - Código gerenciado pelo framework .NET. Tarefas como alocação de
memória e garbage collector são gerenciadas automaticamente pelo ambiente. Das linguagens
nativas apenas o C++ produz código não gerenciado (Unmanaged Code).

SOAP – Sigla de Simple Object Access Protocol. O SOAP é um padrão aberto baseado em
XML e gerenciado pelo W3C para a transferência de dados entre aplicações. Pode ser usado
em conjunto com vários outros protocolos comuns da internet.

UDDI – Sigla de Universal Description, Discovery and Integration. Funciona como uma
espécie de páginas amarelas para Web Services. Na UDDI, empresas podem expor seus
serviços para que outras pessoas possam utilizá-lo.

XML – Sigla de Extensible Markup Language. O XML é uma linguagem baseada em tags,
semelhante ao HTML. Sua principal característica é a extensibilidade. Quem cria um
documento XML pode introduzir tags personalizadas, que podem ser explicadas em um
documento XSD anexo.

XSD – Sigla de Schema Definition. Documento associado a um documento XML utilizado
para descrever e validar os dados do documento XML. Documentos XSDs aceitam dados de
diferentes tipos, como números, data e moeda.

XML Web Service – Blocos fundamentais para a criação do modelo de computação
distribuída na internet. Um Web Service é uma porção de código localizada num servidor web
e pode ser utilizada por uma aplicação qualquer.

WSDL – Sigla de Web Service Description Language. A Linguagem WSDL define regras

baseadas em XML para descrever os Web Services. A WSDL é padroniza da pelo órgão gestor
W3C.

Monografia - Ciência da Computação - UFCG

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Monografia - Ciência da Computação - UFCG

Ähnlich wie Monografia - Ciência da Computação - UFCG (20)

Mehr von Dalton Valadares

Mehr von Dalton Valadares (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Monografia - Ciência da Computação - UFCG