Monografia - Ciência da Computação - UFCG
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,013 views

WUT2S (Web Usability Test Task Scheduler)...

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

Trabalho conclusivo do projeto final do curso de Ciência da Computação, da UFCG. Alunos: Dalton Valadares, Diego Santos e Thiago Gondim.

Statistics

Views

Total Views
2,013
Views on SlideShare
2,013
Embed Views
0

Actions

Likes
0
Downloads
21
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Universidade Federal de Campina GrandeCentro de Engenharia Elétrica e InformáticaCurso 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 deinformatização do processo de realização de testes de usabilidade do Laboratóriode 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 paraverificar 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 umambiente monitorado. As ações desses usuários, ao utilizarem o produto, sãogravadas e anotadas para depois serem analisadas por um avaliador. Os testesseguem 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 qualquerdesconforto que venham a sentir. Após a análise dos resultados obtidos duranteo teste, algumas recomendações são geradas em relação a possíveis problemasencontrados nas interfaces do produto. O Laboratório de Interface Homem-Máquina, do PaqTc-Pb, prestaserviços de projeto e avaliação caracterizados por uma série de atividadesvoltadas para uma integração mais efetiva da Universidade com o setorempresarial, em especial com a indústria. Dessa forma, tem oferecido àsorganizações interessadas uma gama de serviços de consultoria a projetos,iniciativas de implantação de tecnologias e/ou recomendações relativas atomadas de decisões quanto à estruturação/aperfeiçoamento de ambientes econtextos de trabalho. Nesses serviços estão incluídos os testes de usabilidadepara avaliação de produtos (sistemas desktop, sistemas web ou aplicaçõesmóveis). O projeto é um sistema web para informatizar o trabalho de obtenção deinformaçã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 graude satisfação do usuário ao utilizar o produto (software) testado. Todos os testes, atualmente, são realizados de forma manual, o que fazcom que o processo de colheita de dados, resultantes da observação dos testes, ea análise dos mesmos demandem um pouco mais de trabalho e de tempo, secomparado ao mesmo processo estando informatizado, já que grande parte dainformação fica armazenada no computador, ao invés de vários papéis comformulários preenchidos, observações e outros dados relevantes à análise daferramenta testada. Os testes de usabilidade são realizados por pessoas que provavelmenteutilizarão o produto em questão, ou que apresentam um perfil semelhante, e sãoobservados por alguns avaliadores. Os avaliadores observam todo ocomportamento do usuário que está testando o produto e registram tudo o queacontece durante o teste, como: número de erros do usuário para executardeterminada tarefa com o produto, tempo que o usuário leva para realizar todo oroteiro de teste, etc. Toda a informação obtida dos testes fica registrada empapéis que contêm formulários. Ao término de várias sessões de testes, cadaavaliador tem uma grande quantidade de formulários que devem serarmazenados para depois serem analisados. Pode-se entender como problema a grande quantidade de informação a sertratada “manualmente” e armazenada em vários arquivos físicos (váriosformulários - como já citados -, notas de observação, etc.). Esse problema vem aser solucionado com a construção do sistema web, pois este passa a armazenartoda a informação no computador, automatizando grande parte do processo deacompanhamento de testes de usabilidade realizados no LIHM do PacTc. O sistema permite cadastrar e consultar usuários, produtos, tarefas eoutras “entidades” envolvidas em um teste de usabilidade, bem comoacompanhar todo o teste, registrando as informações de maior relevânciaobservadas durante a execução deste.
    • Para construção do sistema foi utilizada a linguagem ASP .NET que fazparte do framework .NET 2.0 da Microsoft. A parte lógica foi desenvolvida nalinguagem C#, também utilizando o .NET 2.0. Para o desenvolvimento oambiente utilizado foi o Visual Studio 2005, também da Microsoft, e apersistência de dados é feita através do sistema de banco de dados MySQL.Algumas funcionalidades apresentadas na interface web foram desenvolvidasem 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 eo ambiente de execução; na segunda seção, a fundamentação teórica é abordada,mostrando os principais conceitos e métodos utilizados no desenvolvimento doprojeto; 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 osresultados obtidos com o projeto, desde o início do desenvolvimento até aconclusão do mesmo; e, por fim, a última seção é uma conclusão sobre tudo quefoi obtido, envolvendo nível de satisfação do cliente, possíveis dificuldadesencontradas, etc.
    • Contexto do ProjetoEustáquio Rangel, doutor em Engenharia Elétrica pela Universidade Federal daParaíba – UFPB, é avaliador no Laboratório de Interface Homem-Máquina –LIHM, localizado no Parque Tecnológico da Paraíba. Entre as atividadescomuns, está a realização de baterias de testes (convencionais) de usabilidade. Nesses testes de usabilidade, indivíduos que representam uma classe deusuários em potencial de um determinado produto (comumente software)possam experimentar a sua utilização. O grau de facilidade com que essesusuários de teste conseguem lidar com o produto é um indicativo da qualidadede sua interface. Para que os resultados possam ser representativos para aprecisão da avaliação, é necessária a realização do mesmo teste com umaquantidade mínima de usuários, e em cada teste é necessária a coleta deinformações relacionadas ao tempo (duração, freqüência de determinadoseventos, etc.), assim como em relação ao “espaço”, por exemplo a posição datela 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 coletadesses 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 pormanusear mais de um cronômetro convencional, formulário em papel, e aindater necessidade de utilizar o microfone para se comunicar com o usuário deteste. Para diminuir os riscos de perda de informação, há a necessidade de umaferramenta integrada para aumentar a produtividade do avaliador em suaoperação de coleta de dados. A forma mais desejável era através de um sistemacomputacional. 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 sersignificativamente lento, pois quanto maior a diferença de tempo entre umevento observado e seu registro, menos precisos são os resultados que serãoavaliados após o teste. O cliente, em experiências semelhantes com equipesanteriores, recomendou fortemente evitar a utilização de JSP (Java ServerPages), se essa tecnologia causasse perda de desempenho em relação ao termpode resposta. Uma restrição inerente de o sistema executar através da web é aimpossiblidade da garantia de interação do sistema de coleta através deprocessos em execução na máquina do usuário de teste, como por exemplo avisode que o tempo previsto para uma tarefa foi encerrado. Além disso, também há o interesse de essa ferramenta servir como umaagenda de atividades, para uso no LIHM e em outras instituições que nãonecessariamente realizem testes de usabilidade. Outra característica dispensável, porém atrativa era o desenvolvimento daferramenta por alunos da Universidade Federal de Campina Grande, devido aohistórico de cooperação entre essa instituição e o Parque Tecnológico,fomentando a atuação de alunos em diversos problemas, incentivando odesenvolvimento do seu conhecimento na realização de sistemas utilizáveis emsituações reais. Por essas características, o problema de construir a ferramenta deexecução de testes de usabilidade foi disponibilizada no rol de alternativas paraa 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 arealização de testes de usabilidade. O Usability Test Data Logger é um softwarebaseado em macros do Microsoft Excel que permite a execução de todo o cliclodos testes de usabilidade, desde o planejamento e a realização, até a síntese dedados. É 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 peloLIHM.
    • Uma das telas do Usability Datalogger A empresa TechSmith também desenvolve ferramentas para a realizaçãode testes de usabilidade, chamadas de Morae (modo standalone) e UserVue(web). Porém, ambas não são gratuitas, contrariando a prioridade porferramentas não-proprietárias no LIHM. O mesmo vale para a UTE, um sistemapara o mesmo fim, produzida pela MindDesign Systems. Em relação às operações de cadastro de atividades, estilo agenda, foiutilizada como referência a ferramenta TaskTimer. Ela permite o gerenciamentode atividades por categoria, relevância, além de ter um banco de dados integradopara o intercâmbio de informações entre os diversos usuários do sistema.Adicionalmente, ainda há a funcionalidade de integrar essas informações naforma 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 interfacehomem-máquina, há outras ferramentas desenvolvidas por alunos daUniversidade Federal de Campina Grande,: O WebQuest, que também é uma ferramenta acessível pela webresponsável pela obtenção de dados subjetivos sobre a percepção de um usuáriode teste sobre o produto a ser testado. Com o auxílio do WebQuest, é possível setraçar um perfil de usuário e na sondagem da satisfação subjetiva de usuários desistemas interativos. O Fermint também é outra ferramenta que facilita é útil como um aliadoda realização de testes de usabilidade. O Fermint permite se avaliar diretamenteas possíveis falhas existentes em interfaces do produto-alvo, tal como umsoftware. Associada ao WUT2S, pode auxiliar o planejamento do roteiro de teste.
    • Fundamentação TeóricaPlataforma .NETUtilizamos a plataforma .NET, a qual oferece uma alternativa de ambiente paraproduzir aplicações Windows e Web, executando-as nos mais diversosdispositivos (PCs, Palms, telefones celulares, etc). A Microsoft torna a infra-estrutura de suporte ao .NET amplamente disponível. O framework de suportepode ser baixado e instalado livremente.O framework .NETO framework .NET, base da plataforma .NET, é uma plataforma de programaçãopara 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 deprogramação.O código das aplicações .NET é compilado para MSIL (Microsoft IntermediateLanguage) e é armazenado em um arquivo chamado assembly. Em tempo deexecução, o assembly é compilado para o seu estado final pela CLR. Enquantoestá ativa, a CLR proporciona checagem de tipo (type-safety checks) e outrastarefas de run-time.Aplicações que rodam sob o CLR são chamadas aplicações de códigogerenciado porque o CLR responsabiliza-se por tarefas que normalmente seriamde 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 doregistro de componentesIntrodução ao ASP.NETO ASP.NET é uma parte importante do framework .NET, mas trata-sesimplesmente 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 oIIS (Internet Information Services). O que torna o ASP.NET especial é o fatodele ser fortemente integrado com ferramentas de programação, acesso à dados esegurança.O ASP.NET proporciona um alto nível de consistência no desenvolvimento deaplicaçõ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 paradesenvolvimento de páginas Web, templates de aplicação e ferramentas dedeployment;Oferece tudo o que é preciso para qualquer tipo de aplicação para Web, sejaDesign, código, componente, Web Service, camada de aplicação ou negócio;Incorpora nativamente diversas linguagens de programação, tais como: VisualBasic, Visual C++, J#, Cobol (inclusive) e C# (a qual usamos ao longo dodesenvolvimento deste projeto).· System.Web namespaces. Fazem parte do frameWork .NET e incluem classesque 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 asfuncionalidades da CLR . Cada namespace contém um grupo de classesrelacionadas. A tabela abaixo sintetiza os namespaces de maior interesse aosprogramadores Web.Categori Namespaces Utilizaçãoa Todos os tipos comuns de dados, incluindo strings, arrays e tipos númericos. Estas classes incluemTipos métodos para SystemComuns 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 paraDebuggin System.Diagnostics Debugging eg tracing. Métodos para acesso so sistema de arquivos. Incluem System.IO,Acesso ao métodos de System.IO.IsolatedStorSistema leitura e age,de escrita de System.DirectoryServicArquivos 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 comoRede 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 deSeguranç System.Security.Permis usuários aléma 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 deAplicaçõe ion, componentess 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 paraAplicaçõe s, criação des System.Windows.Form aplicaçõesWindows s.Design Windows. System.Xml, Criação e System.Xml.Schema, acesso aXML System.Xml.Serializati arquivos on, System.Xml.Xpath, XML. System.Xml.Xsl· Server Controls e HTML Controls . São componentes visuais utilizados paraobter informações e proporcionar respostas aos usuários da aplicação.Adicionalmente, O ASP.NET também utiliza componentes de programação maisgerais. Eles não fazem parte do ASP.NET mas são ítens chave para a suautilização:· Microsoft Internet Information Services (IIS). Hospeda as aplicações Web.Todo o processamento é feito no servidor, onde encontra-se o InternetInformation Server (IIS)
    • · Visual Basic.NET, linguagens de programação Jscript e C# (a qual usamosao longo do desenvolvimento do projeto). Estas três linguagens têm suporteintegrado no Visual Studio.NET.· FrameWork .NET. É um conjunto completo de classes. Elas incluem classesASP.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 outrosbancos de dados acessados via ODBC.· Microsoft Application Center Test (ACT) . Este componente do VisualStudio.NET fornece um meio automatizado para fazer testes de stress com aaplicação.Ferramentas adicionais No ASP .NET, mais especificamente no Visual Studio .NET, contamoscom o Server Explorer e com o Solution Explorer. - Server Explorer: excelente recurso, com o qual pode-se verificar todosos recursos existentes no computador. Com ele, pode-se, inclusive, criar bancode dados, tabelas, consultas, funções e Stored Procedures, e até, fazer ananutenção de todos os registros de uma tabela. Utilizando-se de qualquer BDdisponível. - Solution Explorer: ferramenta que permite administrar todos os arquivoscontidos na solução.
    • OOP A programação Orientada a Objetos (OOP) é padrão em todas aslinguagens .NET e permite desenvolvimento estruturado, reaproveitamento decó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óriovirtual.ProvedoresFaz-se necessário ter Windows 2000 ou superior e, o Framework instalado.Onde rodarEm qualquer navegador, independentemente de fabricante ou versãoPrincipais pontos envolvidos no processo de compilação de uma aplicaçãoASP.NET 2.0:Modelo de Código no ASP.NET 2.0O 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 pelodesenvolvedor e omite o código gerado automaticamente pelo Visual Studio.Quando uma página ASPX com o novo modelo de code-behind é chamada, oASP.NET 2.0 combina o arquivo ASPX (a qual contém a interface gráfica) e aclasse parcial numa única classe ao invés de duas classes separadas.As classes parciais usam uma palavra-chave (Partial no C#) para indicar que ocódigo nesta classe deve ser mesclado com outra classe quando em modoruntime. De maneira semelhante o arquivo ASPX utiliza uma diretivaCompileWith 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, oarquivo de código pode acessar automaticamente qualquer controle na páginasem a necessidade de código declarativo. Isto é possível porque o Runtime doASP.NET 2.0 insere automaticamente as declarações exigidas para os controlese eventos no arquivo compilado ao final do processo, desta forma odesenvolvedor não precisa preocupar-se com isso.Com esse novo modelo, o arquivo de código e a página ASPX são mesclados ecompilados numa única e completa classe em runtime eliminando acomplexidade do processo de compilação. A sincronização entre o arquivo decódigo e o arquivo ASPX é automática, mas ainda assim é possível que o códigoseja alterado no arquivo ASPX e não atualizado no arquivo de código, contudo odesenvolvedor poderá localizar o problema de forma muito mais rápida uma vezque o ASP.NET 2.0 gerará uma Exception muito mais detalhada.Modelos de compilação no ASP.NET 2.0O 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 numassembly e armazenados na pasta /bin da aplicação. As páginas ASPX sãocompiladas por demanda. Este modelo funciona bem para a maioria doswebsites. Contudo, este processo de compilação torna a primeira requisição dequalquer 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. ORuntime do ASP.NET 2.0 se encarregará de realizar a compilação quandoreceber a primeira requisição para a aplicação. Se alguma alteração for feita, nopróximo request da página alterada, o Runtime do ASP.NET 2.0 determinará asdependências do arquivo alterado e realizará a compilação apenas para osarquivos 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 tempode execução. A ferramenta provoca vários requests para o website provocando acompilação do mesmo. Se altera-se a página da aplicação, deve-se repetir oprocesso 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 arquivoalterado.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çõesnas 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 todosque tiverem acesso à pasta da aplicação.Deployment Pre-CompilationEste modelo inserido no ASP.NET 2.0 permite ao desenvolvedor fazer acompilação completa da sua solução antes de fazer o deployment. Com acompilação completa, todos os arquivos code-behind, páginas ASPX, HTML,recursos gráficos, são compilados em um ou mais assemblies, dependendo dotamanho da aplicação e da configuração da compilação. Os assemblies contém oWebsite completo, com exceção do arquivo Web.config. Este modelo decompilação oferece a melhor performance e segurança se comparado com osoutros modelos, porém remove a capacidade de qualquer alteração no Websiteapós feito o deployment. Se trabalha-se em um website altamente visado, ou queexige alto nível de segurança, este modelo é a melhor opção para o deploymentfinal. Contudo, se desenvolve-se um pequeno website, trabalhando numaintranet local, e o projeto requer frequentes mudanças, este modelo decompilação porde tornar-se inviável.
    • Pre-Compilation com camada de apresentação atualizávelCom a utilização do parâmetro –u da ferramenta ASP.NET Compilation, odesenvolvedor pode pré-compilar os arquivos de código (*.vb ou *.cs) e osarquivos de recursos (*.resource), deixando o código da camada deapresentação (HTML) disponível para atualizações. Depois de realizar odeployment do website no servidor de produção, os arquivos ASPX podem sermodificados 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ávelA ferramenta ASP.NET Compilation pode compilar todo código-fonte de umaaplicação, incluindo os arquivos de interface (ASPX, ASCX), encapsulando-osem 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 dedesenvolvimento trabalhou para o desenvolvimento do projeto, quais e como foio processo de desenvolvimento, como foram feitos o controle de versão, oambiente de desenvolvimento, a comunicação com o cliente e entre os membrosdesenvolvedores, etc. E por fim, é apresentado comentários relevantes. Durante o desenvolvimento do projeto, correspondente à disciplinaProjeto1 e Projeto2, o processo de desenvolvimento utilizado foi o XP1. Aseguir, 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 docliente. Um release em XP1 é composto de iterações, preferencialmente poucas,entre 2 e 5.Atividades
    • As atividades realizadas em XP1 podem ser brevemente descritas daseguinte maneira:- Planejamento: abrange a escrita de User Stories (funcionalidades),levantamento de requisitos não funcionais, planejamento de releases e deiteração;- Projeto: se divide em projeto arquitetural e refatoramento constante;- Testes: inclui a elaboração de testes de aceitação e de unidade, assegurandoque 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 softwarecom 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 projetopara desenvolver uma tarefa) antes de iniciar o desenvolvimento e fazendocheck-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 doprojeto,sendo desempenhada pelo gerente.Gestão do Código Durante todo o período de desenvolvimento do projeto, o código foicompartilhado entre seus desenvolvedores. No planejamento, cada
    • funcionalidade tornava-se responsabilidadede um desenvolvedor especíco, porém com o compartilhamento do códigoincentivado, de forma que todos os desenvolvedores poderiam ajudar emqualquer parte implementada, mesmo que não fosse, à priori, de suaresponsabilidade. 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émobtivemos problemas de configuração e migramos para o “Subversion” (sistemade controle de versão, também conhecido svn ou SVN, desenhadoespecificamente para ser um substituto moderno do CVS, que se considera teralguns defeitos) do GoogleCode.Ambiente de Desenvolvimento O ambiente de desenvolvimento escolhido foi o VisualStudio.NET. Osdesenvolvedores do projeto o escolheram, pois além de sua familiaridade, oVisualStudio .NET também é uma ferramenta poderosa, de fácil utilização, altaportabilidade, muito flexível para utilização de plugins e uma das maiscompletas IDE´s da atualidade. Possui integração com o banco de dadosescolhidos (MySQL), Nunit e todas as demais ferramentas por nós utilizadas. Para testes, usamos o NUnit e o EasyAcceptToNUnit. O primeiro comoum 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 ede fácil aceitação.Comunicação A comunicação, como em todas as áreas, é parte vital para o sucesso deum 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 atarde. Na reunião discutíamos questões pendentes e trabalhávamosconjuntamente no código propriamente dito. É importante ressaltar que a comunicação virtual continuou existindo aolongo de todo o processo e que dávamos continuidade ao códigoindividualmente, em nossos domicílios. Todos estavam livres para tirar qualquer dúvida sobre a implementaçãocom os outros integrantes e/ou com o próprio cliente. O qual demonstrou grandedisponibilidade e prestatividade para esclarecer eventuais questões. Muitasdúvidas, quanto ao projeto como um todo, foram clarificadas durante as reuniõessemanais 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 dedesenvolvimento, acompanhando de perto cada passo e validando as
    • funcionalidades recém-implementadas por meio de demonstrações por parte dosdesenvolvedores. 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 decomputação e,conseqüentemente, sabia explicar (inclusive com termos técnicos) o quedesejava.Portanto, suas especificações tinham maior chance de serem corretamenteinterpretadas 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 dereleases e a distribuição das user stories por cada iteração, não podendo estimaro tempo em que as user stories deveriam ser concluídas. O cliente também sedispôs a tirar dúvidas dos desenvolvedores quando/se surgissem. Os desenvolvedores, por sua vez, apoiaram o cliente na definição de userstories e requisitos não-funcionais, elaboraram o projeto arquitetural eestimaram o tempo de desenvolvimento das user stories durante o planejamentode releases. Durante a fase do planejamento de iteração, dividiram as user storiesdaquela iteração em tarefas, escolheram quais tarefas iriam desenvolver eestimaram precisamente o tempo de desenvolvimento de cada tarefa. Também
    • desenvolveram o esquema lógico e testes de unidade para cada tarefa, semprefazendo integração. Já o gerente foi responsável por cobrar o andamento do projeto, conduziras atividades de planejamento, descobrir riscos e traçar estratégias para lidarcom os mesmos.Cada um dos alunos foi gerente durante uma release e o gerenteacumulava também as responsabilidades de desenvolvedor.Prazos de entrega Em datas definidas pelas ministrantes das disciplinas, as equipes entregamalgumresultado de seu trabalho. Existem três tipos de entrega:- Apresentação de planejamento: devem-se entregar artefatos resultantes daanálise do sistema, ou seja, requisitos funcionais e não-funcionais, projetoarquitetural e o planejamento de releases e iterações, distibuindo asfuncionalidades nas mesmas.- Apresentação de iteração: artefatos de acompanhamento devem serapresentados, como big charts, tabela de cumprimento de atividades, etc;- Apresentação de release: além dos artefatos mencionados acima, deve-se teruma 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 asmostravam ao cliente durante as reuniões semanais.Comentários- A ferramenta EasyAcceptToNUnit foi uma adaptacao implementadaexclusivamente para este projeto. Já existia o EasyAccept, a qual tem a mesmafuncionalidade mas trabalha com a linguagem Java;- Um dos integrantes (Thiago Gondim) não possuía familiaridade com alinguagem e plataforma utilizadas, pois este projeto é uma continuidade doprojeto da disciplina LES (Laboratório de Engenharia de Software), do qual elenão fazia parte. Este membro fazia parte de outro projeto porém decidiu mudarpara este por ter achado a proposta interessante e por desejar ampliar seushorizontes, aprendendo algo como .NET
    • Resultados O WUT2S é um sistema web que apresenta toda sua interface desenvolvidaem ASP .NET. Toda a lógica do sistema foi implementada na linguagem C#,utilizando o Visual Studio como ambiente de desenvolvimento. Algumasfuncionalidades da interface foram desenvolvidas com JavaScript, utilizando abiblioteca ASP .NET AJAX (antigo ATLAS). A interface do sistema apresenta abas com o intuito de aproximar o usodeste com o uso de determinados sistemas desktop. Menus são utilizados emcada aba, seguindo um padrão para facilitar a utilização das funcionalidades dosistema. A escolha das linguagens se deu após se ter tomado conhecimento dosservidores Windows que se encontram no LIHM e baseado em certafamiliaridade dos integrantes do projeto com as mesmas. Além disso, a escolhadessa 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 comofaçade permitindo uma maior flexibilidade caso seja necessário realizarmudanças. A figura abaixo apresenta um modelo da arquitetura utilizada:
    • Uma vantagem dessa arquitetura é que ela pode ser facilmente adaptadapara 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 quetoda a lógica de negócio se mantém e o acesso via Web Service pode ser feito damesma maneira. Para aplicações desktop, a figura abaixo apresenta uma arquiteturapossí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 deaplicaçã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 dadosMySQL, por ser gratuito e por apresentar eficiência satisfatória.Há a possibilidade (interesse do cliente) de integrar, no futuro, a ferramentaWUT2S ao Fermint e ao WebQuest (já mencionados anteriormente nacontextualização do projeto), mas não se tem tanta certeza, pois seus códigosnem foram vistos ainda. Uma possibilidade de integração pode se dar através doweb service (diagrama acima) ou pelo compartilhamento da base de dados.User stories As user stories desenvolvidas durante o período de curso da disciplinaProjeto 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 mesmotambém foram criadas outras, porém com uma “menor” relevância para oescopo do sistema, levando em consideração o tempo para finalização deste. Porisso, estas user stories não foram implementadas, mas ficaram guardadas paraque, com uma possível solicitação do cliente, as mesmas incorporem maisfuncionalidades 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 alteradasLES 8 24 8 0 20 20 0Iteração 12/03/2007 8 35 8 0 26 26 801 - P1Iteração 26/03/2007 10 40 10 0 28 28 802 - P1Iteração 09/04/2007 11 48 14 3 31 31 1503 - P1Iteração 23/04/2007 11 50 15 5 35 35 1804 - P1Iteração 14/05/2007 12 56 18 6 38 38 2005 - P1Iteração 25/06/2007 12 66 21 10 45 45 2401 - P2Iteração 09/07/2007 13 75 24 12 51 51 2602 - P2Iteração 22/07/2007 13 78 28 15 57 57 2903 - P2Iteração 05/08/2007 13 81 29 17 59 59 3404 - P2Iteração 19/08/2007 15 95 32 21 63 63 3805 - P2Iteração 03/09/2007 15 98 33 25 64 64 4706 - P2
    • Data Java Testes de Testes de aceitação Script Unidade (linhas) (métodos)LES 4 18 56Iteração 01 - 12/03/2007 4 22 68P1Iteração 02 - 26/03/2007 4 25 82P1Iteração 03 - 09/04/2007 4 29 87P1Iteração 04 - 23/04/2007 4 33 97P1Iteração 05 - 14/05/2007 4 38 122P1Iteração 01 - 25/06/2007 4 44 165P2Iteração 02 - 09/07/2007 15 51 227P2Iteração 03 – 22/07/2007 15 53 254P2Iteração 04 - 05/08/2007 16 58 303P2Iteração 05 - 19/08/2007 17 69 341P2Iteração 06 - 03/09/2007 17 75 425P2
    • Interface O sistema apresenta uma tela de login como tela inicial. Nesta tela ousuário deve entrar com seu login e sua senha válidos, a fim de obter acesso àsfuncionalidades da ferramenta. A tela inicial é mostrada na figura abaixo:
    • É válido mencionar que a figura ainda está com o antigo logotipo dosistema, o Platinum Test. Após o usuário ser validado (login e senha corretos), a tela principal dosistema aparece. Esta tela apresenta abas para facilitar a navegação do usuáriopelo sistema. Dependendo do que se quer fazer, três abas podem serselecionadas (além de apresentar a aba inicial que mostra a saudação aousuário): Cadastro, Consulta ou Execução de teste. Cada uma apresenta ummenu contendo opções referentes ao que se quer cadastrar, consultar ouexecutar. 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 testeapresenta informações relacionadas aos roteiros de teste cadastrados. As duas figuras abaixo apresentam, respectivamente, a tela principal naaba Início e na aba Cadastro:
    • Conclusões Ao término dessa disciplina, o sistema pode ser considerado pronto paraser utilizado no LIHM do PaqTc-Pb. Durante o período de dois semestres letivosforam desenvolvidas as funcionalidades da ferramenta citada neste documento. Seguindo a metodologia mencionada anteriormente, a equipedesenvolvedora dividiu todas as tarefas a serem executadas, em cada user storie,e, em alguns momentos, também fez prática de pair programming, ficando doisdesenvolvedores resolvendo um mesmo problema. Alguns desafios apareceram e foram superados, como, por exemplo: afalta de conhecimento em AJAX, já que algumas funcionalidades na interfaceprecisaram ser desenvolvidas em JavaScript (com o uso de AJAX os resultadosobtidos foram satisfatórios). Além disso, houve um rigor maior relacionado àinterface do sistema, já que o cliente trabalha diretamente na área de “InterfaceHomem-Máquina” e o sistema é voltado para um público que também trabalhanessa á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 comproblemas relacionados à interface. No decorrer do desenvolvimento, também foram sugeridas modificaçõesem alguns pontos que já haviam sido discutidos, o que impôs certo atrasotambém no andamento do projeto. Mas tudo isso serviu de aprendizado emostrou que, com um bom planejamento e uma boa organização de tarefas, osproblemas quando aparecem são mais fáceis de tratar e não atrasam tanto quantose 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 aoconhecimento de gerenciamento de projetos, já que todos não ficaram apenas navisão de desenvolvedores do sistema.
    • Pode-se dizer que o cliente está de acordo com tudo o que foi feito, poistodas as funcionalidades que tinham prioridade foram implementadas de acordocom o que foi pedido. Funcionalidades extras podem ser desenvolvidas, segundoa 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áficasLOBO, 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 .NETComo toda nova tecnologia, a plataforma .NET inclui uma série de novos termos. Os maiscomuns estão listados abaixo:CLR – Sigla de Common Language Runtime. Base comum a todas as linguagens escritaspara a plataforma. O CLR é o ambiente que gerencia a execução de código escrito emqualquer linguagem. O CLR faz parte do framework .NET.FRAMEWORK .NET – É a estrutura da plataforma .NET para construir, instalar e rodarqualquer aplicação, seja ela desenvolvida para desktop ou internet. Para executar qualquerprograma .NET é preciso ter o framework instalado.IDE – Ambiente integrado de desenvolvimento (Integrated Development Environment) doVisual Studio .NET. Diferentes linguagens usam o mesmo ambiente para desenvolvimento(editor de código, depurador) e compilam executáveis na linguagem MSIL. Além daslinguagens nativas suportadas existem pelo menos outras vinte que foram portadas para esteambiente (Perl, Cobol, Pascal, etc).MSIL – Microsoft Intermediate Language. Toda aplicação .NET compilada é convertida parauma linguagem intermediária, a MSIL. Ela é um conjunto de instruções independentes deCPU. Na hora da execução do programa, um novo compilador chamado Just-in-timeCompiler (JIT), converte o MSIL para código nativo, específico para o processador damáquina.MANAGED CODE - Código gerenciado pelo framework .NET. Tarefas como alocação dememória e garbage collector são gerenciadas automaticamente pelo ambiente. Das linguagensnativas 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 emXML e gerenciado pelo W3C para a transferência de dados entre aplicações. Pode ser usadoem conjunto com vários outros protocolos comuns da internet.UDDI – Sigla de Universal Description, Discovery and Integration. Funciona como umaespécie de páginas amarelas para Web Services. Na UDDI, empresas podem expor seusserviç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 umdocumento XML pode introduzir tags personalizadas, que podem ser explicadas em umdocumento XSD anexo.XSD – Sigla de Schema Definition. Documento associado a um documento XML utilizadopara descrever e validar os dados do documento XML. Documentos XSDs aceitam dados dediferentes tipos, como números, data e moeda.XML Web Service – Blocos fundamentais para a criação do modelo de computaçãodistribuída na internet. Um Web Service é uma porção de código localizada num servidor webe 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 gestorW3C.