JULIANO FRANCISCO DE SOUZA GALGARO PEDRO VINICIUS DA ROSA
COTAMUS:
SISTEMA WEB PARA COTAÇÕES DE PRODUTOS BASEADO NOS CONCEITOS DA WEB 2.0
Palhoça 2010
PEDRO VINICIUS DA ROSA
COTAMUS:
SISTEMA WEB PARA COTAÇÕES DE PRODUTOS BASEADO NOS CONCEITOS DA WEB 2.0
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Dr. João Luiz Alkaim.
Palhoça 2010
JULIANO FRANCISCO DE SOUZA GALGARO PEDRO VINICIUS DA ROSA
COTAMUS:
SISTEMA WEB PARA COTAÇÕES DE PRODUTOS BASEADO NOS CONCEITOS DA WEB 2.0
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina.
Palhoça, 18 de junho de 2010.
______________________________________________________ Professor e orientador João Luiz Alkaim, Dr.
Universidade do Sul de Santa Catarina
______________________________________________________ Profa. Maria Inés Castiñeira, Dra.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Mauro Notarnicola Madeira, Dr.
Dedicamos este trabalho a nossos pais que sempre estiveram ao nosso lado, nos deram amor e compreensão em todos os momentos e ajudaram a construir este projeto que muda nossas vidas. Ao professor João Luiz Alkaim pela ajuda e atenção ao orientar nosso trabalho.
AGRADECIMENTOS
Como este trabalho foi concebido, desenvolvido e elucidado por dois autores, resolvemos criar um espaço separado para fazermos os agradecimentos.
Eu, Pedro Vinicius, gostaria de agradecer primeiramente a minha família, meu pai Pedro e minha mãe Ivanir que sempre estiveram ao meu lado, me dando carinho, amor e apoio sempre que necessário, sem eles com certeza este trabalho não seria possível. Ao meu irmão Guilherme que sempre esteve comigo me ajudando. Aos demais familiares, amigos e colegas de faculdade que estiveram juntos neste longo período de trabalho, saibam que estão ligados a este projeto de maneira direta. Por fim deixo minha palavra de Muito Obrigado a todos.
Eu, Juliano, agradeço aos meus pais José e Iraci pela dedicação, apoio, amor e carinho que recebi durante toda a vida e por me possibilitarem realizar este curso de graduação que, sem dúvida, foi muito importante para o meu crescimento pessoal e profissional. Aos meus primos e demais familiares pelos constantes incentivos durante as etapas do desenvolvimento deste projeto. À minha namorada, Daiane pelo apoio e carinho que recebi nos momentos mais difíceis e estressantes deste período e a todos os amigos que ajudaram de alguma forma para que este trabalho pudesse estar concluído.
Juntos, gostaríamos de agradecer a Deus e aos nossos mestres que acompanharam nossa vida acadêmica durante nossa passagem pela UNISUL, saibam que cada um tem um pedaço dentro deste trabalho de conclusão.
Ao nosso orientador Professor João Luiz Alkaim que contribuiu com ajuda e apoio para que conseguíssemos chegar ao final, concluindo nosso ciclo acadêmico, nosso muito obrigado.
“Não precisamos de mais dinheiro, não precisamos de mais sucesso ou fama, não precisamos do corpo perfeito, nem mesmo do parceiro perfeito, agora mesmo, neste momento exato, dispomos da mente, que é todo o equipamento básico de que precisamos para alcançar a plena felicidade.” (Dalai Lama).
RESUMO
Com o objetivo de ajudar os consumidores do mercado da grande Florianópolis, foi concebida a intenção de criar um sistema baseado em Web 2.0 para controle de cotações de preços em diversos segmentos, inicialmente para postos de combustíveis. Como o sistema é baseado em Web 2.0, foram utilizadas ferramentas que acolhessem este conceito, por isto, utilizou-se a linguagem de programação JAVA com uma de suas derivações JSF (Java Server Faces), a ferramenta Richfaces e outras aplicações web como o servidor Tomcat, da Apache, e requisições Ajax. A Web 2.0 não entrou neste trabalho apenas pelos softwares utilizados, mas também pelo sistema de cotação empregar amplamente o seu conceito primário, o compartilhamento da informação e a interação pessoal entre usuário e sistema, usuário e usuário. O sistema foi complexo em sua formação, porém, para o usuário final, ele foi desenvolvido para ser de utilização simples e de grande influência mútua entre os utilitários. No contexto web, foram utilizados softwares que proporcionassem agilidade na programação e que pudessem auxiliar nas etapas do projeto como: NetBeans IDE, Adobe Photoshop, pgAdmin, DBDesigner e BizAgi Process Modeler. Na modelagem utilizou-se a UML/ICONIX. O sistema “Cotamus” foi desenvolvido para permitir a interatividade do usuário final no mercado da Grande Florianópolis auxiliando nas buscas das cotações de preços e na economia de suas compras.
ABSTRACT
Aiming to help consumers market of Florianopolis, the intention is designed to create a system based on Web 2.0 for the control of price quotations in several segments, initially for gas stations. As the system is based on Web 2.0, tools were used for approach this concept, therefore, it used the JAVA programming language with its derivations JSF (Java Server Faces), the tool RichFaces and other web applications and server Tomcat, the Apache, and Ajax requests. Web 2.0 has not entered in this study only by the software used, but also by the quotation system widely employs its primary concept, information sharing and personal interaction between user and system, user and user. The system was complex in its formation, however, to the end user, it is designed to be simple to use and great mutual influence between the utilities. In the web context, we used software that would provide flexibility in programming and that could help in the steps project as: NetBeans IDE, Adobe Photoshop, pgAdmin, DBDesigner and BizAgi Process Modeler. In the modeling it used the UML / ICONIX. The "Cotamus" system was developed to allow interactive end-user market of Florianópolis assisting in searches of price quotations and the economy in their purchases.
LISTA DE ILUSTRAÇÕES
Figura 1 - Gráfico da evolução do número de domínios .BR ... 17
Figura 2 – Web 1.0 versus web 2.0. ... 23
Figura 3 – Comparação entre aplicações web com modelo clássico e com modelo AJAX ... 26
Figura 4 – Fluxograma da metodologia de desenvolvimento do trabalho. ... 30
Figura 5 – Visão macro do ICONIX ... 33
Figura 6 – Exemplo de modelo de domínio ... 36
Figura 7 – Diagrama de caso de uso ... 37
Figura 8 – Conexão da fase de análise com a fase de design ... 37
Figura 9 – Representação dos objetos interface, controlador e entidade... 38
Figura 10 – Exemplo de diagrama de robustez ... 38
Figura 11 – Exemplo de diagrama de seqüência ... 39
Figura 12 – Exemplo de diagrama de classe ... 40
Figura 13 – Diagrama de pacotes ... 41
Figura 14 – Diagrama do processo de cotação de combustível. ... 42
Figura 15 – Diagrama de casos de uso do processo de cotação de combustível ... 47
Figura 16 – Atores do processo de cotação de combustível ... 48
Figura 17 – Diagrama de caso de uso de busca da melhor cotação. ... 50
Figura 18 – Diagrama de atividades da busca de melhor cotação. ... 51
Figura 19 – Diagrama de robustez da busca de melhor cotação. ... 52
Figura 20 - Diagrama de seqüência do caso de uso Busca de melhor cotação. ... 52
Figura 21 – Diagrama de caso de uso de Cotar Combustível ... 54
Figura 22 – Diagrama de atividades de Cotar de combustíveis ... 55
Figura 23 – Diagrama de robustez de Cotar Combustível. ... 56
Figura 24 – Diagrama de seqüência do caso de uso cotar combustível. ... 57
Figura 25 – Processo de desenvolvimento do Cotamus ... 58
Figura 26 – Tecnologias e softwares utilizados no desenvolvimento do projeto ... 59
Figura 27 – Modelo das tabelas no banco de dados. ... 62
Figura 28 – Classe Combustível referência para a tabela combustível. ... 63
Figura 29 – Classe UnidadeMedida referência para a tabela unidade_medida ... 63
Figura 31 – Tela do módulo de cotações de combustíveis ... 66
Figura 32 – Tela de cadastro de novos usuários ... 67
Figura 33 – Tela de criação de rotas ... 68
Figura 34 – Tela de cadastro e visualização de comentários ... 69
Figura 35 – Tela de nova cotação de combustível... 70
Figura 36 – Página principal do Cotamus ... 71
Figura 37 – Tela de cadastro de novos usuários do sistema ... 72
Figura 38 – Confirmação de cadastro no Cotamus... 73
Figura 39 – Usuário autenticando-se no Cotamus pela página de combustíveis ... 73
Figura 40 – Página das cotações de combustíveis após a autenticação do usuário ... 74
Figura 41 – Tela da busca de melhor cotação ... 75
SUMÁRIO 1 INTRODUÇÃO ... 11 1.1 OBJETIVO PRINCIPAL ... 12 1.2 OBJETIVOS ESPECÍFICOS: ... 12 1.3 JUSTIFICATIVA ... 13 1.4 ESTRUTURA DA MONOGRAFIA ... 13 2 REVISÃO BIBLIOGRÁFICA ... 15 2.1 A INTERNET ... 15 2.1.1 Internet no mundo ... 15
2.1.2 Crescimento da Internet no Brasil ... 16
2.1.3 Sobre o World Wide Web ... 17
2.2 NEGÓCIO ELETRÔNICO (E-BUSINESS) ... 17
2.2.1 Conceitos e vantagens do Negócio Eletrônico ... 18
2.2.2 Comércio Eletrônico (e-commerce) ... 19
2.2.3 Cotação on-line ... 21
2.3 TECNOLOGIAS DA WEB ... 21
2.3.1 Web 2.0 ... 21
2.3.2 Java ... 23
2.3.3 Asynchronous Javascript and XML (AJAX) ... 24
2.3.4 Frameworks ... 26
2.3.4.1 Java Server Faces (JSF) ... 27
2.3.4.2 Google Web Toolkit (GWT) ... 27
3 MÉTODO ... 29
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ... 29
3.2 ETAPAS ... 30
3.3 DELIMITAÇÕES ... 31
4 MODELAGEM DO SISTEMA ... 32
4.1 LINGUAGEM DE MODELAGEM UNIFICADA (UML) ... 32
4.2 MODELAGEM DE SISTEMAS COM ICONIX ... 32
4.2.1 Etapas do desenvolvimento ... 34
4.2.1.2 Análise e projeto preliminar ... 35
4.2.1.3 Projeto... 35
4.2.1.4 Implementação ... 35
4.2.2 Modelo de domínio ... 36
4.2.3 Modelo de casos de uso ... 36
4.2.4 Diagrama de Robustez ... 37
4.2.5 Diagrama de Seqüência ... 38
4.2.6 Diagrama de classe ... 39
4.2.7 Codificação ... 40
4.3 MODELAGEM DO SISTEMA DE COTAÇÕES ... 40
4.3.1 Processo de negócio: Cotação de combustível ... 41
4.3.1.1 Requisitos funcionais ... 42
4.3.1.2 Requisitos não funcionais ... 44
4.3.1.3 Regras de negócio ... 45
4.3.1.4 Diagrama de caso de uso do processo de cotação de combustível ... 47
4.3.1.4.1 Atores do sistema ... 48
4.3.1.4.2 Casos de uso do sistema ... 49
4.4 CONCLUSÕES DO CAPÍTULO ... 57 5 PROJETO COTAMUS ... 58 5.1 DESENVOLVIMENTO DO SISTEMA ... 58 5.2 TECNOLOGIAS E SOFTWARES ... 59 5.2.1 Softwares ... 60 5.2.2 Contexto tecnológico ... 60
5.2.2.1 Java Server Faces – JSF ... 61
5.2.2.2 Richfaces ... 61
5.2.2.3 Google Maps ... 61
5.2.2.4 Tomcat ... 62
5.2.2.5 Hibernate ... 62
5.2.2.6 PostgreSQL... 63
5.3 ESTRUTURAÇÃO DAS TELAS DO PROJETO ... 64
5.3.1 Tela principal ... 65
5.3.2 Tela do módulo de cotações de combustíveis ... 66
5.3.3 Tela de cadastro de usuários ... 67
5.3.5 Tela de cadastro e visualização de comentários ... 69
5.3.6 Função gerar nova cotação ... 70
5.4 INTERAÇÃO USUÁRIO X COTAMUS ... 70
5.5 CONCLUSÕES DO CAPÍTULO ... 76
6 CONCLUSÕES E RECOMENDAÇÕES ... 77
1 INTRODUÇÃO
A internet, criada no final da década de 1980, tinha como seu objetivo apenas garantir a comunicação entre os computadores da rede do Departamento de Defesa dos Estados Unidos da América, como um experimento militar. A partir da década de 1990 e com a ajuda da evolução dos computadores que passaram a fazer parte do cotidiano da grande parte da população mundial, a internet começou a servir como uma ótima ferramenta tanto de trabalho como de estudos para as pessoas, facilitando o acesso à informação.
A grande quantidade de informação que circula por todo o mundo através da rede mundial de computadores cria uma teia de dados e com isso perguntas são respondidas em velocidades surpreendentes e de maneiras antes inimagináveis.
Nos dias atuais, a internet começa a ser tratada como um negócio e uma das funções utilizadas pelos usuários é a busca pelo menor preço de um produto, ou seja, a pesquisa e comparação deste em vários fornecedores com o objetivo de economizar.
Este trabalho abordará o desenvolvimento de um sistema web para cotações de produtos de postos de combustíveis do tipo on-line, que segundo Jayme Teixeira Filho (2001), proporciona ao futuro comprador maior comodidade e velocidade ao pesquisar preços de produtos.
O modo de trabalho do sistema será diferente dos atuais, tais como o “Bondfaro” (www.bondfaro.com.br) e “BuscaPé” (www.buscape.com.br), pois ele utilizará os conceitos da Web 2.0 que, de modo geral, focam no desenvolvimento comunitário e na interatividade entre os usuários. Segundo Tim O’Reilly (2006), uns dos primeiros a idealizar esta nova forma de web, descreve-a da seguinte forma:
Web 2.0 é a mudança para uma internet como plataforma, e um entendimento das regras para obter sucesso nesta nova plataforma. Entre outras, a regra mais importante é desenvolver aplicativos que aproveitem os efeitos de rede para se tornarem melhores quanto mais são usados pelas pessoas, “aproveitando a inteligência coletiva”.
No decorrer do trabalho, o sistema terá uma análise de viabilidade para verificar se ele pode vir a ser útil no momento em que o usuário procura economizar em seus abastecimentos. O benefício deste sistema consiste em ter uma agilidade na atualização das informações e com os dados indexados no banco de dados teremos uma
gama de pesquisas e comparações que poderão ser realizadas com a velocidade da internet.
A interação entre as pessoas cadastradas na forma de comunidade poderá aumentar a relação entre elas, com o objetivo de gerar não só a pesquisa de preços, mas também, discussões sobre a qualidade dos produtos, marcas e demais assuntos relacionados. O sucesso do sistema será alicerçado pela quantidade de pessoas que o utilizará e pelas contribuições por elas prestadas. Quanto maior for a interação e as informações inseridas no site, maior será a quantidade de parâmetros para realizar as consultas e também ao calcular a validação dos preços inseridos pelos usuários.
1.1 OBJETIVO PRINCIPAL
Este trabalho se propõe a apresentar o projeto de um sistema na web que permita realizar cotações, buscas baseadas em parâmetros e comparações de postos de combustíveis, com um diferencial aos sites já existentes, utilizando, também os usuários como uma das fontes de atualização dos preços dos produtos.
1.2 OBJETIVOS ESPECÍFICOS:
Como objetivos específicos, pretende-se:
Estudar os conceitos e recursos da Web 2.0 para o desenvolvimento do projeto;
Apresentar a modelagem do sistema de cotações, na linguagem UML;
Aprofundar o conhecimento na linguagem de programação Java para web;
Experimentar o uso de frameworks, para a web, que auxiliam no desenvolvimento do sistema;
Implementar o sistema que exemplifica esta forma de cotação;
Utilizar os conhecimentos adquiridos no decorrer do curso de graduação.
1.3 JUSTIFICATIVA
Este tema foi escolhido devido a pouca ou nenhuma existência deste conteúdo – cotações de preços de postos de combustíveis da Grande Florianópolis com atualização comunitária - dentro dos postos da atualidade, principalmente na grande Florianópolis. O uso da inserção comunitária de preços é pouco difundido e utilizado hoje, podendo fortalecer a relação entre o produto e os compradores, além de colocar em prática a grande parte das metodologias apreendidas nas disciplinas do curso de sistemas de informação.
A realização deste sistema trará vários benefícios à comunidade, e servirá como base de pesquisa para compras, possibilitando a quem utilizá-lo economizar em suas despesas com abastecimento.
1.4 ESTRUTURA DA MONOGRAFIA
A presente monografia está organizada da seguinte forma: Capítulo 1: Introdução ao tema do trabalho;
Capítulo 2: Revisão bibliográfica dos assuntos relacionados ao contexto do projeto;
Capítulo 3: Apresentação do método de desenvolvimento do trabalho; Capítulo 4: Modelagem do sistema;
Capítulo 5: Descrição do processo de implementação e apresentação do sistema proposto;
Capítulo 7: Conclusões e recomendações para futura continuação do desenvolvimento do projeto.
2 REVISÃO BIBLIOGRÁFICA
Este capítulo aborda a revisão bibliográfica referente aos assuntos e tecnologias utilizadas no desenvolvimento do sistema de cotações de produtos baseados na web 2.0.
Esta revisão conta com os seguintes itens: Histórico do desenvolvimento da Internet; Negócio eletrônico (e-business);
Tecnologias da Web.
2.1 A INTERNET
Conforme expõe o Guia Internet de Conectividade:
A internet é um conjunto de redes de computadores interligadas pelo mundo inteiro, que têm em comum um conjunto de protocolos e serviços, de forma que os usuários a ela conectados podem usufruir de serviços de informação e comunicação de alcance mundial. (SENAC, 2000, pág. 15)
2.1.1 Internet no mundo
Segundo SENAC (2000), a história da internet se iniciou com o projeto ARPA (Advanced Research and Projects Agency) com o intuito de conectar os computadores desta agência no ano de 1969. As cidades pioneiras foram: Los Angeles, Santa Bárbara, Utah e Stanford. Durante a década de 70 seguiram-se com estudos que teve por objetivo e resultado principal a criação de um protocolo que é utilizado até hoje, denominado TCP/IP. No inicio dos anos 80, foi continuada a pesquisa do protocolo citado acima, que foi mesclada a informação com outros centros de pesquisa,
assim também inserindo o protocolo TCP/IP no sistema UNIX. No decorrer da história, temos os seguintes acontecimentos:
1985: A entidade americana National Science Foundation interligou seus computadores de centro de pesquisa criando a rede NSFNET;
1986: NSFNET é conectada a ARPANET;
1988: Grandes empresas como a IBM passaram a dar apoio a NSFNET, e formaram a associação: Advanced Network and Services (ANS);
1990: ARPANET foi desativada, e em seu lugar foi criada a DRI (Defense Research Intenet);
Entre 1991 e 1992: Foi construído o novo backbone da intenet (ANSNET); 1993: A internet começa a ser utilizada comercialmente, deixando de ser
apenas utilizado nos centros de pesquisa.
2.1.2 Crescimento da Internet no Brasil
Segundo Pinho (2000), a revolução da internet aconteceu no período entre 1995 e 1998, se tornando um dos maiores fenômenos do mercado brasileiro.
Em apenas três anos, o número de pessoas que acessam a rede mundial de suas casas e do trabalho cresceu mais de 4000%, enquanto outra novidade recente, a TV paga, experimentou desde 1995 um aumento de cerca de 100% no número de assinantes. (PINHO, 2000, pág. 74).
O gráfico a seguir demonstra o crescimento de domínios “.BR”, de acordo com o Comitê Gestor da Internet no Brasil, e nele é possível perceber que o número saltou de 851 domínios em Janeiro de 1996 para 1.934.935 em Novembro de 2009.
Figura 1 - Gráfico da evolução do número de domínios .BR Fonte - http://www.cetic.br/dominios/index.htm
2.1.3 Sobre o World Wide Web
Os autores H. M. Deitel, P. J. Deitel e K. Steinbuhler (2004) definem a tecnologia do WWW (World Wide Web) da seguinte maneira:
A World Wide Web permite a usuários de computador localizar e ver documentos multimídia (documentos com texto, gráficos, animações, áudios e/ou vídeos) sobre qualquer assunto. Embora a internet já estivesse pronta há mais de três décadas, a introdução da Word Wide Web foi um acontecimento relativamente recente. (H. M. DEITEL, P. J. DEITEL e K. STEINBUHLER (2004), pág. 5)
2.2 NEGÓCIO ELETRÔNICO (E-BUSINESS)
Os itens a seguir estão relacionados ao Negócio Eletrônico (e-business) e contam com a apresentação do conceito e das vantagens da sua utilização. Também serão apresentados os conceitos e características de comércio eletrônico e cotação on-line.
2.2.1 Conceitos e vantagens do Negócio Eletrônico
Segundo Ravi Kalakota e Marcia Robinson (2002), a definição de negócio eletrônico é “[...] o fundamento organizacional necessário para sustentar os negócios em uma economia baseada na Rede.” Eles citam também que os negócios eletrônicos não são apenas as transações de comércio eletrônico ou de compra e venda através da web, este utiliza das tecnologias atuais para redefinir os antigos modelos de negócio das organizações com o objetivo de manter-se na rede.
H. M. Deitel, P. J. Deitel e K. Steinbuhler (2004) definem e-business de modo mais objetivo como sendo uma companhia que tem presença on-line.
Além dessas definições, Fernando Rebouças (2009) cita que o e-business abrange todas as atividades de uma organização, partindo do sistema de informação interno da empresa até a utilização da web para atingir as metas comerciais e mercadológicas.
Segundo Jayme Teixeira Filho (2001) as empresas que não fizerem o uso estratégico da utilização da internet, ou seja, a aplicação do e-business nos modelos de negócio, terão problemas ao competir com as suas concorrentes. Jayme Teixeira Filho (2001) lembra: “A competição não se dá apenas entre produtos ou serviços, mas principalmente entre modelos de negócios. Os melhores e também os mais perigosos novos modelos de negócio parecem estar na Web”.
H.M. Deitel, P.J. Deitel e K. Steinbuhler (2004), falam em seu livro “E-business e e-commerce para administradores” sobre o resultado da utilização do negócio eletrônico:
O e-business e o e-commerce aumentaram a velocidade e a facilidade das transações comerciais e como resultado, a competição é intensa. [...] Instituições concorrentes precisam agora colaborar para sua mútua sobrevivência e têm de perceber que os clientes não mais precisam percorrer pontos distantes até o fornecedor seguinte. (H.M. DEITEL, P.J. DEITEL E K. STEINBUHLER (2004), pág. 7).
H. M. Deitel, P. J. Deitel e K. Steinbuhler (2004) citam que as empresas que fornecerem serviços de maneira mais confiável, funcional, conveniente e veloz serão bem-sucedidas, pois os clientes querem que a tecnologia esteja disponível 24 horas por dia e 7 dias por semana permitindo o acesso aos serviços e produtos a qualquer
momento. H. M. Deitel, P. J. Deitel e K. Steinbuhler (2004) também dizem que o modo mais fácil de proporcionar esses serviços é deslocar as operações para o sistema on-line.
Segundo Grant Norris et al. (2001), o e-business pode aumentar de maneira significativa a relação empresa-empresa e a ligação empresa-consumidor final. Grant Norris et al. (2001) também cita que o e-business tem foco na eficácia visando melhorar o serviço ao consumidor, custos reduzidos e processos de negócio otimizados.
Conforme Bartel (apud DEITEL, 2004), o e-business contém alguns dos elementos que compõe o e-commerce, mas também inclui outras informações realizadas internamente em uma organização, como por exemplo: produção, desenvolvimento, infra-estrutura corporativa e gerenciamento de produtos.
2.2.2 Comércio Eletrônico (e-commerce)
Segundo Madeira (2007), Comércio eletrônico é muito mais do que efetuar vendas através da internet, pois ele é o resultado da junção de várias tecnologias, principalmente informática e telecomunicações, que ao longo do tempo foram evoluindo e amadurecendo.
Grant Norris et al. (2001) diz que o foco do comércio eletrônico é a promover a eficácia em vendas, marketing e compras e que algumas empresas o tem como núcleo de suas atividades eletrônicas, já outras como uma parte da estratégia mais abrangente, o e-business.
Segundo Kalakota e Whinston (1997) o conceito de comércio eletrônico pode ser definido através de quatro perspectivas:
Perspectiva da comunicação: o comércio eletrônico é visto como a forma de distribuir produtos, serviços, informações ou pagamentos através da web. Perspectiva de processo comercial: comércio eletrônico é fazer uso da
tecnologia para automatizar as transações e o fluxo de trabalho.
Perspectiva de serviços: o comércio eletrônico é definido como uma ferramenta que auxilia as empresas, consumidores e administradores a suprirem as necessidades relacionadas à redução de custos e à melhoria nos níveis de qualidade e agilidade do atendimento aos clientes.
Perspectiva on-line: o comércio eletrônico é garantir a possibilidade de efetuar transações (compra e venda) de produtos e informações através da web.
De acordo com Turban (2004) pode ser acrescentado mais duas perspectivas importantes:
Perspectiva da cooperação: o comércio eletrônico é definido como um instrumento de mediação inter e intra-cooperativa em uma organização. Perspectiva comunitária: o comércio eletrônico é o ponto de encontro para
os membros de uma comunidade poderem aprender, negociar e cooperar.
São várias as formas de comércio eletrônico. Segundo Turban et al. (2004), o comércio eletrônico pode ser classificado pelo tipo de operação ou pelo relacionamento entre as partes. Os seis tipos mais comuns são:
Business-to-business (B2B): É o tipo de comércio eletrônico em que ambas as partes da negociação são empresas.
Business-to-consumer (B2C): É o comércio eletrônico em que o consumidor compra diretamente da empresa.
Consumer-to-business (C2B): Os clientes anunciam os produtos que necessitam e as empresas concorrem para fornecê-los.
Commerce-to-consumer (C2C): É o comércio eletrônico negociado entre consumidores finais.
Business-to-governement (B2G): São negócios eletrônicos entre empresa e governo.
Business-to-employee (B2E): São os sistemas que permitem que uma empresa se relacione melhor com os seus funcionários concedendo o acesso a serviços e informações.
2.2.3 Cotação on-line
Segundo Jayme Teixeira Filho (2001), as cotações de produtos feitas sem a internet utilizavam telefone e fax e tinham dois problemas: eram lentas e caras. A versão on-line desta ferramenta traz várias vantagens ao consumidor, tais como:
Redução no tempo e o valor gasto na busca do produto;
Comparação do mesmo modelo de produto em vários fornecedores; Redução do valor final gasto na finalização da compra.
Segundo o mesmo autor, a comodidade proporcionada ao cliente, com essa ferramenta, fará com que vários setores de atividades venham a utilizá-lo.
Jayme Teixeira Filho (2001) cita, ainda, que na visão do fornecedor a mudança será grande e se ele pretende sobreviver, deverá buscar inovações na questão competitiva da empresa.
2.3 TECNOLOGIAS DA WEB
Os próximos itens apresentam várias tecnologias presentes no desenvolvimento para web. Serão abordados assuntos como web 2.0, conceitos da linguagem de programação Java e seus frameworks e derivados.
2.3.1 Web 2.0
Conforme Melo (2007) há dúvidas sobre o criador do termo web 2.0, porém tudo indica que o termo foi desenvolvido por Tim O’Reilly. Melo define da seguinte forma:
Na verdade, a Web 2.0 não representa nenhuma mudança tecnológica significativa, mas uma mudança de foco. Começou uma percepção de que os Websites deveriam se integrar, deixando de ser estanques e passando a integrar conteúdo. (MELO, 2007, pág. 8).
A definição citada acima mostra que em termos de novas tecnologias a web 2.0 não veio agregar inicialmente, com certeza ao longo prazo as novas características e tecnologias foram surgindo e agregando a nova forma de fazer a web, uma integração entre todas as partes envolvidas, começando das grandes empresas até os pequenos usuários, compartilhando seus dados.
Segundo Melo (2007) houve uma grande mudança de comportamento quando se deu início à exploração de forma exponencial das redes de relacionamento, este descreve um quadro com as principais datas de lançamento:
Janeiro de 2001: Lançamento da Wikipédia (versão em inglês); Fevereiro de 2003: O serviço Blogger do Google entra no ar; Janeiro de 2004: O serviço Orkut entra no ar;
Fevereiro de 2004: O serviço Flicker;
2004: Yahoo e Google lançam seus serviços de mapas e acontece a primeira conferência sobre a Web 2.0.
O mesmo autor categoriza as características da web 2.0 da seguinte maneira:
Uso da Web como plataforma de desenvolvimento, com a integração de serviços de APIs;
Os dados são o que realmente agrega valor a um WebSite. Tudo é feito para permitir a troca de dados usando microformatos, como hCard e hAtom;
Uso extensivo de estruturas de informação, como XML ou JSON; Entrega assíncrona com o uso e Ajax;
Disponibilização de conteúdo via RSS (Syndication); Aplicações compostas por outra aplicações – Mashups;
Padrões simples e abertos, como: JSON, XML-RPC, JSON-RPC e REST.
A figura a seguir de Governor, Hinchcliffe, Nickull (2009) demonstra a evolução de alguns serviços da web 1.0 para 2.0, fazendo a demonstração da migração dos serviços que eram oferecidos e que foram substituídos:
Figura 2 – Web 1.0 versus web 2.0.
Fonte: Governor, James; Hinchcliffe, Dion; Nickull, Duane 2009. pág. 27
2.3.2 Java
Segundo Mattos (2005), Java foi criada pela Sun Microsystems na década de 90 e foi baseada no conceito de “write once, run anywhere” (Sun Microsystems) [escreva uma vez, execute em qualquer lugar]. Este conceito, segundo o autor, tem como objetivo proporcionar ao programador escrever e compilar o código apenas uma vez e, com isso, executar em qualquer plataforma que possua a máquina virtual do Java.
A máquina virtual do Java já está disponível, segundo Cattel, para várias plataformas tais como desktops, servidores, mainframes, celulares, PDAs e outros dispositivos presentes no mercado.
Segundo Sampaio (2006) uma das vantagens do Java é que ele permite reaproveitamento de código, se programado em camadas. O mesmo autor também cita que além de todas suas vantagens a principal é que o Java possui ferramentas de desenvolvimento, compilador e servidores gratuitos.
Após algum tempo da criação desta linguagem, de acordo com Mattos (2005), notou-se que um tipo de plataforma não poderia se ajustar a todos os tipos de
dispositivos então criaram-se três edições do Java, cada uma focando especificamente em uma área da informática:
Java 2 Plataform Standard Edition (J2SE): é a plataforma básica dessa tecnologia, focada no desenvolvimento para computadores pessoais e estações de trabalho.
Java 2 Plataform Enterprise Edition (J2EE): Destinada ao desenvolvimento web. Dispõe de um conjunto de serviços, interfaces de programação de aplicação (API) e outros recursos.
Java 2 Plataform Micro Edition (J2ME): focada em dispositivos com pouca quantidade de memória, capacidade de processamento e/ou vídeo.
2.3.3 Asynchronous Javascript and XML (AJAX)
O termo AJAX foi criado por Garret (apud. CABRERA, 2006) para abreviar Asynchronous Javascript + XML. Segundo o autor AJAX não é uma tecnologia, mas sim a junção de várias que estão se desenvolvendo de forma independente, mas que juntas melhoram a interação com os utilizadores das aplicações web. As tecnologias utilizadas são:
Apresentação baseada em padrões com eXtensible Hypertext Markup Language (XHTML) e Cascading Style Sheet (CSS);
Apresentação dinâmica e interação com o Documento Object Model (DOM);
Utiliza eXtensible Markup Language (XML) para a troca e manipulação de dados;
Se comunica de forma assíncrona com o servidor utilizando XMLHttpRequest;
Utiliza o JavaScript para unir essas tecnologias.
Segundo Cabrera (2006), o AJAX adiciona uma camada entre o cliente e o servidor, chamada de motor AJAX, que permite eliminar requisições feitas sem necessidade ao servidor, garantindo melhor desempenho na utilização do sistema. Para
o autor, a forma do uso do Javascript com essa tecnologia se assemelha ao conceito de Design Pattern, ou seja, da utilização deste de maneira eficiente a fim de realizar as comunicações com o servidor de modo assíncrono, com o objetivo de trazer benefícios significativos às aplicações que o implementam.
Cabrera (2006) também cita algumas características vantajosas do AJAX: Maior interatividade nas aplicações;
Redução no consumo de banda;
Redução no processamento do servidor; Não é proprietário;
Compatível com a maioria dos browsers.
Existem também algumas desvantagens da utilização do AJAX de acordo com Cabrera (2006):
Herança das limitações das tecnologias utilizadas; Muito processamento no cliente;
Exige ajustes para funcionamento dos botões “voltar” e “avançar”; Necessita de ajustes para conhecer o link para um ponto da aplicação; Latência da rede;
Requer conexão integral, por parte da aplicação estar em um servidor e outra no cliente.
Uma comparação feita entre o modelo clássico de uma aplicação web e o modelo desenvolvido com Ajax pode ser vista na figura 3.
Figura 3 – Comparação entre aplicações web com modelo clássico e com modelo AJAX Fonte: http://www.linhadecodigo.com.br/Artigo.aspx?id=1203.
2.3.4 Frameworks
Segundo Gonçalves (2008), um framework pode ser definido como um conjunto de bibliotecas que possuem funcionalidades encapsuladas e prontas para o uso que, juntas, criam uma forma mais simples de desenvolver uma tarefa.
2.3.4.1 Java Server Faces (JSF)
Gonçalves (2008) define Java Server Faces (JSF) como sendo um framework de aplicações web oficial da Sun Microsystems que foi desenhado para simplificar o desenvolvimento de aplicações para web. Gonçalves (2008) cita também que o JSF facilita, de forma simplificada, ao desenvolvedor realizar a conexão dos componentes de interface de usuário (GUI) com os objetos de negócio.
Segundo Franzini (2009) o JSF possui as seguintes características básicas: Arquitetura Model-View-Controller (MVC) – Modelo-Visão-Controle – que
padroniza as camadas de desenvolvimento das aplicações web;
Permite ao desenvolvedor a criação de interfaces para os usuários utilizando componentes pré-definidos;
Programação orientada a eventos entre as camadas de visão e o servidor; Permite a padronização de componentes entre empresas e desenvolvedores
através de modelos;
Verificação e conversão dos dados; Internacionalização;
Tratamento de erros.
2.3.4.2 Google Web Toolkit (GWT)
Segundo Bruce W. Perry (2007), o Google Web Toolkit (GWT) é definido como um framework, desenvolvido pelo Google, que gera códigos JavaScripts para programadores Java de forma eficiente.
O Google, criador deste framework, cita no site desta ferramenta (http://code.google.com/intl/pt-BR/webtoolkit/overview.html) vários conceitos e vantagens do seu uso. Segundo ele, o JavaScript gerado pelo GWT é otimizado e funciona com todos os principais navegadores disponíveis na web. No mesmo site, ainda é citado que este framework foi criado para minimizar os vários erros e problemas
encontrados no desenvolvimento de aplicações para web, além de facilitar a manutenção nos códigos JavaScript e nos componentes AJAX.
Bruce W. Perry (2007), cita os benefícios do uso deste framework: Permite o uso de qualquer IDE;
Permite desenvolver a interface gráfica baseado nos conceitos da orientação por objetos, por utilizar Java;
Remoção de grande parte dos problemas de compatibilidade com browsers, por causa do AJAX, não necessitando adaptações;
Permite gerar o código JavaScript de maneira difícil de ler, para garantir a segurança em sistemas proprietários;
Possui várias bibliotecas com componentes prontos para o uso. O Google ainda acrescenta algumas vantagens. São elas:
Otimiza o download de JavaScripts através do perfil do usuário, ou seja, são criadas várias versões da aplicação, mas apenas a que melhor se adapta ao cliente é carregada no momento da execução;
Permite o uso de JavaScript nativo e de outras bibliotecas;
Diminui significativamente os erros comuns no desenvolvimento para web; Possui suporte ao histórico do navegador (funcionamento do botão voltar e
avançar);
Reutilização de componentes em vários projetos; É um toolkit de código-fonte aberto.
3 MÉTODO
O presente capítulo tem como objetivo apresentar o método de pesquisa, as etapas e as delimitações do desenvolvimento deste trabalho.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
De acordo com Santos:
A diferença entre os trabalhos dos cientistas e o dos estudantes universitários não deveria residir no método, mas nos propósitos. Os cientistas já estão trabalhando com o intuito de promover o avanço da ciência para a Humanidade; os estudantes ainda estão trabalhando para o crescimento de sua ciência. Ambos, porém, devem trabalhar cientificamente. Os estudantes trabalham cientificamente quando realizam pesquisas dentro dos princípios estabelecidos pela metodologia científica, quando adquirem a capacidade não só de conhecer as conclusões que lhes foram transmitidas, mas se habilitam a reconstituir, a refazer as diversas etapas do caminho percorrido pelos cientistas. (SANTOS, 1999, pág. 47).
Pode-se classificar este trabalho, pela sua natureza, como sendo uma pesquisa aplicada que segundo Silva e Menezes tem como objetivo solucionar problemas específicos utilizando de uma aplicação prática.
Tendo como ponto de vista os objetivos o presente trabalho pode ser classificado em uma pesquisa exploratória que segundo Gil (apud. SILVA e MENEZES, 2005) utiliza de bibliografias, análise de exemplos e contato com pessoas que conhecem de forma prática o problema pesquisado.
Os procedimentos de coleta de dados de acordo com Antonio Raimundo dos Santos (2002) são os métodos utilizados para reunir as informações necessárias para se construir o conhecimento sobre um fato/fenômeno. Este trabalho será classificado como uma pesquisa bibliográfica, pois segundo o mesmo autor este tipo de pesquisa utiliza de materiais publicados por outros autores que podem ser livros, dicionários, enciclopédias, websites, seminários, periódicos, etc.
3.2 ETAPAS
O processo de pesquisa e construção deste projeto pode ser verificado no fluxograma abaixo:
Figura 4 – Fluxograma da metodologia de desenvolvimento do trabalho. Fonte: Elaboração dos autores, 2009.
1- Pesquisa e estudo das tecnologias existentes;
2- Desenvolvimento intrínseco da revisão bibliográfica; 3- Desenvolvimento da modelagem do sistema;
4- Estudo das linguagens de programação para web existentes e das ferramentas de apoio ao desenvolvimento;
5- Implementação dos módulos do sistema; 6- Análise e criação da interface protótipo;
7- Análise da viabilidade do sistema na comunidade;
3.3 DELIMITAÇÕES
O sistema de cotações web a ser apresentado tem como principal função informar ao usuário o melhor lugar para ele realizar suas compras ou abastecer o seu automóvel, de forma colaborativa, levando em consideração fatores definidos na busca, tais como localização, volume, preferências de estabelecimentos, entre outros a serem apresentados no decorrer do trabalho.
Com a intenção de atingir todos os objetivos deste trabalho, ficam definidas as seguintes limitações:
O sistema web abordará apenas a cotação de produtos de postos de combustíveis;
O protótipo foi construído apenas com os módulos de cotação de combustíveis, registro de comentários para os estabelecimentos, cadastro de usuários, autenticação, qualificação de cotação, rotas e busca do melhor lugar para a compra;
Não são objetos deste trabalho o desenvolvimento e a criação de novas tecnologias.
4 MODELAGEM DO SISTEMA
Neste capítulo é abordada a modelagem do sistema e os conceitos que foram utilizados para o desenvolvimento deste, tais como linguagens, diagramas, requisitos e regras de negócio. Segundo Bezerra:
[...] certamente, o desenvolvimento de um sistema envolve a execução de uma quantidade significativa de atividades. Essas atividades se traduzem em informações sobre o sistema em desenvolvimento. Grande parte dessas informações corresponde aos modelos criados para representar o sistema. Neste sentido, os modelos de um sistema servem também para promover difusão de informações relativas ao sistema entre os indivíduos envolvidos em sua construção. (BEZERRA, 2002, p.4).
4.1 LINGUAGEM DE MODELAGEM UNIFICADA (UML)
O presente sistema teve a sua modelagem de processos descrita na linguagem de modelagem UML (Unified Modeling Language), na versão 2.1.2.
De acordo com Bezerra:
A UML é uma linguagem visual para modelar sistemas orientados a objeto. Isso quer dizer que a UML é uma linguagem constituída de elementos gráficos (visuais) utilizados na modelagem que permitem representar os conceitos do paradigma da orientação a objetos. Através dos elementos gráficos definidos nesta linguagem pode-se construir diagramas que representam diversas perspectivas de um sistema. (BEZERRA, 2002, p.14).
4.2 MODELAGEM DE SISTEMAS COM ICONIX
Para que o desenvolvedor possa fazer um bom trabalho em um sistema complexo, ele deve examinar o projeto sobre diversas perspectivas, como diz Bezzera (2002). O mesmo autor descreve as visões existentes para um bom desenvolvimento de sistema conforme abaixo:
Visão de Casos de Uso: descreve o sistema e um ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos ao sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das outras visões do sistema.
Visão de Projeto: enfatiza as características do sistema que dão suporte, tanto estrutural quanto comportamental, às funcionalidades externamente visíveis do sistema.
Visão de Implementação: corresponde à distribuição física do sistema em seus subsistemas e à conexão entre essas partes.
Visão de Processo: esta visão enfatiza as características de concorrência (paralelismo), sincronização e desempenho do sistema. (BEZERRA, 2002, p. 15).
A sua confiança em práticas que trabalhar com ambos no curto prazo instintos de programadores e os interesses de longo prazo do projeto. (BECK, 2004, pág. 17)
O método de modelagem utilizado foi o ICONIX que segundo Silva et al, (2007) é um processo de desenvolvimento de software prático, simples e que possui um ótimo componente de representação juntamente com análise dos problemas através de modelagem UML.
Segundo Maia (2005), o processo de desenvolvimento ICONIX é dividido em dois setores que podem ser desenvolvidos em paralelo e de modo recursivo. São eles o modelo estático e o dinâmico como pode ser visto na figura 5.
Figura 5 – Visão macro do ICONIX Fonte: Maia, 2005
Maia (2005) cita que o modelo estático é formado pelos diagramas de domínio e pelo diagrama de classe, pois fazem parte da modelagem do funcionamento
do sistema, mas não possuem a interação e dinamismo do usuário final. Já o modelo dinâmico conta com a interação do usuário onde o sistema apresenta a ele respostas em tempo de execução.
4.2.1 Etapas do desenvolvimento
O processo de desenvolvimento de software ICONIX, segundo Rosenberg e Scott(1999), possui quatro etapas consideradas principais, são elas:
Análise de requisitos;
Análise e projeto preliminar; Projeto;
Implementação.
4.2.1.1 Análise de requisitos
Segundo Videira e Silva (2001), a etapa de análise de requisitos é composta pelas seguintes atividades:
Através de modelo definir os casos de uso do sistema, incluindo todos os atores;
Entregar ao cliente um protótipo para um melhor entendimento do sistema sempre que possível;
Utilizar o diagrama de pacotes para os casos de uso;
Associar os requisitos funcionais aos objetos de domínio e também aos casos de uso.
4.2.1.2 Análise e projeto preliminar
Segundo o mesmo autor, as atividades que compõe a análise esta etapa são: Apresentar o fluxo principal das ações e descrever os casos de uso;
Atualizar o diagrama de classes.
4.2.1.3 Projeto
A etapa projeto é composta pelas seguintes atividades: Verificar se todos os requisitos foram atendidos no projeto; No diagrama de classes colocar as especificações gerais; Exibir de modo detalhado as regras no diagrama de seqüência
4.2.1.4 Implementação
A etapa de implementação conta com as seguintes atividades: Desenvolver a codificação do sistema;
Obter a aprovação dos usuários do mesmo; Executar o teste de integração do sistema.
Os principais diagramas que compõe ICONIX são: Modelo de domínio;
Modelo de casos de uso; Diagrama de robustez; Diagrama de seqüência; Diagrama de classe.
4.2.2 Modelo de domínio
O modelo de domínio é muito importante no processo ICONIX, segundo Maia (2005). Ele constrói um modelo estático que é essencial para dar o início ao desenvolvimento dos casos de uso.
Este modelo consiste, basicamente, em descobrir objetos de um problema do mundo real, mas como esta tarefa necessita de muita abstração, o treinamento e a experiência tornam-se essenciais para agilizar e facilitar o desenvolvimento.
O mesmo autor ainda cita que este modelo não apresentará o cenário completo adequado para o problema a ser resolvido, com o tempo algumas classes serão excluídas e outras serão encontradas ou modificadas, pois isso faz parte do processo de desenvolvimento de softwares.
Figura 6 – Exemplo de modelo de domínio Fonte: Maia, 2005.
4.2.3 Modelo de casos de uso
Este modelo, segundo Maia (2005), é usado para representar as exigências do usuário para um sistema novo ou para um sistema já existente. Ele deve detalhar de forma clara e legível, todos os cenários que os usuários utilizarão para realizar alguma tarefa. Um exemplo pode ser visto na figura 7.
Figura 7 – Diagrama de caso de uso Fonte: Maia, 2005.
4.2.4 Diagrama de Robustez
O objetivo desta etapa, segundo Maia (2005), é ligar a parte de análise com a parte de projeto e ainda, como pode ser visto na figura 8, certifica que as descrições dos casos de uso estejam corretas ou se precisam de novos objetos.
Figura 8 – Conexão da fase de análise com a fase de design Fonte: Maia, 2005
O principal foco desta análise é construir um modelo com base nas narrativas de texto de casos de uso, identificando o conjunto de objetos que serão utilizados em cada um destes casos de uso. Estes objetos podem ser classificados em três tipos, de acordo com Maia (2005), como pode ser observado na figura 9.
Figura 9 – Representação dos objetos interface, controlador e entidade Fonte: Maia, 2005
A figura 10 apresenta um diagrama de robustez completo para melhor entendimento do uso dos objetos.
Figura 10 – Exemplo de diagrama de robustez Fonte: Maia, 2005
4.2.5 Diagrama de Seqüência
Segundo Maia (2005), o objetivo principal do diagrama de seqüência é construir um modelo dinâmico entre o usuário e o sistema. Para atingir este objetivo deve-se utilizar os objetos do diagrama de robustez, mas agora com o detalhamento de cada fluxo de ação. Um exemplo de diagrama de seqüência pode ser visto na figura 11.
Figura 11 – Exemplo de diagrama de seqüência Fonte: Maia, 2005
4.2.6 Diagrama de classe
Composto pelas funcionalidades do modo estático, por não contar com a interação do usuário com o sistema, o diagrama de classe é o modelo de domínio que sofreu alterações durante as fases do ICONIX, de acordo com Maia (2005). A figura 12 apresenta um exemplo de um diagrama de classe.
Figura 12 – Exemplo de diagrama de classe Fonte: Maia, 2005
4.2.7 Codificação
Segundo Maia (2005), a fase de codificação não faz parte da área de análise do ICONIX, que a considera subjetiva para o desenvolvimento correto do sistema a ser construído. Esta fase é composta pelo desenvolvimento correto com base nos artefatos construídos para um produto de software estruturado e válido. Este produto deve atender a todos os requisitos e refletir todas as funcionalidades identificadas no desenvolvimento dos diagramas.
O mesmo autor ainda cita que como qualquer tarefa de codificação, uma bateria de testes é necessária para confirmar que todas as operações e os resultados desejados foram atendidos.
4.3 MODELAGEM DO SISTEMA DE COTAÇÕES
A modelagem do Cotamus utilizou do diagrama de pacotes para dividir os seus módulos. O objetivo do uso foi separar os módulos que possuem focos distintos. O diagrama pode ser visto na figura 13.
Figura 13 – Diagrama de pacotes Fonte: Elaboração dos autores, 2010
Foi abordado neste trabalho o processo de negócio considerado fundamental para o funcionamento do sistema, ele faz parte do pacote “Combustíveis” e referencia o módulo de cotação de combustíveis.
Este processo de negócio contará com os diagramas de caso de uso e suas descrições, diagrama de robustez, diagrama de seqüência, requisitos funcionais, não-funcionais, regras de negócio e o diagrama do processo.
4.3.1 Processo de negócio: Cotação de combustível
Este é o principal processo do sistema. A função dele é permitir ao usuário buscar e atualizar o preço de um determinado produto e por conseqüência compartilhar com todos os demais usuários do sistema. O diagrama do processo pode ser visualizado na figura 14.
Figura 14 – Diagrama do processo de cotação de combustível. Fonte: Elaborado pelos autores, 2010.
4.3.1.1 Requisitos funcionais
Segundo Paula Filho (2001), os requisitos funcionais apresentam as funções que o produto deverá prover para beneficiar o usuário, ou seja, as funcionalidades do software são definidas através deles.
Macoratti (2006) diz que um bom requisito funcional deve possuir as seguintes características:
ser claro e não-ambíguo; ser completo;
se correto;
ser consistente; ser conciso; ser confiável.
O quadro 1 apresenta os requisitos funcionais do processo de Cotação de combustível.
Nome: RF01 - Cadastro de usuários («Funcional»)
Descrição: O sistema deverá prover funcionalidade que permita ao usuário gerenciar os seus dados
Nome: RF02 - Cadastrar produtos («Funcional»)
Descrição: O sistema deverá prover funcionalidade que permitam ao usuário cadastrar produtos / itens para cotação
Nome: RF03 - Comentário/opinião sobre estabelecimento («Funcional»)
Descrição: O sistema deve permitir ao usuário cadastrar e visualizar comentários/opiniões sobre os estabelecimentos
Nome: RF03 - Filtro de cotações («Funcional»)
Descrição: O sistema deverá prover funcionalidade que permita ao usuário filtrar os resultados das cotações por:
- Faixa de preço
- Nome de estabelecimento - Bandeira de fornecedor - Qualificação
Nome: RF04 - Ordenação de cotações («Funcional»)
Descrição: O sistema deverá permitir ao usuário ordenar as cotações dos produtos por:
- menor preço
- preço mais confiável - menor distância
- nome do estabelecimento
Nome: RF05 - Busca de melhor cotação («Funcional»)
Descrição: O sistema deverá permitir ao usuário encontrar de forma rápida a melhor cotação de acordo com o produto necessitado levando em consideração os fatores:
- distância - preço
- km/l do seu veículo - valor a ser abastecido
Nome: RF06 - Endereço de origem e favorito («Funcional»)
Descrição: O sistema deve permitir ao usuário definir um endereço de origem e/ou um endereço favorito para as rotas aos estabelecimentos
Nome: RF07 - Rotas («Funcional»)
Descrição: O sistema deve prover a funcionalidade de criação de rotas aos estabelecimentos
Nome: RF08 - Qualificação de cotação («Funcional»)
Descrição: O sistema deve permitir ao usuário autenticado qualificar a cotação de um produto como confiável ou não
Nome: RF09 - Autenticação de usuário ( «Funcional»)
Descrição: O sistema deverá prover funcionalidades que permita ao usuário autenticar-se no sistema, alterar seus dados e fechar a sua conta
Quadro 1 – Especificação dos requisitos funcionais do processo de cotação de combustível Fonte: Elaboração dos autores, 2010.
4.3.1.2 Requisitos não funcionais
Segundo Paula Filho (2001), os requisitos não funcionais são compostos pelos requisitos de desempenho e atributos de qualidade do produto que representam o comportamento e as restrições que este deve atender.
No quadro 2 pode-se visualizar os requisitos não funcionais do processo de cotação de combustível.
Nome: RNF01 - Plataforma de Desenvolvimento ( «Não Funcional») Descrição: O sistema deverá ser desenvolvido em plataforma JAVA 1.6.
Categoria: Sistema
Nome: RNF02 - Desempenho das Consultas ( «Não Funcional»)
Descrição: As consultas realizadas no sistema deverão ter o seu resultado disponível em até 5s.
Categoria: Sistema
Nome: RNF03 - Identidade Visual ( «Não Funcional»)
Descrição: As cores e fontes utilizadas no sistema deverão obedecer a um template. Categoria: Interface
Nome: RNF04 - Botões de navegação («Não Funcional»)
Descrição: Toda interface deverá possuir botões de acesso aos módulos do sistema Categoria: Interface
Nome: RNF05 - Segurança da informação («Não Funcional»)
Descrição: Toda senha de usuário devera ser criptografada no algoritmo SHA512 Categoria: Sistema/Segurança
Nome: RNF06 - Definição de Banco de Dados («Não Funcional») Descrição: O banco de dados deverá ser o PostgreSQL
Categoria: Sistema
Nome: RNF07 - Ícones ( «Não Funcional»)
Descrição: Os botões mais utilizados devem conter ícones para facilitar ao usuário diferenciá-los, muitas vezes sem ter que ler.
Categoria: Interface
Nome: RNF08 - Browser padrão ( «Não Funcional»)
Descrição: O sistema deverá ter suas funcionalidades e usabilidade nos browsers Microsoft Internet Explorer 8,Firefox, Safari, Opera e Chrome.
Categoria: Sistema
Nome: RNF09 - Mensagens de erro e aviso ( «Não Funcional»)
Descrição: Toda mensagem de erro e aviso deverá ser mostrada ao usuário de maneira legível e fácil de entender.
Categoria: Interface
Nome: RNF10 - Ajax («Não Funcional»)
Descrição: O sistema deve realizar a maioria de suas requisições utilizando Ajax para evitar processamento desnecessário.
Categoria: Sistema/Interface Quadro 2 – Especificação dos requisitos não funcionais Fonte: Elaboração dos autores, 2010
4.3.1.3 Regras de negócio
Segundo Larman (2007), regras de negócio são requisitos ou políticas de um projeto de software. Estas regras definem as particularidades do negócio e como o produto deve funcionar
O quadro 3 apresenta as regras de negócio do processo de cotação de combustível.
Nome: RN01 - Cadastro de Perfil («Regra Negócio») Descrição: Para realizar cotações, o usuário deve estar cadastrado
Nome: RN02 - Campos para o cadastro de usuários («Regra Negócio») Descrição: Para o cadastro de usuários deverão ser fornecidas as seguintes
informações: Campos obrigatórios: - nome - sobrenome - email - login - senha Campos opcionais: - endereço favorito - média de km/l do automóvel
Nome: RN03 - Campos para o cadastro de estabelecimentos («Regra Negócio»)
Descrição: Os estabelecimentos devem possuir os seguintes dados, obrigatoriamente:
- nome - endereço - logomarca Opcionais:
- no caso de postos de combustíveis os indicadores de: - borracharia
- conveniência - 24 horas
Todo posto de combustível deve possuir pelo menos um tipo de combustível.
Nome: RN04 - Sugestão de valor do produto («Regra Negócio»)
Descrição: O produto deve estar previamente cadastrado no Sistema, assim como o usuário que fará a sugestão do valor. O novo valor deve ser verificado antes da inclusão no sistema e não poderá ser igual ao último inserido. Nome: RN05 - Login de usuário em mais de um dispositivo («Regra
Negócio»)
Descrição: Um usuário poderá estar autenticado em mais de um dispositivo ao mesmo tempo
Nome: RN06 - Criação de rotas («Regra Negócio»)
Descrição: Para criar rotas o usuário do sistema deverá possuir um endereço favorito, caso esteja autenticado, ou definir um endereço de origem. O usuário não precisará estar autenticado para utilizar o sistema de rotas.
Nome: RN07 - Cadastro de comentários («Regra Negócio»)
Descrição: Para comentar um produto ou estabelecimento o usuário deverá estar autenticado
Nome: RN08 - Exclusão de usuário («Regra Negócio»)
Descrição: Um usuário nunca poderá ser excluído fisicamente da base de dados, por motivos de integridade das cotações. Ele apenas ficará como inativo. Nome: RN09 - Campos para busca por melhor cotação («Regra Negócio») Descrição: A busca da melhor cotação necessita que o usuário informe a quantidade
de km/l que o seu automóvel faz, que ele esteja autenticado no sistema, que exista um endereço de origem e que ele informe o valor que deseja abastecer.
Quadro 3 – Definição das regras de negócio do processo de cotação de combustíveis. Fonte: Elaboração dos autores, 2010.
4.3.1.4 Diagrama de caso de uso do processo de cotação de combustível
O diagrama de casos de uso apresenta as funcionalidades do sistema e os atores que as utilizam. O processo de cotação de combustíveis é formado pelos casos de uso apresentados na figura 15.
Figura 15 – Diagrama de casos de uso do processo de cotação de combustível Fonte: Elaboração dos autores, 2010
4.3.1.4.1 Atores do sistema
Os atores são entidades externas que interagem com o sistema por meio de casos de uso. Segundo Paula Filho (2001), a identificação dos atores ajuda a identificar os casos de uso relevantes além de ser o ponto de partida para a especificação das interfaces.
Paula Filho (2001, p. 65) ainda cita “pode ser útil também definir atores não humanos, para modelar outros sistemas que devam interagir com o produto em questão”.
Na figura 16 são apresentados os atores deste módulo do sistema e no quadro 3 a descrição destes.
Figura 16 – Atores do processo de cotação de combustível Fonte: Elaboração dos autores, 2010
NOME DO ATOR: Administrador
DEFINIÇÃO: Indivíduo que administra o sistema FREQÜENCIA DE USO: Constante
CONHECIMENTO EM INFORMÁTICA: conhecimento avançado de informática GRAU DE ESCOLARIDADE: Ensino médio à superior
PERMISSÕES DE ACESSO: terá acesso a todos os módulos do sistema e poderá fazer a administração do mesmo. Poderá cadastrar novos postos de combustíveis e suas funcionalidades, moderar os usuários e mensagens postadas.
NOME DO ATOR: Usuário
DEFINIÇÃO: Indivíduo que utiliza qualquer função do sistema FREQÜENCIA DE USO: Esporádico
CONHECIMENTO EM INFORMÁTICA: conhecimento básico de informática GRAU DE ESCOLARIDADE: Ensino médio à superior
PERMISSÕES DE ACESSO: só não possuirá acesso ao módulo administrativo e só poderá cotar os produtos e comentar sobre os estabelecimentos se estiver autenticado no sistema.
Quadro 4 – Características dos autores Fonte: Elaboração dos autores, 2010
4.3.1.4.2 Casos de uso do sistema
Este item conta com a descrição completa dos casos de uso “Busca de melhor cotação” e “Cotar combustível”, do processo de cotação de combustíveis.
4.3.1.4.2.1 Busca de melhor cotação
Este caso de uso tem como objetivo encontrar a melhor cotação de um produto para os usuários. Ela é composta por um algoritmo que utiliza de fatores fundamentais para a seleção da melhor cotação. Os fatores fundamentais são a distancia do usuário ao estabelecimento, a taxa média de consumo por litro do seu automóvel e o valor da cotação.
A descrição deste processo pode ser visto abaixo e o seu diagrama de caso de uso na figura 17.
Iniciado por: Usuário.
Pré-condições:
Escolha de um produto;
Definição de endereço de origem;
Definição de média de km/l do automóvel. Fluxo principal:
Usuário escolhe o produto a ser buscado; Clica na opção “Buscar melhor cotação”; O sistema analisa o endereço de origem;
O sistema analisa a média de km/l do automóvel do usuário; O sistema solicita qual o valor total que o usuário deseja abastecer; O sistema executa o algoritmo de busca de melhor cotação.
Fluxo alternativo:
Cliente não informou endereço de origem, o sistema solicita o endereço; Cliente não informou a média de quilometro por litro, o sistema solicita esta informação.
Pós-condições:
Apresenta a melhor cotação ao usuário.
Diagrama de caso de uso do processo de busca de melhor cotação
Figura 17 – Diagrama de caso de uso de busca da melhor cotação. Fonte: Elaboração dos autores, 2010.
Este caso de uso apresenta a busca da melhor cotação baseado nos parâmetros informados pelo usuário, sendo estes o seu endereço, o produto e a média de quilômetros por litro do seu automóvel. Caso alguma das informações não tenha sido informada o sistema solicita o seu preenchimento. O usuário pode definir o endereço de origem antes de utilizar a opção “Buscar melhor cotação”.
Diagrama de atividades do caso de uso Busca de melhor cotação
O diagrama de atividades apresentado na figura 18 representa o fluxo da busca da melhor cotação de combustível, tendo como ponto de partida a vista do usuário do sistema. Este processo inicia quando o usuário seleciona um produto e clica na opção buscar melhor cotação, caso o endereço ou a média de quilômetros por litro do seu automóvel não tenha sido informado, o sistema solicita o seu preenchimento, solicita o valor total desejado a abastecer, busca as cotações e executa o algoritmo que é composto de uma formula que encontra a melhor cotação em relação a custo benefício.
Figura 18 – Diagrama de atividades da busca de melhor cotação. Fonte: Elaboração dos autores, 2010.
Diagrama de robustez do caso de uso Busca de melhor cotação
O diagrama de robustez apresentado na figura 19 representa o usuário executando o processo de busca de melhor cotação. Este diagrama ainda tem como objetivo permitir o entendimento da ligação que existe entre as camadas de modelo, controle e visão.
Figura 19 – Diagrama de robustez da busca de melhor cotação. Fonte: Elaboração dos autores, 2010.
Diagrama de seqüência do caso de uso Busca de melhor cotação
O diagrama de seqüência apresentado na figura 20 representa a interação entre o ator e as solicitações às classes e aos objetos passando pelas camadas do sistema. Este diagrama é baseado na linha do tempo, portando as setas indicam as solicitações e respostas.
Figura 20 - Diagrama de seqüência do caso de uso Busca de melhor cotação. Fonte: Elaboração dos autores, 2010.
4.3.1.4.2.2 Cotar combustível
O caso de uso Cotar combustível tem o objetivo de permitir aos usuários atualizar o valor de determinado produto de um estabelecimento.
A descrição deste processo pode ser vista a seguir.
Iniciado por: Usuário.
Pré-condições:
O usuário deve estar autenticado no sistema; Um produto deve ser escolhido.
Fluxo principal:
O usuário efetua login no sistema; Escolhe produto;
Clica em “Cotar”;
Informa o valor atualizado; O sistema analisa o valor;
O sistema insere uma nova cotação. Fluxo alternativo:
Usuário informou valor inválido, o sistema solicita um novo valor. Usuário não está autenticado, o sistema solicita login ou cadastro. Pós-condições:
Diagrama de caso de uso do processo de cotar combustível
Figura 21 – Diagrama de caso de uso de Cotar Combustível Fonte: Elaboração dos autores, 2010.
O presente caso de uso, visualizado na figura 21, inicia pela seleção do produto, seguindo para a informação do valor. Além disto, também é realizada análise de valores tendo como fim a geração de uma nova cotação.
Diagrama de atividades do caso de uso Cotar combustível
A figura 22 permite visualizar o diagrama de atividades do caso de uso Cotar Combustível. Nota-se nela que é necessário o usuário estar autenticado no sistema para proceder com o processo de cotação. Após escolher o produto o usuário informa o valor e se este não for válido o sistema emite uma mensagem de erro, caso contrário gera uma nova cotação e apresenta uma mensagem de confirmação.
Figura 22 – Diagrama de atividades de Cotar de combustíveis Fonte: Elaboração dos autores, 2010.
Diagrama de robustez do caso de uso Cotar combustível
O diagrama de robustez do caso de uso Cotar combustível pode ser visualizado na figura 23. Este caso de uso apresenta as camadas de interação do usuário, seguidas pela camada de controle e por fim chegando às regras de negócio e à camada modelo.
Figura 23 – Diagrama de robustez de Cotar Combustível. Fonte: Elaboração dos autores, 2010.
Diagrama de seqüência do caso de uso Cotar combustível
O diagrama de seqüência do caso de uso Cotar combustível representa o usuário interagindo com o sistema através das requisições feitas aos objetos e camadas do sistema. A figura 24 apresenta este diagrama graficamente e facilita o entendimento deste processo.
Figura 24 – Diagrama de seqüência do caso de uso cotar combustível. Fonte: Elaboração dos autores.
4.4 CONCLUSÕES DO CAPÍTULO
Notou-se neste capítulo que a modelagem do sistema é um pilar para o trabalho descrito, sem este instrumento de informação não seria possível de se modelar e dimensionar o projeto em si.
Foram apresentados também os conceitos e definições sobre modelagem, requisitos e diagramas do processo de Cotação de combustíveis, além de constatar que a inclusão da linguagem UML e do processo de desenvolvimento ICONIX remete a utilização de ferramentas que na conclusão e desenvolvimento do projeto evitam erros e conseqüentemente um menor tempo de execução e melhor planejamento do projeto.
