SOFTWARE DE GERENCIA MENTO DE AUTOPEÇAS · Gerenciamento de Autopeças (SGA) was partly developed....
Transcript of SOFTWARE DE GERENCIA MENTO DE AUTOPEÇAS · Gerenciamento de Autopeças (SGA) was partly developed....
FACULDADE DE CIÊNCIAS APLICADAS DE MINASAutorizada pela Portaria no 577/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO
SOFTWARE DE GERENCIA
EDUARDO STUART RODRIGUES DE VASCONCELOS
LEONARDO LUCIO CARVALHO OLIVEIRA
JHARBAS ARAUJO RODRIGUES
MÁRIO LÚCIO DE ARAÚJO BRUM
FACULDADE DE CIÊNCIAS APLICADAS DE MINASAutorizada pela Portaria no 577/2000 – MEC, de 03/05/2000BACHARELADO EM SISTEMAS DE INFORMAÇÃO
SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS
DAIANE LOPES SILVA
EDUARDO STUART RODRIGUES DE VASCONCELOS
EVERTON ALVES CUNHA
LEONARDO LUCIO CARVALHO OLIVEIRA
LEONARDO CESAR BRITO
JHARBAS ARAUJO RODRIGUES
MÁRIO LÚCIO DE ARAÚJO BRUM
SALGER LUIS DE OLIVEIRA
Uberlândia
2010/1
FACULDADE DE CIÊNCIAS APLICADAS DE MINAS MEC, de 03/05/2000
MENTO DE AUTOPEÇAS
EDUARDO STUART RODRIGUES DE VASCONCELOS
DAIANE LOPES SILVA
EDUARDO STUART RODRIGUES DE VASCONCELOS
EVERTON ALVES CUNHA
LEONARDO LUCIO CARVALHO OLIVEIRA
LEONARDO CESAR BRITO
JHARBAS ARAUJO RODRIGUES
MARIO LUCIO DE ARAUJO BRUM
SALGER LUIS DE OLIVEIRA
SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
Orientador: Prof. Esp. Márcio Aurélio
Ribeiro Moreira
Uberlândia
2010/1
DAIANE LOPES SILVA
EDUARDO STUART RODRIGUES DE VASCONCELOS
EVERTON ALVES CUNHA
LEONARDO LUCIO CARVALHO OLIVEIRA
LEONARDO CESAR BRITO
JHARBAS ARAUJO RODRIGUES
MARIO LUCIO DE ARAUJO BRUM
SALGER LUIS DE OLIVEIRA
SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS
Trabalho de Final de curso submetido à
UNIMINAS como parte dos requisitos para
a obtenção do grau de Bacharel em
Sistemas de Informação.
Orientador: Prof. Esp. Márcio Aurélio R.
Moreira
Uberlândia, 06 de Junho de 2010.
Banca Examinadora:
Prof. Esp. Márcio Aurélio Ribeiro Moreira (Orientador)
Prof. Esp. Carlos Henrique de Barros
Prof. Msc. Edson Angoti
Uberlândia
2010/1
A nossa família pela força e costumeira atenção.
AGRADECIMENTOS
A todos os professores pela experiência passada a nós e em especial ao professor
Márcio Aurélio Ribeiro Moreira pela atenção e grande suporte a este trabalho de
conclusão, e ao professor Carlos Henrique de Barros pelo auxílio do desenvolvimento
do projeto durante o curso. Aos familiares pela confiança e motivação. Aos
companheiros de sala pela amizade e confiança, pois sem os quais não seria
possível a elaboração deste trabalho.
RESUMO
O objetivo deste projeto é a modelagem e desenvolvimento de um sistema de
autopeça, tendo como parceiro a empresa Universo Autopeças, situada na cidade
de Uberlândia. Com o levantamento das necessidades no parceiro foi proposto um
sistema, cujo sua documentação foi baseada nos conhecimentos adquiridos no
curso. Nessa fase foi de extrema importância o uso da UML (Unified Modeling
Language), para mostrar de maneira clara e consistente como foi implementado o
sistema, através de seus principais diagramas. Fizemos o uso de uma arquitetura
voltada para web, que se propõe a implementar o modelo MVC (Model-View-
Controller) através do framework Apache Struts2 e realizar a persistência de dados
utilizando-se do framework Hibernate, arquitetura na qual trabalhamos com
Enterprise JavaBeans (EJB) e páginas JSP. O Sistema de Gerenciamento de
Autopeças (SGA) foi desenvolvido parcialmente. Foram escolhidos alguns casos de
uso, com a intenção de demonstrar a capacidade de atender as demandas,
utilizando as teorias necessárias.
Palavras Chave: autopeça, gestão comercial, sistema, software, UML,
JSP, MVC, JDBC, JavaBeans, arquitetura web, Apache Struts2, Hibernate, EJB3,
JBoss.
ABSTRACT
This projects goal is to model and develop a auto part software, having as partner
Universo Autopecas, located in Uberlandia. From the gathering of client’s needings,
was proposed a sistem, whose documentation was based in the knowledge aquired
on the course. In this stage, using UML (Unified Modeling Language), though its
diagrams, was very important to show by a simple and consistent way how the
system was implemented. We made a web-oriented architecture, that propose to
implement the MVC (Model-View-Controller) model though Apache Struts 2
framework and to persist by using Hibernate framework. In this architecture we
worked with Enterprise JavaBeans (EJB) and JSP pages. The Sistema de
Gerenciamento de Autopeças (SGA) was partly developed. Some case uses was
choosen, on the intention to show the capacity to answer demands, using the
necessaries teories.
Key words: auto parts comercial management, system, software, UML,
JSP, MVC, JDBC, JavaBeans, web architecture, Apache Struts2, Hibernate, EJB3,
JBoss.
LISTA DE FIGURAS
Figura 1 - Diagrama de Casos de Uso ___________________________________________________________ 29
Figura 2 - Diagrama de classes ________________________________________________________________ 42
Figura 3 – Diagrama de Sequencia do Caso de Uso Manutenção de Clientes ____________________________ 44
Figura 4 - Diagrama de Seqüência do Caso de Uso Manutenção de Funcionários ________________________ 45
Figura 5 - Diagrama de Seqüência do Caso de Uso Manutenção de Fornecedores _______________________ 46
Figura 6 - Diagrama de Seqüência do Caso de Uso Manutenção de Produtos ___________________________ 47
Figura 7 - Diagrama de Seqüência do Caso de Uso Efetuar Login _____________________________________ 48
Figura 8 - Sistema de Banco de Dados __________________________________________________________ 52
Figura 9 - Esquema de níveis __________________________________________________________________ 60
Figura 10 - Crescimento da tecnologia e da demanda por informação _________________________________ 61
Figura 11 - Abordagem centralizada ____________________________________________________________ 64
Figura 12 - Abordagem distribuída _____________________________________________________________ 65
Figura 13 - Diagrama Entidade e Relacionamento - DER ____________________________________________ 69
Figura 14 - Anotações dos atributos ____________________________________________________________ 75
Figura 15 - Anotação chave estrangeira _________________________________________________________ 76
Figura 16 - Anotação relacionamento ___________________________________________________________ 76
Figura 17 - Construtor Entidade _______________________________________________________________ 78
Figura 18 - Consulta utilizando API Criteria ______________________________________________________ 79
Figura 19 - Annotations ______________________________________________________________________ 79
Figura 20 - Tela de cadastro de clientes _________________________________________________________ 84
Figura 21 - Erro tratamento CPF _______________________________________________________________ 85
Figura 22 - Mensagem de cliente cadastrado _____________________________________________________ 85
Figura 23 - Controle remoto ____________________________________________ Erro! Indicador não definido.
Figura 24 - Menu da tela inicial ________________________________________________________________ 87
Figura 25 - Estrutura do menu do sistema _______________________________________________________ 89
Figura 26 - Código para implementar o Interceptor no struts.xml _______________ Erro! Indicador não definido.
Figura 27 - Código cadastrarCliente.jsp _________________________________________________________ 90
Figura 28 - Tela inicial do WebService ___________________________________________________________ 91
Figura 29 - Relatório de clientes cadastrados _____________________________________________________ 91
Figura 30 - Código do interceptor criando sessão __________________________________________________ 92
Figura 31 - Tela inicial do sistema ______________________________________________________________ 92
Figura 32 - Código da página telaInicial.jsp ______________________________________________________ 93
Figura 33 - Menu de cliente ___________________________________________________________________ 93
Figura 34 - As três camadas lógicas de um sistema em camadas. (Adaptado de Sommerville, 2003, p.209) ___ 96
Figura 35 - O padrão MVC. (Adaptado de Pressman, 2006, p.443) ____________________________________ 98
Figura 36 - Framework Struts 2. (Fonte: Roughley, 2006, p.11) ______________________________________ 100
Figura 37 - Enfoque em camadas. (Adaptado de Alur, Crupi e Malks, 2004, p.102) ______________________ 103
Figura 38 - O contêiner web (Adaptado de Todd e Szolkowski,2003, p.10) _____________________________ 106
Figura 39 - A estrutura de uma aplicação Web. (Adaptado de Todd e Szolkowski, 2003, p.90) _____________ 107
Figura 40 - Arquitetura do sistema SGA ________________________________________________________ 108
Figura 41 - Diagrama de pacotes do software SGA _______________________________________________ 111
Figura 42 - Diagrama de classes de projeto do caso de uso Manutenção de Clientes ____________________ 112
Figura 43 - Diagrama de distribuição do software SGA ____________________________________________ 113
LISTA DE QUADROS
Quadro 1 - Requisitos do sistema ______________________________________________________________ 27
Quadro 2 - Regra de negócio RN – 02 ___________________________________________________________ 28
Quadro 4 – Regra de negócio RN – 03 __________________________________________________________ 28
Quadro 5 - Regra de negócio RN – 04 ___________________________________________________________ 28
Quadro 6 - Detalhe do caso de uso CSU - 01 ______________________________________________________ 34
Quadro 7 - Detalhe do caso de uso CSU - 02 ______________________________________________________ 35
Quadro 8 - Detalhe do caso de uso CSU - 03 ______________________________________________________ 36
Quadro 9 - Detalhe do caso de uso CSU - 04 ______________________________________________________ 37
Quadro 10 - Detalhe do caso de uso CSU - 05 _____________________________________________________ 38
Quadro 11 - Detalhe do caso de uso CSU - 06 _____________________________________________________ 39
Quadro 12 - Detalhe do caso de uso CSU - 07 _____________________________________________________ 40
Quadro 13 - Listagem de ferramentas de ORM ___________________________________________________ 74
Quadro 14 - Lista de pacotes Hibernate. Fonte – Java Magazine 2009. Edição 73 p. 4 ____________________ 78
LISTA DE ABREVIATURAS E SÍMBOLOS
API - Application Programming Interface (Interface de Programação de
Aplicações) - é um conjunto de classes, funções e rotinas de software acessíveis
através de uma linguagem de programação e que permitem o acréscimo de
funcionalidades em um programa sem a necessidade de reescrever o código.
Business Object (BO) – é um padrão de projeto utilizado para definir
as regras de negócio, separando: os dados do objeto da parte de negócio, e o
comportamento da persistência.
Context Objetct (CO) – é um padrão de projeto utilizado para a
modelagem dos objetos, proporcionando o desacoplamento das camadas e
tornando a aplicação com maior escalabilidade.
CSU – Caso de uso de usuário - representa uma unidade da interação
entre um usuário (humano ou máquina) e um sistema computacional. Um Caso de
Uso é uma unidade de um trabalho significante do sistema e descreve a
funcionalidade que ele representa no sistema proposto. Pode "incluir" outra
funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio
comportamento.
DAO - Data Access Object - é um padrão para persistência de dados
que permite separar regras de negócio das regras de acesso a banco de dados.
Numa aplicação que utilize a arquitetura MVC, todas as funcionalidades de bancos
de dados, tais como obter as conexões, mapear objetos Java para tipos de dados
SQL ou executar comandos SQL, podem ser feitas por classes de DAO.
DER – Diagrama de Entidades e Relacionamentos – diagrama
construído para representar o modelo do banco de dados, onde as entidades
representam agrupamentos funcionais de dados do mundo real que deverão persistir
no banco e as relações entre essas entidades são as relações ou ligações entre
esses dados.
GUI – Graphical User Interface (Interface de usuário gráfico).
Hibernate - O Hibernate é uma framework ORM (Object-Relational
Mapping) ou Mapeamento Objeto-Relacional para ambientes Java. As bibliotecas de
ORM fazem o mapeamento de tabelas para classes. Além disso, as classes, que
fazem essa interface com as tabelas do banco de dados, provêem um conjunto de
métodos de alto-nível que servem para realizar operações básicas nas tabelas. É um
framework não intrusivo, ou seja, não restringe a arquitetura da aplicação, e
implementa a especificação Java Persistente API (JPA).
HTML - HyperText Markup Language (Linguagem de Marcação de
Hipertexto) - é uma linguagem de marcação utilizada para produzir páginas na Web.
Documentos HTML podem ser interpretados por navegadores Web ou browsers.
HTTP - HyperText Transfer Protocol (Protocolo de Transferência de
Hipertexto) – é um protocolo de comunicação (da camada de Aplicação do Modelo
OSI) utilizado para transferência de dados na Internet (World Wide Web) e em
intranets. É usado para a comunicação de sites, comunicando na linguagem HTML.
Contudo, para haver comunicação com o servidor do site é necessário utilizar
comandos adequados, que não estão em linguagem HTML.
JDBC – Java Database Connectivity – é um conjunto de classes e
interfaces, próprias da linguagem de programação Java, que fazem a intermediação
entre aplicativos escritos nesta linguagem e um banco de dados relacional através
do envio de comandos SQL.
JSP - JavaServer Pages - é uma tecnologia da linguagem de
programação Java utilizada no desenvolvimento de aplicações para Web, similar às
tecnologias Active Server Pages (ASP) da Microsoft ou PHP. Por ser baseada em
Java, tem a vantagem da portabilidade de plataforma, que permite a sua execução
em diversos sistemas operacionais. Esta tecnologia permite ao desenvolvedor de
páginas para Internet produzir aplicações que, acessem o banco de dados,
manipulem arquivos no formato texto, capturem informações a partir de formulários e
captem informações sobre o visitante e sobre o servidor. Uma página criada com a
tecnologia JSP, depois de instalada em um servidor de aplicação compatível com a
tecnologia Java EE, é transformada em um Servlet.
MVC – Model-View Controller - é um padrão de arquitetura de software.
O MVC separa as tarefas de acesso de dados, da lógica de negócio e da
apresentação uma das outras, colocando cada uma em uma “camada” do software.
Isso é especialmente útil em aplicações complexas, que enviam uma série de dados
para o usuário, pois, com o uso do MVC, alterações feitas na interface não afetarão
a manipulação dos dados, e estes poderão ser reorganizados sem alterar a interface
do usuário. A separação das partes acontece através de um componente chamado
“Controller”, que distribui as tarefas a cada uma das camadas.
Modelo OSI – Open System Interconection – é um modelo que
descreve como os dados são enviados através do meio físico e processados por
outros computadores na rede.
RN – Regra de Negócio – é uma regra associada ao negócio sob a
qual o sistema deve operar.
Servlet - é uma tecnologia da linguagem de programação Java que
insere novos recursos a um servidor, são consideradas extensões de servidores.
Essa tecnologia disponibiliza ao programador da linguagem Java uma interface para
o servidor web (ou servidor de aplicação), através de uma API. As aplicações
baseadas no Servlet geram conteúdo dinâmico e interagem com os clientes,
utilizando o modelo request/response. Os servlets normalmente utilizam o protocolo
HTTP, apesar de não serem restritos a ele. Um Servlet necessita de um Web
Container para ser executado.
Struts - é um framework de desenvolvimento da camada controladora,
numa estrutura seguindo o padrão do MVC oficializado pela Sun, de aplicações web
(principalmente) construído em Java para ser utilizado em um web container. Este
framework foi originalmente desenvolvido por Craig McClanahan e doado para a
Apache Software Foundation, onde continua sendo desenvolvido segundo o padrão
desta fundação.
UML - Unified Modeling Language (Linguagem de Modelagem
Unificada) - é uma linguagem visual utilizada para modelar sistemas computacionais
por meio do paradigma de orientação a objetos. Essa linguagem tornou-se, nos
últimos anos, a linguagem padrão de modelagem de software adotada
internacionalmente pela indústria de Software. A UML não é uma metodologia de
desenvolvimento ou linguagem de programação e sim uma linguagem de
modelagem, cujo objetivo é auxiliar na definição das características do software e na
padronização dos projetos independente da linguagem de programação utilizada.
Web Container – é um objeto que contém os Servlets, onde estes
podem ser inseridos ou removidos dinamicamente. Quando uma aplicação web faz
uma solicitação para um Servlet, o servidor não entrega a solicitação diretamente ao
Servlet, mas sim para o Web Container que o contém. O container gerencia o ciclo
de vida, dá suporte ao multithread, segurança, e suporte para páginas JSP.
EJB3 – Enterprise Java Beans – componente do tipo servidor da
arquitetura JEE que permite o desenvolvimento baseado em componentes de forma
rápida e prática de aplicações distribuídas, transacionais, portáveis e seguras
utilizando a tecnologia Java. Sua versão 3 é a mais atual e oferece suporte à API de
gerência de persistência e mapeamento objeto-relacional da tecnologia Java.
Web Service – tecnologia de desenvolvimento de software que permite
que aplicações diferentes comuniquem entre si de forma normatizada,
independentemente da plataforma em que foram construídas, de forma a serem
capazes de invocar recursos umas das outras e delegar tarefas de diversos níveis
de complexidade. Estes componentes utilizam a linguagem XML como “linguagem
universal”, que pode ser traduzida para qualquer outra que os sistemas entendam.
JBoss – servidor de aplicação de código aberto baseado na linguagem
Java e que pode ser executado em qualquer sistema operacional que a suporte. Foi
desenvolvido inicialmente por uma empresa chamada JBoss, como um Servidor de
Aplicação (Aplication Server, AS, em inglês), e hoje é um produto da Red Hat. Traz o
web contêiner Apache Tomcat embutido e implementa diversos serviços de suporte
à arquitetura JEE, como por exemplo, EBJ, Java Persistence, Servlets e JSP, JMS
(Java Message Service), entre outros.
SUMÁRIO
1 INTRODUÇÃO .................................................................................... 17
1.1 Breve Histórico ...........................................................................................17
1.2 Cenário atual ..............................................................................................17
1.3 A tecnologia nas empresas de autopeça .....................................................18
1.4 Identificação do problema ..........................................................................19
1.5 Objetivos do trabalho .................................................................................19
1.5.1 Objetivos Gerais .................................................................................................. 19
1.5.2 Objetivos Específicos ........................................................................................... 19
1.6 Justificativa para a pesquisa .......................................................................20
1.7 Organização do Trabalho ............................................................................21
1.8 Especificação do Problema .........................................................................22
2 ANÁLISE DE PROJETO DE SISTEMAS .................................................... 23
2.1 Introdução ..................................................................................................23
2.2 Ferramenta de modelagem ........................................................................24
2.3 Requisitos ...................................................................................................25
2.4 Regras de negócio .......................................................................................27
2.5 Descrição dos atores ......................................................................................28
2.6 Casos de uso ..................................................................................................29
2.7 Documentação dos casos de uso ...................................................................31
2.7.1 Manutenção de Cliente .......................................................................................... 34
2.7.2 Manutenção de Funcionário ................................................................................... 35
2.7.3 Manutenção de Fornecedor ................................................................................... 36
2.7.4 Manutenção de Produtos ....................................................................................... 36
2.7.5 Login de Usuário ..................................................................................................... 38
2.7.6 Registrar Compra .................................................................................................... 39
2.7.7 Registrar Venda....................................................................................................... 40
2.8 Classes de análise ..........................................................................................40
2.9 Diagrama de classes de análise ......................................................................41
2.10 Diagramas de Seqüência ..............................................................................43
3 PERSISTÊNCIA DE DADOS ................................................................... 49
3.1 Conceitos de banco de dados .....................................................................49
3.2 Sistema gerenciador de banco de dados – SGBD ........................................50
3.3 Arquitetura do banco de dados ..................................................................58
3.4 A evolução dos sistemas de dados ..............................................................60
3.5 Tipos de Banco de Dados ............................................................................63
3.6 Modelagem de banco de dados ..................................................................66
3.7 Mapeamento Objeto Relacional .................................................................71
3.7.1 Conceito .............................................................................................................. 71
3.7.2 Motivação do uso de ORM .................................................................................. 72
3.7.3 Ferramentas de mapeamento objeto/relacional ................................................ 74
3.7.4 Mapeamento objeto/relacional .......................................................................... 74
3.8 Framework Hibernate .................................................................................76
3.8.1 Introdução ........................................................................................................... 76
3.9 Historia .......................................................................................................77
3.9.1 Arquitetura .......................................................................................................... 77
4 PROJETO DE INTERFACE ..................................................................... 83
4.1 Introdução ..................................................................................................83
4.2 Interface .....................................................................................................83
4.3 Usabilidade .................................................................................................86
4.4 Padrões utilizados .......................................................................................87
4.5 Arquitetura da interface .............................................................................88
4.6 Estudo de Caso .................................................. Erro! Indicador não definido.
5 ARQUITETURA E CÓDIGO ................................................................... 94
5.1 O enfoque de camadas ...............................................................................95
5.2 O padrão MVC ............................................................................................97
5.3 Servlets e Java Server Pages .......................................................................99
5.4 O Framework Struts2 ..................................................................................99
5.5 Java Enterprise Edition (JEE) ..................................................................... 101
5.6 Padrões de projeto ................................................................................... 102
5.7 Enterprise Java Bean (EJB) ........................................................................ 104
5.8 Conteiner Web e Aplicações Web ............................................................. 105
5.9 Web Services ............................................................................................ 107
5.10 Arquitetura e Projeto do SGA ................................................................. 107
5.10.1 Diagrama de pacotes ....................................................................................... 109
5.10.2 Diagrama de Distribuição ................................................................................ 112
6 CONCLUSÕES ................................................................................... 115
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 117
ANEXO A – DADOS IMPORTANTES ........................................................... 119
17
1 INTRODUÇÃO
1.1 Breve Histórico
O Setor automobilístico nacional é considerado um dos setores que
sentem, de forma mais rápida, os reflexos do que acontece no âmbito mundial. Este
setor está constantemente sobre pressões de várias maneiras, e estas pressões
guiam seu mercado determinando as tendências que devem ser consideradas no
momento de decidir quais as próximas mudanças a serem adotadas.
O Brasil entrou na competição por este setor um pouco atrasado,
enquanto as nações mais desenvolvidas já estavam otimizando sua produção,
aplicando técnicas de gerenciamento com a intenção de aumentar a qualidade,
baixar os custos e gerenciar melhor seus estoques, o Brasil estava apenas
começando.
Antes da década de 90 o Brasil ainda não tinha evoluído bem neste
setor, um dos motivos era a dificuldade na importação de veículos, fazendo com que
as montadoras aqui situadas não fossem obrigadas a disputar com fortes
concorrentes. Porem no início desta mesma década, com o objetivo de forçar a
modernização das fabricas brasileiras e seus produtos, o governo nacional reduziu
as tarifas de importação de 80% em 1990, para 35% em 1994, afetando diretamente
a indústria automobilística, o que aumentou bastante a velocidade do seu
desenvolvimento, conforme mencionado por Cangüe, Godefroid, & Silva (2004).
1.2 Cenário atual
Atualmente as indústrias automobilísticas tiveram que se adaptar
rapidamente a duas grandes mudanças: uma na estrutura dos veículos e outra em
seu processo de produção.
De acordo com (CANGÜE, GODEFROID, & SILVA, 2004), nas ultimas
4 décadas a estrutura dos veículos teve muitas alterações devido à necessidade de
carros mais leves e mais econômicos. Os principais responsáveis pelo surgimento
desta necessidade foram as pressões ambientais, econômicas e mercadológicas. O
alumínio, por exemplo, que na década de 1960, representa apenas 25 quilos do
18
material de um carro, em 2005 este peso saltou para 160 quilos, o mesmo
aconteceu com plásticos, polímeros, ligas de magnésio e ligas de titânio.
Pera (2009) explica que o processo de produção teve que aumentar
rapidamente o seu ritmo, pois, após a recente crise de Setembro de 2008, com a
intenção de aquecer o mercado automobilístico, o governo federal reduziu o IPI dos
carros até 1.000 cm³ de 7% para 0% e dos carros entre 1.001 cm³ e 2.000 cm³ de
13% para 6,5%. Com os preços baixos as vendas aumentaram consideravelmente,
aquecendo por conseqüência, o mercado de crédito. Porém, antes deste incentivo
governamental, outro mercado foi muito estimulado ainda durante a crise, o setor de
autopeças.
De acordo com Antônio Carlos Bento, diretor e conselheiro do
Sindipeças e coordenador do Grupo de Manutenção Automotiva (GMA), o que
fortaleceu o mercado de autopeças foi, especialmente, a crise. “Muitas pessoas
deixaram de comprar o carro novo por causa da crise e decidiram fazer a
manutenção mais completa do usado”, observa.
Após a crise, durante o plano de contingência do governo, o mercado
de autopeças continuou aumentando, e diversificando cada vez mais o seu estoque,
pois deveria atender a demanda dos veículos que já circulavam anteriormente, e
atender também a demanda de uma grande diversidade de novos modelos.
1.3 A tecnologia nas empresas de autopeça
Com o rápido crescimento do mercado automotivo e o forte impulso no
setor de autopeças, a necessidade de gestão dos estoques e da logística aumentou
sensivelmente. Muitas empresas do setor tiveram seus mercados expandidos ou
muito modificados, algumas iniciando suas operações em outros estados ou mesmo
outros países.
Saraiva (2007) afirma que neste cenário desafiador, a utilização
eficiente da tecnologia tem sido um diferencial muito importante e pode garantir a
sobrevivência das empresas. Segundo Raul Randon, CIO das empresas Randon,
um dos grandes desafios do setor é a integração da cadeia de suprimentos, onde o
planejamento é essencial, e que a área de TI pode contribuir com ferramentas que
permitam a dinamização dos processos, para maximizar ganhos e aumentar a
19
eficiência operacional. Ainda de acordo com ele, essa eficiência é que determina a
redução de custos, determinante na hora da venda. Edson Badan, diretor de TI da
Ford América do Sul, corrobora a idéia do colega, informando que o parque de TI
das empresas da área tem sido modernizado com a idéia de aperfeiçoar os níveis de
estoque e a disponibilidade de peças, de olho no aumento da satisfação dos
usuários, o que torna muito positiva a visão que clientes e fornecedores têm das
empresas.
1.4 Identificação do problema
Para atender as necessidades específicas da empresa Universo
Autopeças, foi necessário o projeto de um sistema customizado, que permitisse ao
administrador, controlar as transações comerciais, realizar o controle de estoque e a
geração de informações relevantes a empresa. Para o levantamento dos requisitos
funcionais, foram realizadas reuniões presenciais com o cliente.
Para o desenvolvimento deste projeto serão realizados conceitos de
Engenharia de Software e do paradigma de Orientação a Objetos.
1.5 Objetivos do trabalho
1.5.1 Objetivos Gerais
Desenvolver um sistema com suporte a Web para gestão de uma
empresa especializada em vendas de peças para automóveis. Desenvolver uma
solução para gerenciar, administrar e armazenar todas as operações realizadas pela
empresa.
1.5.2 Objetivos Específicos
• Levantar os requisitos do sistema;
• Documentar os Casos de Uso;
• Analisar o desenvolvimento do projeto;
• Elaborar os diagramas de seqüência de análise;
• Desenvolver o aplicativo em três camadas de acordo com o modelo MVC;
20
• Desenvolver o sistema utilizando a linguagem de programação Java;
• Desenvolver os diagramas de classes no nível do projeto;
• Utilizar o Design Patterns J2EE;
• Elaborar o diagrama conceitual (Diagrama de classes de negócio);
• Desenvolver a camada de integração utilizando DAO – Data Acess
Object;
• Utilizar o Hibernate com anotações para mapeamento objeto-relacional;
• Utilizar Struts2;
• Utilizar Tiles.
1.6 Justificativa para a pesquisa
Embora exista uma quantidade considerável de softwares para gestão
de empresas de autopeças no mercado, sempre há a demanda por soluções
customizadas, que se adéquam mais precisamente ao negócio de cada empresa,
pois apesar de se tratar de um nicho de negócio comum, cada empresa possui
necessidades particulares, que variam de acordo com as características específicas
da empresa.
O custo envolvido na produção de um software customizado, que se
adéqüe perfeitamente aos padrões da empresa, dificulta sua aquisição, pois em sua
maioria, estas empresas são de pequeno e médio porte, e não possuem tal valor
para realizar um investimento tão significativo. Por isso, é bastante comum a
utilização de soluções genéricas para suprirem interinamente as necessidades
especificas da empresa de vendas de peças para automóveis.
Conforme citado anteriormente, a utilização de soluções genéricas, não
atende completamente todas as necessidades da empresa, o que pode causar
prejuízos ao negócio, como a perda de vendas, falta de controle de estoque,
redução na agilidade da entrega, falta de controle de clientes, dentre outras
situações. Com o sistema desenvolvido, estes problemas são minimizados,
proporcionando um aumento de qualidade ao serviço prestado pelo
21
estabelecimento.
Observando-se estas necessidades, desenvolveu-se um sistema que
implementa uma solução eficaz e consistente de gerenciamento, manipulação e
armazenamento de dados, o que possibilita maior lucratividade, e maior agilidade no
atendimento ao cliente.
A importância da pesquisa, para projeto de desenvolvimento de um
sistema específico para a empresa Universo Autopeças sustenta-se na necessidade
de um estudo detalhado, de como desenvolver um software com todas estas
características, desde sua primeira etapa, utilizando tecnologias e metodologias
atuais.
A utilização da plataforma web pela equipe de desenvolvimento
contribuiu para o projeto que aborda o uso de tecnologias como o Struts2, Hibernate,
Java, Java Server Pages dentre outras. Este projeto poderá servir como objeto de
estudo para futuras pesquisas acadêmicas e cientificas.
1.7 Organização do Trabalho
Este trabalho foi desenvolvido com o empenho e dedicação de todos
integrantes do grupo, onde cada etapa as equipes subdivididas desenvolviam suas
atividades e o grupo como um todo analisava o trabalho de todos.
O capítulo 2 descreve a empresa a escolhida para desenvolvimento do
trabalho e suas características. Ainda neste capítulo serão abordados os requisitos
do sistema e as reuniões feitas com o dono da empresa.
O capítulo 3 abordará a análise dos dados coletados nas reuniões
feitas com o proprietário. Descreverá o uso de ferramentas que nos auxiliou na
elaboração do escopo do sistema, mostrado os principais diagramas na linguagem
escolhida.
O capítulo 4 é feito uma síntese da persistência de dados, bem como
alguns trechos de códigos e para desenvolver tal tarefa.
O capítulo 5 é demonstrado a interface do sistema, explicitando a
forma como foi feito e esboçando telas do sistema como exemplos das execuções.
O capítulo 6 será descrita toda a arquitetura utilizada por nós para
22
desenvolvimento do sistema.
O capítulo 7 apresentará as conclusões observadas pelo grupo como
um todo, esboçando os objetivos traçados e alcançados através da pesquisa feita.
1.8 Especificação do Problema
Propõe-se então o desenvolvimento de um sistema de informação que
abranja os dados e cruze as informações contidas nele apoiando na administração e
tomadas de decisões de seu proprietário. Este sistema deverá haver a manipulação
de informações tais como: registro das peças que foram adquiridas pela empresa
(compra) e vendidas a seus clientes, gerando históricos de todas as etapas desta
movimentação. Nesta movimentação, o vendedor será capaz de cadastrar clientes e
fornecedores, consultar clientes e fornecedores, emitir boleto de pagamento, nota
fiscal, registrar vendas e registrar os pagamentos feitos a partir das vendas feitas. O
gerente será responsável pelo recebimento das compras feitas pela empresa, o
cadastro da utilização das peças, a criação de grupo de produto, a concessão de
descontos diferenciados e visualizar relatórios gerais.
O sistema será baseado na arquitetura web, utilizando a linguagem
JAVA que será possível desenvolver um layout intuitivo que agilizará seu uso.
Utilizando tais ferramentas, o cliente poderá desempenhar suas atividades comuns
como cadastrar, consultar, excluir, visualização de relatórios funcionais e gerenciais
que ajudarão na estratégia da empresa, e poderá tomar decisões mais precisas.
23
2 ANÁLISE E PROJETO DO SISTEMA
2.1 Introdução
A modelagem de sistemas é um elemento importante do processo de
engenharia de sistemas. O engenheiro cria modelos que representam os processos,
servindo às necessidades da visão que está sendo considerada, representam o
comportamento dos processos e os pressupostos nos quais o comportamento está
baseado. A modelagem da análise usa uma combinação de formas textuais e
diagramáticas para mostrar os requisitos de dados, função e comportamento, de
modo que seja relativamente fácil de entender e, mais importante, mais direto de
revisar o modelo.
A análise de requisitos resulta na especificação das características
operacionais do software, indica a interface do mesmo com outros elementos do
sistema e estabelece restrições a que o software deve satisfazer. Ou seja, a análise
de sistemas é importante, pois, representa os requisitos em várias “dimensões”,
aumentando conseqüentemente a probabilidade de acertos, pois força que sejam
encontrados erros, apareçam inconsistências e que omissões sejam descobertas.
Os requisitos de informações, funcionais e comportamentais são modelados usando
vários formatos diagramáticos diferentes.
Dentre as diferentes modelagens da análise de sistema, seguem
algumas com suas especificações básicas. A modelagem baseada em cenário
representa o sistema sob o ponto de vista do usuário. A modelagem orientada a
fluxo fornece indicação de como os objetos de dados são transformados pelas
funções de processamento. A modelagem baseada em classes define objetos,
atributos e relacionamentos. A modelagem comportamental mostra os estados do
sistema e de suas classes, e o impacto que os eventos têm nesses estados. Uma
vez criados os modelos preliminares, eles são refinados e analisados para avaliar
sua clareza, completeza e consistência. Ou seja, os produtos do trabalho da
modelagem da análise precisam refletir as necessidades de todos os interessados e
estabelecer um fundamento com base no qual o projeto possa ser conduzido, logo o
modelo final de análise é então validado por todos os interessados. De uma
perspectiva mais ampla um modelo pode ser visto como uma representação
24
idealizada de um sistema a ser construído. São várias as razões da utilização de
modelos para construção de sistemas, dentre elas cita-se: o gerenciamento da
complexidade, a comunicação entre as pessoas envolvidas, a redução dos custos
no desenvolvimento e a predição do comportamento futuro do sistema.
Logo, a análise de um sistema consiste em definir um problema,
analisar o mesmo para verificar quais são as possíveis soluções, identificar as suas
causas, verificar o porquê um determinado problema existe e identificar assim as
reais necessidades para que seja implementada uma solução através do sistema de
informação. Dentro dos requisitos da organização, para que se faça uma boa
análise, é necessário estudar a viabilidade técnica, econômica e operacional da
empresa, para avaliar, por exemplo, os recursos de hardware que estarão
disponíveis para implementação, ou, avaliar se os benefícios da solução proposta
irão ultrapassar os custos, entre outros. A análise é o processo para se conhecer o
negócio do cliente e produzir um modelo de sistema que seja parecido com a
realidade do parceiro. Um sistema inclui vários elementos: software, hardware,
pessoal, banco de dados, documentação, processos e procedimentos, por isso é
necessário a compreensão de todos e o uso da engenharia de sistemas
(SOMMERVILLE, 2003).
2.2 Ferramenta de modelagem
As ferramentas de modelagem de sistemas fornecem ao engenheiro de
software a habilidade de modelar todos os elementos de um sistema baseado em
computador usando uma notação que é específica para aquela ferramenta. Em
geral, as ferramentas nessa categoria possibilitam a um engenheiro modelar a
estrutura de todos os elementos funcionais do sistema, o comportamento estático e
dinâmico do sistema, e a interface homem-máquina (BOOCH, RUMBAUGH, &
JACOBSON, 2000).
As ferramentas de engenharia de requisitos apóiam a obtenção,
modelagem, gestão e validação de requisitos. Em geral, essas ferramentas
constroem uma variedade de modelos gráficos (por exemplo, UML) que representam
os aspectos informacional, funcional e comportamental de um sistema. Esses
modelos formam a base para todas as outras atividades do processo de software. A
linguagem UML auxilia na criação dos itens, relacionamentos e diagramas. Os itens
25
podem ser estruturais, comportamentais, de agrupamento ou anotacionais; os
relacionamentos podem ser de dependência, associação, agregação ou
generalização; e os diagramas que definem ângulos de visualização do sistema são
nove, dentre eles cita-se o diagrama de classes, de casos de uso, de seqüência,
entre outros, todos são representações gráficas que auxiliam a análise.
As ferramentas de modelagem de dados, por exemplo, são usadas
principalmente para aplicações de grandes bancos de dados e outros projetos de
sistemas de informação. Elas fornecem meios automatizados para criação de
diagramas de entidade, dicionários de objetos de dados e modelos relacionados.
Ferramentas nessa categoria possibilitam ao usuário descrever objetos de dados e
seus relacionamentos, ou, possibilitam a criação de um modelo de banco de dados
pela geração do esquema de banco de dados comum para Sistemas de Gestão de
Banco de Dados (SGBD).
Para modelagem de dados usamos a ferramenta de modelagem de
dados DBDesigner que é um editor visual para criação de banco de dados mySQL
que integra criação, modelagem, desenvolvimento e manutenção dos bancos em um
ambiente simples e agradável. Algumas características do DBDesigner são: software
livre; multi-plataforma; permite engenharia reversa, gerando o modelo a partir das
tabelas do banco de dados; interface com o usuário muito bem elaborada, tornando
o seu uso bastante simples; entre outras.
Para modelagem de sistema usamos o Enterprise Architect que é uma
ferramenta de desenho e análise UML, e que abrange o desenvolvimento de
softwares, através das etapas da análise, desenho de modelos, testes e
manutenção. O Enterprise Architect é multi-usuário, baseado no sistema operacional
Windows, e capaz de construir software robusto e sustentável (PRESSMAN, 2006).
Com essa ferramenta, conseguimos desenhar os diagramas necessários para
construção do sistema, gerar a documentação, controlar a mudança dos requisitos e
da engenharia de classes no decorrer do projeto.
2.3 Requisitos
A análise de requisitos é fundamental para o desenvolvimento de
sistemas, pois exemplifica as operações que o sistema deve fazer e também as suas
26
restrições. Os requisitos podem ser funcionais ou não funcionais.
Um requisito é considerado como funcional quando descreve um
serviço ou função a ser realizada. Já requisitos não funcionais coincidem com
restrições ou condições impostas ao sistema ou ao seu desenvolvimento (SILVA,
BONIN, & PALUDO, 2006).
É necessário entender os requisitos antes de começar a implementar o
projeto, para isso deve-se seguir as tarefas da engenharia de requisitos: concepção,
levantamento, elaboração, negociação, especificação, validação e gestão dos
requisitos. À medida que os requisitos são levantados pelo cliente ou pelo analista, a
equipe negocia também a prioridade, a disponibilidade de recursos e o custo relativo
a cada requisito, para avaliar o que será desenvolvido primeiro e qual impacto terá
no projeto. É importante verificar com o cliente todos esses casos e deixar claro o
que será necessário, para que ele tenha consciência do que será feito e quando
será feito; além disso, pode ser feito um cronograma estabelecendo essas
prioridades em nível de conhecimento do cliente.
O sistema SGA a ser desenvolvido apresenta os requisitos funcionais e
não funcionais do Quadro 1. Esses requisitos que descrevem o comportamento do
sistema e se relacionam ao desempenho do mesmo, foram definidos na reunião
entre o cliente e os desenvolvedores do projeto. Para estabelecer esses requisitos, o
cliente foi colocando todas as suas reais necessidades, as mesmas foram avaliadas
pelos desenvolvedores e as conformidades e não conformidades foram passadas
para o cliente, até chegar a um consenso comum. O processo da autopeças em
questão é simples, ela trabalha com os determinados cadastros, registros de compra
e venda de peças automotivas. Conforme definido na reunião com cliente, os
requisitos citados abaixo atenderiam as suas necessidades e permitirão o
entendimento dos usuários do sistema.
REQUISITOS FUNCIONAIS
27
• O sistema deve permitir a manutenção de clientes.
• O sistema deve permitir a manutenção de fornecedores.
• O sistema deve permitir a manutenção de produtos.
• O sistema deve permitir a manutenção de funcionários.
• O sistema deve permitir o login.
• O sistema deve permitir o registro de compra.
• O sistema deve permitir a atualização de estoque.
• O sistema deve permitir a atualização de estoque manual.
• O sistema deve permitir a concessão de desconto especial.
• O sistema deve permitir registro de vendas.
• O sistema deve permitir a devolução de peças.
REQUISITOS NÃO FUNCIONAIS
• Usabilidade: os funcionários inexperientes devem ser capazes de
utilizar todas as funcionalidades do sistema após treinamento.
• O sistema deve ser confiável.
• Desempenho: o sistema deve ter um bom desempenho, ser eficiente e
exato.
Quadro 1 - Requisitos do sistema
2.4 Regras de negócio
As regras de negócio determinam o comportamento do sistema e são
usadas para alcançar os objetivos de uma empresa. Podem ser as operações,
definições, validações, restrições ou condições da empresa, podem abranger
diversos assuntos seguindo a definição do negócio.
Para especificar as particularidades do sistema a ser desenvolvido para
a autopeça, dentro da reunião feita com o cliente foram determinadas as regras
descritas nas tabelas abaixo. A definição das mesmas ajuda os desenvolvedores na
hora da programação dos métodos do sistema, por isso é importante que essas
regras sejam definidas logo no início do projeto, ou seja, o método a ser
implementado pelo desenvolvedor deve seguir as restrições das regras de negócio
definidas, todas elas devem ser tratadas dentro do sistema, caso contrário cada uma
28
pode ter um impacto negativo em outra parte do programa futuramente, e tratar um
código que já está programado é mais difícil do que prever antes e já desenvolver.
Nome Descontos especiais RN- 01
Descrição O gerente pode conceder descontos especiais de até 20% para
clientes que efetuam compras acima de R$1.000,00.
Quadro 2 - Regra de negócio RN – 01
Nome Validação de CPF e CNPJ RN- 02
Descrição Para cadastrar um cliente ou fornecedor deverá ser verificado se o
CPF/CNPJ são válidos.
Quadro 3 – Regra de negócio RN – 02
Nome Preço de venda menor que preço de compra RN- 03
Descrição Ao cadastrar uma compra, o preço de venda não pode ser menor
que o preço de compra mesmo com os descontos especiais..
Quadro 4 - Regra de negócio RN – 03
2.5 Descrição dos atores
Funcionário - responsável por algumas manutenções do sistema. Ele
pode realizar a manutenção de clientes e fornecedores, como cadastro e consulta de
clientes, cadastro e consulta de fornecedores, e manutenção de produtos.
Vendedor - pessoa responsável pela devolução de peças (e
conseqüentemente a atualização do estoque), e registro de vendas (à vista, à prazo
ou com desconto especial).
Gerente - responsável pelos requisitos dos atores funcionário e
vendedor, podendo realizar a manutenção de clientes, fornecedores e produtos,
registrar venda e devolver peça. Alguns casos de uso só o gerente tem permissão
para realizar, como por exemplo, o cadastro de utilização de peça e a manutenção
de funcionários. Logo o gerente tem permissão para realizar todos os casos de uso.
29
2.6 Casos de uso
Os casos de uso são usados para definir o que deve ser realizado pelo
sistema e o que existe fora dele, sendo assim cada caso de uso está ligado a um
requisito funcional. E para exemplificar a funcionalidade dos casos de uso, cria-se
um diagrama de casos, conforme Figura 1, com os usuários envolvidos e a possível
existência de integração com sistemas externos. O diagrama de casos de uso
mostra as interações entre os atores e os sistemas em seu cenário específico.
Figura 1 - Diagrama de Casos de Uso
Conforme o diagrama de casos de uso do sistema SGA, a iteração com
30
o sistema será feita por funcionários, vendedores e gerente, e não haverá integração
com outro sistema. Os casos de uso podem ter relacionamentos de inclusão
(quando um caso de uso inclui obrigatoriamente outro) e extensão (quando um caso
de uso opcionalmente inclui outro). De acordo com o sistema SGA o caso de uso
devolver peça obrigatoriamente inclui o atualizar estoque, ou seja, se devolver uma
determinada peça irá atualizar o estoque da mesma, e o caso de uso registrar venda
opcionalmente incluirá o caso de uso conceder desconto especial, pois no momento
da venda o cliente pode ou não ter desconto da peça.
Pode-se verificar com o diagrama de casos de uso qual a utilidade e o
contexto do sistema, os processos da empresa que serão influenciados e as
pessoas que estarão envolvidas em seus determinados processos, ou, as
responsabilidades de cada ator
Os elementos chave de um diagrama de casos de uso são:
Ator: agentes externos que interagem com o sistema, podem ser
pessoas ou hardware. Os atores estão ligados diretamente com o seu respectivo
caso de uso, cada um com suas funcionalidades. Sendo que um ator também pode
ter os mesmos casos de uso de outro ator e mais as suas funcionalidades. No caso
da autopeça, os autores serão os funcionários da loja, aquelas pessoas que ficam
internas na empresa administrando o negócio, os vendedores, que ficam no balcão
ou na rua, e o próprio gerente da loja.
Caso de uso: descreve o relacionamento do sistema e do ator, e as
operações entre os mesmos. Descreve cada funcionalidade do sistema, os
requisitos funcionais que serão implementados.
Interações: comunicação do sistema com os seus respectivos atores,
ou seja, qual ator tem ligação com o determinado caso de uso. Na autopeça, por
exemplo, um funcionário da empresa irá interagir com a manutenção de produtos,
clientes, dentre outros.
Sistema: conjunto de casos de uso dentro da fronteira, com seus
objetivos específicos. Todos os requisitos funcionais avaliados pelos analistas que
serão desenvolvidos.
31
2.7 Documentação dos casos de uso
Um caso de uso especifica o comportamento de um sistema ou de parte de
um sistema e é uma descrição de um conjunto de seqüência de ações,
incluindo variantes realizadas pelo sistema para produzir um resultado
observável do valor de um ator. (BOOCH, RUMBAUGH, & JACOBSON,
2000)
Os casos de uso podem ser aplicados a todo o sistema, incluindo
interfaces e classes individuais. Para identificar esses casos, na reunião com o
cliente, são levantadas questões como: quem serão as pessoas que implementarão
o sistema, patrocinadoras, suas funções, a capacidade de cada uma, quem seria
responsável por determinada operação, as regras estabelecidas para cada um, se o
software precisa se comunicar com sistemas externos, fazer validações em outros
sites ou programas, e outras questões também importantes para determinação
desses casos.
Os casos de uso podem ser representados por documentos de texto, e
os mesmos podem exemplificar o desenvolvimento que será feito no sistema, os
subsistemas e as classes que serão criadas, ajudando assim os analistas no
desenvolvimento do projeto e, posteriormente, os desenvolvedores que precisam de
toda essa documentação para moldar o sistema de acordo com as necessidades
dos usuários. É importante ter toda essa documentação para evitar erros e deixar
um escopo bem definido com o cliente.
Conforme Bezerra (2002):
O modelo de Casos de Uso é uma representação das funcionalidades
externamente observáveis do sistema e dos elementos externos ao sistema
que interage com ele.
[...] Desde então, esse modelo vem se tornando cada vez mais popular para
realizar a documentação de requisitos funcionais de uma aplicação, devido
à sua notação gráfica simples e descrição em linguagem natural, o que
facilita a comunicação de desenvolvedores e usuários.
[...] Além disso, o modelo de casos de uso fora os desenvolvedores a
32
moldarem o sistema de acordo com o usuário, e não o usuário de acordo
com o sistema.
Os casos de uso que na fase de concepção do projeto foram descritos,
agora devem ser detalhados em uma seqüência de passos. A descrição em alto
nível explica o objetivo e funcionamento do caso. Primeiro deve-se identificar o fluxo
principal e as seqüência alternativas associadas às suas possíveis exceções. Todos
os requisitos devem ser bem documentados para que se tenha um bom projeto.
Seguindo os padrões UML um documento de casos de uso é descrito com as
seguintes características:
Nome: descrição do caso de uso. Deve ser a mesma descrição que
está no diagrama de casos de uso.
Identificador: código que pertence a referência do caso de uso com os
diversos documento relacionados a ele.
Ator primário: nome do ator que inicia o caso de uso.
Ator(es) secundário(s): nome dos demais atores participantes do caso
de uso.
Sumário: descrição rápida do caso de uso.
Pré-condição: regra que defini qual hipótese será assumida como
verdadeira para que o caso de uso tenha início. As pré-condições estabelecidas não
serão testadas durante a execução do caso de uso e, portanto não podem gerar
exceções. Só seria impossível realizar um caso de uso se uma pré-condição fosse
falsa.
Pós-condição: situação do sistema após a execução de um caso de
uso estabelece os resultados do mesmo.
Fluxo principal: descrição da seqüência de passos do fluxo principal,
em conseqüência, é a descrição do processo no qual tudo dá certo e não ocorre
nenhuma exceção, ou seja, o fluxo principal normalmente descreve o que ocorre
numa situação de normalidade quando o caso de uso é executado.
Fluxo alternativo: utilizado para descrever o que acontece quando o
ator faz uma seqüência alternativa, diferente da descrita no fluxo principal, para
33
alcançar seu objetivo. É a identificação e o tratamento das possíveis exceções de
interação identificadas pelo analista.
Fluxo de exceção: descreve o que acontece quando algo indesejado
ocorre na interação entre o ator e o caso de uso. Uma exceção impede a realização
da seqüência lógica do caso de uso.
Utilizando as práticas da UML, são apresentadas a seguir as
documentações dos casos de uso do sistema SGA.
34
2.7.1 Manutenção de Cliente
A documentação do caso de uso “Manutenção de cliente”, conforme o
Quadro 5, descreve o fluxo para o cadastro de clientes no sistema e identifica se um
cliente já está cadastrado ou não.
Nome Manutenção de Cliente CSU-01
Sumário Caso de Uso que descreve os passos para o cadastro de cliente.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O cliente é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do cliente; 2. O sistema solicita como campos (CPF, nome do cliente, telefone, sexo, endereço,
número do endereço, complemento, bairro, CEP, estado e cidade do cliente); 3. O funcionário informa os dados e confirma o cadastro do cliente; 4. O sistema valida o CPF e retorna uma mensagem informando que o cliente foi
cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de cliente.
1.1. O funcionário clica no botão buscar para localizar o cliente; 1.2. O sistema solicita o CPF/CNPJ do cliente; 1.3. O funcionário insere o CPF/CNPJ; 1.4. O sistema exibe os dados do cliente na tela e retorna ao passo 2.
Fluxo de Exceção [4]: Violação da Regra de Negócio RN-02.
4.1. O sistema emite uma mensagem informando que o cliente já está cadastrado; 4.2. O sistema retorna ao passo 2.
Fluxo de Exceção [4]: Cliente com CPF inválido.
4.1. O sistema emite uma mensagem informando que oCPF/CNPJ do cliente é inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócios associadas
RN - 02
Quadro 5 - Detalhe do caso de uso CSU - 01
35
2.7.2 Manutenção de Funcionário
A documentação do caso de uso “Manutenção de funcionário”,
conforme o Quadro 6, descreve o fluxo para o cadastro de funcionários no sistema e
identifica se os mesmos já está cadastrado ou não.
Nome Manutenção de Funcionário CSU-02
Sumário Caso de Uso que descreve os passos para o cadastro de funcionário.
Ator primário: Gerente
Ator(es) secundário(s): -
Pré-condição: O gerente deve estar logado no sistema.
Pós-condição: O funcionário é cadastrado.
Fluxo Principal
1. O gerente solicita ao sistema o cadastro do funcionário;
2. O sistema solicita como campos (CPF, nome do funcionário, telefone, sexo,
endereço, número do endereço, complemento, bairro, CEP, estado e cidade do
funcionário);
3. O gerente informa os dados e confirma o cadastro do funcionário;
4. O sistema valida o CPF e retorna uma mensagem informando que o funcionário
foi cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo[1]: Busca de funcionário.
1.1. O gerente clica no botão buscar para localizar o funcionário; 1.2. O sistema solicita o CPF do funcionário; 1.3. O gerente insere o CPF; 1.4. O sistema exibe os dados do funcionário na tela e retorna ao passo 2.
Fluxo de Exceção [4]: Funcionário já possui cadastro.
4.1. O sistema emite uma mensagem informando que o funcionário já está cadastrado;
4.2. O sistema retorna ao passo 2.
Fluxo de Exceção [4]: Violação da Regra de Negócio RN-02.
4.1. O sistema emite uma mensagem informando que o CPF do funcionário é inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócios associadas
RN - 02
Quadro 6 - Detalhe do caso de uso CSU - 02
36
2.7.3 Manutenção de Fornecedor
A documentação do caso de uso “Manutenção de fornecedor”,
conforme o Quadro 7, descreve o fluxo para o cadastro de fornecedores no sistema
e identifica se já está cadastrado ou não.
Nome Manutenção de Fornecedor CSU-03
Sumário Caso de Uso que descreve os passos para o cadastro de fornecedor.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O fornecedor é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do fornecedor; 2. O sistema solicita como campos (CPF/CNPJ), nome do fornecedor, telefone,
sexo, endereço, número do endereço, complemento, bairro, CEP, estado e cidade do fornecedor);
3. O funcionário informa os dados e confirma o cadastro do fornecedor; 4. O sistema valida o CPF/CNPJ e retorna uma mensagem informando que o
fornecedor foi cadastrado com sucesso e encerra o caso de uso.
Fluxo Alternativo [1]: Busca de fornecedor.
1.1. O funcionário clica no botão buscar para localizar o fornecedor; 1.2. O sistema solicita o CPF/CNPJ do fornecedor; 1.3. O funcionário insere o CPF/CNPJ; 1.4. O sistema exibe os dados do fornecedor na tela e retorna ao passo 2.
Fluxo de Exceção [4]: Fornecedor já possui cadastro.
4.1. O sistema emite uma mensagem informando que o fornecedor já está cadastrado;
4.2. O sistema retorna ao passo 2.
Fluxo de Exceção [4]: Violação da Regra de Negócio RN-02.
4.1. O sistema emite uma mensagem informando que o CPF/CNPJ do fornecedor é inválido;
4.2. O sistema retorna ao passo 2.
Regras de Negócios associadas
RN - 02
Quadro 7 - Detalhe do caso de uso CSU - 03
2.7.4 Manutenção de Produtos
A documentação do caso de uso “Manutenção de produtos”, conforme
37
o Quadro 8, descreve o fluxo para o cadastro de produtos no sistema e identifica os
produtos cadastrados.
Nome Manutenção de Produto CSU-04
Sumário Caso de Uso que descreve os passos para o cadastro de produto.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: O funcionário deve estar logado no sistema.
Pós-condição: O produto é cadastrado.
Fluxo Principal
1. O funcionário solicita ao sistema o cadastro do produto; 2. O sistema solicita como campos (código, nome do produto, grupo de produto,
preço de custo, preço de venda e utilização da peça); 3. O funcionário informa os dados e confirma o cadastro do produto; 4. O sistema retorna uma mensagem informando que o produto foi cadastrado com
sucesso e encerra o caso de uso.
Fluxo Alternativo [1]: Busca de Produto.
1.1. O funcionário clica no botão buscar para localizar o produto; 1.2. O sistema solicita o código/nome do produto; 1.3. O funcionário insere o código/nome do produto; 1.4. O sistema exibe os dados do produto na tela e retorna ao passo 2.
Fluxo de Exceção [4]: Produto já possui cadastro.
4.1. O sistema emite uma mensagem informando que o produto já está cadastrado;
4.2. O sistema retorna ao passo 2.
Regras de Negócios associadas
Quadro 8 - Detalhe do caso de uso CSU - 04
38
2.7.5 Login de Usuário
A documentação do caso de uso “Login de Usuário”, conforme o Quadro 9,
descreve o fluxo de funções que o ator deve aplicar para efetuar login no sistema. O
caso de uso verifica se o usuário e senha estão corretos, se a senha estiver errada
volta para a tela de login.
Nome Login de usuário CSU-05
Sumário Caso de Uso que descreve os passos para o usuário do sistema efetuar
login.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: -
Pós-condição: O funcionário é logado.
Fluxo Principal
1. O funcionário inicia o sistema; 2. O sistema solicita como campos (nome do usuário, e senha); 3. O funcionário informa os dados e efetua o login; 4. O sistema verifica se o nome do usuário e a senha estão corretos e o sistema é
logado.
Fluxo de Exceção[4]: Usuário ou senha inválidos.
4.1. O sistema emite uma mensagem informando que o usuário ou senha estão inválidos
4.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
--
Quadro 9 - Detalhe do caso de uso CSU - 05
39
2.7.6 Registrar Compra
No Quadro 10 estão descritas as funções para o ator “Registrar
Compra”. Nesse caso de uso, o funcionário informa os dados necessários para o
registro, o sistema adiciona os dados e atualiza o estoque da peça comprada.
Nome Registrar compra CSU-06
Sumário Caso de Uso que descreve os passos para o funcionário registrar uma
compra feita.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: O funcionário tem que estar logado no sistema.
Pós-condição: O funcionário registra a compra.
Fluxo Principal
1. O funcionário seleciona a opção desejada; 2. O sistema solicita como campos (código do produto, quantidade, preço de compra,
preço de venda, data da compra; 3. O funcionário informa os dados e registra a compra. 4. O sistema adiciona os dados no banco e atualiza o estoque da peça comprada.
Fluxo de Exceção [2]: Violação da Regra de Negócio RN-03
2.1. O sistema emite uma mensagem informando que o preço de venda está menor que o preço de compra.
2.2. O sistema retorna ao passo 2, solicitando os campos novamente.
Regras de Negócio Associadas
RN – 03
Quadro 10 - Detalhe do caso de uso CSU - 06
40
2.7.7 Registrar Venda
No Quadro 11 estão descritas as funções para o ator “Registrar
Venda”. Nesse caso de uso, o funcionário informa os dados necessários para o
registro, o sistema adiciona os dados e atualiza o estoque da peça vendida.
Nome Registrar venda CSU-07
Sumário Caso de Uso que descreve os passos para o funcionário registrar uma
venda.
Ator primário: Funcionário
Ator(es) secundário(s): -
Pré-condição: O funcionário tem que estar logado no sistema.
Pós-condição: O funcionário registra a venda.
Fluxo Principal
1. O funcionário seleciona a opção desejada; 2. O sistema solicita como campos (nome do cliente, nome ou código da peça e a
quantidade); 3. O funcionário informa os dados e registra a venda. 4. O sistema registra a venda e encerra o caso de uso.
Fluxo de Exceção[2]: Nome do cliente inválido
2.1. O sistema emite uma mensagem informando que o nome do cliente é inválido. 2.2. O sistema retorna ao passo 2.
Regras de Negócio Associadas
--
Quadro 11 - Detalhe do caso de uso CSU - 07
2.8 Classes de análise
Uma classe de análise descreve um conjunto de objetos que tem as
mesmas propriedades, sejam elas semânticas, operações ou relacionamentos, ou
seja, um objeto é uma instância de uma classe. Elas podem representar pessoas,
carros, outros sistemas, computadores ou tipo de dados, entre outros, as classes se
manifestam por entidades externas, coisas, papéis, eventos, unidades
organizacionais, lugares e estruturas. Cada classe tem um conjunto de atributos e
operações, as mesmas estão relacionadas entre si por uma variedade de modos e
são modeladas por meio de diagramas UML.
41
Segundo Booch, Rumbauch, & Jacobson (2000, p.48):
[...] Uma classe é uma abstração de itens que fazem parte do seu
vocabulário. A classe não é um objeto individual, mas representa um
conjunto inteiro de objetos. Portanto você pode pensar conceitualmente em
“parede” como uma classe de objetos com determinadas propriedades
comuns, como altura, largura, espessura, suportar ou não pesos e assim
por diante. Você pode também considerar instâncias individuais de paredes,
como “a parede do lado sudoeste do meu escritório”. [...] No caso de
software, muitas linguagens de programação dispõem de suporte direto
para o conceito de classe. Isso é excelente, pois significa que as abstrações
que você criar podem ser mapeadas diretamente para a linguagem de
programação, ainda que sejam abstrações de itens que não sejam software,
como “cliente”, “transação” ou “conversação”.
A representação gráfica de uma classe é feita através de um retângulo,
e as suas abstrações são formadas pelo nome da classe, atributos e operações. O
nome da classe é o identificador dela; os atributos correspondem às informações
que os objetos armazenam, portanto uma classe pode ter vários atributos; as
operações correspondem às ações que um objeto sabe realizar, quando um objeto
solicita uma operação ela modifica o seu comportamento.
As classes podem estar relacionadas por multiplicidade, associação,
herança, agregação, composição, unária ou reflexiva, associativa, associação
ternária ou dependência. Cada uma representa uma forma diferente de uma classe
se relacionar com outra.
2.9 Diagrama de classes de análise
O diagrama de classes é considerado por vários autores como o mais
importante e utilizado diagrama da UML. Ele apresenta uma visão estática da
organização das classes do sistema, permitindo além da visualização das classes e
de seus atributos e métodos, a representação de seus relacionamentos, como estas
se complementam e a transmissão da informação dentro do sistema (SILVA, 2007)
Seguindo o levantamento das necessidades e requisitos para
implementação foi desenvolvido o diagrama de classes do sistema SGA que é
apresentado na Figura 2 com suas respectivas classes e relacionamentos.
42
Figura 2 - Diagrama de classes
43
As classes levantadas no projeto SGA e que fazem parte do diagrama,
seguem abaixo com suas respectivas funcionalidades:
Fornecedor: responsável pela manutenção de fornecedores, cadastro e
consulta, e pelas relações dessa classe com as outras.
Funcionário: responsável pelo cadastro de novos funcionários e pelas
associações do mesmo.
Cliente: mantém o cadastro e consulta de clientes.
Produto: responsável pela manutenção de produtos, associações e
relacionamentos do mesmo.
Item: mantém as funções relacionadas as associações do item.
Compra: responsável pelo registro de compras e as suas associações.
Venda: responsável pelo registro de venda e suas associações.
Operação: responsável pelo registro de uma operação, verificação do
tipo de operação, e mantém as suas associações e os seus relacionamentos.
2.10 Diagramas de Seqüência
Os diagramas de seqüência são usados para representar a seqüência
dos eventos de sistema levando em consideração os casos de uso do sistema. Esse
diagrama tem como elementos atores e instâncias de objetos que fazem parte do
sistema, sendo que o ator só pode se comunicar com o objeto interface. Cada
elemento do diagrama de seqüência tem uma linha do tempo indicando os eventos
que poderão ocorrer; se a linha estiver tracejada, nenhum evento está ocorrendo,
portanto o ator ou sistema está inativo. As linhas horizontais do diagrama
representam o fluxo de informação do evento que está acontecendo, é importante
lembrar que nesse tipo de diagrama, nenhuma informação pode ser criada no
decorrer de um processo, as informações são transferidas ou transformadas.
O diagrama de seqüência é construído de acordo com o fluxo principal
do caso de uso, mas pode ser que os fluxos alternativos também sejam
implementados no mesmo. Esse diagrama é usado para estabelecer as operações e
consultas de sistema que serão necessárias, ou, para saber quais as informações
serão repassadas dos atores para o sistema e vice-versa.
44
Conforme a Figura 3, o funcionário solicita a opção de manter clientes
que pode ser: cadastrar um novo cliente, editar um que já existe ou excluir o mesmo;
essa solicitação é encaminhada ao controlador e entidade do sistema, dependendo
da solicitação a tela é apresentada com os campos a serem preenchidos.
Figura 3 – Diagrama de Seqüência do Caso de Uso Manutenção de Clientes
Esse processo de manutenção se estende para outros casos de uso,
como na Figura 4, a manutenção de funcionários da empresa também é feita pelo
sistema e o gerente pode cadastrar, editar e excluir o registro salvo. Para manter um
funcionário no sistema, é necessário o ator gerente, pois só ele tem permissão para
tal.
45
Figura 4 - Diagrama de Seqüência do Caso de Uso Manutenção de Funcionários
A manutenção de fornecedores tem a mesma seqüência das outras
manutenções, porém para cada alteração nos determinados caso de uso é
importante lembrar que as entidades e controladores são diferentes, cada caso de
uso possui o seu, conforme representado na Figura 5.
46
Figura 5 - Diagrama de Seqüência do Caso de Uso Manutenção de Fornecedores
O cadastro, edição, e exclusão de produtos são representados pela
Figura 6. Essa manutenção deve ser feita por um funcionário da autopeça.
47
Figura 6 - Diagrama de Seqüência do Caso de Uso Manutenção de Produtos
Para qualquer alteração nos dados do sistema, o funcionário da
empresa deve efetuar o login no sistema, digitar o seu usuário e senha, e só depois
de autenticados eles podem alterar. A Figura 7 está representando esse fluxo, o
funcionário solicita o login, insere os dados necessários e se o login for bem
sucedido, pode trabalhar no sistema. Caso contrário, o sistema emite uma
mensagem informando que o usuário e ou senha do sistema estão incorretos.
48
Figura 7 - Diagrama de Seqüência do Caso de Uso Efetuar Login
49
3 PERSISTÊNCIA DE DADOS
Nos últimos anos, a importância dos sistemas computacionais para as
organizações veio evoluindo gradualmente, de forma que, para se manter
competitiva no mercado, as empresas necessitam, além de aplicações robustas e
performáticas, de acesso rápido e eficiente às informações.
Os primeiros sistemas computacionais eram utilizados para realizar
cálculos e operações de forma mais rápida. Porém, não conseguiam armazenar as
informações de forma apropriada. No momento em que a agilidade na recuperação
das informações se tornou fator crítico para o sucesso da corporação, novas
técnicas de persistência e manutenção de dados foram surgindo, e estimulando a
evolução tecnológica dos sistemas de banco de dados.
Devemos entender por persistência, a capacidade de “eternizar” as
informações presentes na memória volátil do sistema operacional, armazenando tais
dados em um meio recuperável, como exemplo um disco rígido ou um arquivo de
texto num CD ou DVD.
A maioria dos aplicativos requer dados persistentes. A persistência é
um dos conceitos fundamentais em desenvolvimento de aplicativos. Se um sistema
de informação não preservasse os dados inseridos pelos usuários quando a
máquina anfitriã fosse desligada, o sistema seria de pequeno uso prático (BAUER &
KING, 2005).
A afirmação de Bauer e King (2005) ilustra a importância da
persistência de dados para as aplicações utilizadas atualmente, pois ao se
armazenar os dados de forma coerente e confiável, as empresas podem utilizar as
informações disponíveis de forma simples, rápida e segura, possibilitando a
recuperação destes dados em diversas aplicações simultaneamente.
3.1 Conceitos de banco de dados
Os bancos de dados e seus sistemas se tornaram um componente
essencial para a vida diária das pessoas que vivem em sociedade. Durante o dia
lidamos com várias atividades que envolvem alguma interação com uma base de
50
dados. Como por exemplo, quando vamos ao banco sacar ou depositar dinheiro, se
fazemos uma reserva em algum hotel ou linha aérea, se acessamos um catalogo
computadorizado de alguma livraria ou se compramos algum produto via Comércio
Eletrônico, provavelmente estaremos utilizando de uma base de dados.
Os cenários citados são exemplos do que podemos chamar de
aplicações de banco de dados tradicionais, onde a maioria das informações
armazenadas e acessadas é textual ou numérica. Há alguns anos atrás, os avanços
da tecnologia possibilitaram o desenvolvimento de formas mais modernas de
sistemas de banco de dados. Bases de dados de Multimídia podem agora
armazenar imagens, vídeos e mensagens de som. Os sistemas de informação
Geográficos podem armazenar e analisar mapas, condições climáticas e imagens de
satélite. Os sistemas de Data Warehouse e OLAP (On-Line Analytical Processing)
são usados em várias empresas para extrair e analisar informações úteis de bases
de dados bastante extensas. E as técnicas de busca das bases de dados estão
sendo também aplicadas na Internet para otimizar a procura por informação
necessárias aos usuários em sua procura pela internet.
Os bancos de dados e suas tecnologias estão se desenvolvendo de
acordo com o crescimento da utilização de sistemas computacionais. Podemos dizer
que eles têm uma função crítica em diversas áreas onde os sistemas
computacionais são utilizados, incluindo negócios, engenharia, medicina, legislação,
educação e ciências, para citar apenas algumas delas. A expressão “banco de
dados” é utilizada tão constantemente que primeiro devemos defini-la (ELMASRI &
NAVATHE, 2005, Tradução nossa).
Nos tempos atuais, muitas pessoas conhecem o termo “banco de
dados” mesmo sem compreender seu significado completo, podemos definir um
banco de dados como uma coleção integrada de registros relacionados logicamente
ou arquivos consolidados em um meio comum que provê dados para um ou
múltiplos usuários.
3.2 Sistema gerenciador de banco de dados – SGBD
Um sistema gerenciador de banco de dados (SGBD) consiste em um
software que organiza o armazenamento de dados. O sistema de banco de dados
51
controla a criação, manutenção e a utilização das estruturas de armazenamento de
dados das organizações sociais e de seus usuários. Isto permite à organização ter
controle sobre o desenvolvimento de sua base de dados através dos
administradores de banco de dados e outros especialistas. Nos grandes sistemas, o
SGBD permite aos usuários e outros sistemas armazenar e recuperar os dados de
uma forma estruturada. Através do sistema de banco de dados é possível realizar
diversas operações para administração da base de dados como inserção, alteração,
exclusão e busca de dados.
Podemos concluir que um sistema de banco de dados tem como
função, não somente armazenar as informações oriundas dos processos de uma
organização, mas principalmente, de administrar e prover esta informação quando
ela se fizer necessária, da forma mais útil e específica possível.
Informações podem ser qualquer coisa que tenha algum significado ao
indivíduo ou à organização e que o sistema deve oferecer, ou seja, qualquer coisa
que seja necessária para auxiliar nas atividades deste indivíduo ou dessa
organização (DATE, 2004).
Baseados na Figura 8 que ilustra um sistema simplificado de banco de
dados iremos abordar os conceitos mais fundamentais a cerca dos componentes
principais de um sistema de banco de dados, tais conceitos serão apresentados de
forma resumida, sem desviar o verdadeiro foco deste trabalho.
52
Figura 8 - Sistema de Banco de Dados
A Figura 8 ilustra de forma bastante simples os principais componentes
de um sistema de banco de dados e a interação que tais elementos têm entre si,
esta relação é de fundamental importância para se compreender o papel de cada
componente deste sistema.
Dados: De uma forma mais bruta, os dados são um conjunto de
números, caracteres, imagens ou outros dispositivos de saída para converter
quantidades físicas em símbolos, num sentido muito extenso. Os dados podem ser
humanos ou processados por uma entrada em um sistema de computador, podendo
ser simplesmente armazenados e tratados neste sistema, ou transmitidos para
outros sistema subsequentes ou através de uma interface humana. A palavra
"dados" é um termo relativo, o tratamento de dados comumente ocorre por etapas,
de modo que os "dados processados" a partir de uma etapa podem ser
considerados os "dados brutos" da próxima etapa (DATE, 2004). Alguns autores
preferem distinguir os termos “dados” e “informações”, referindo-se a dados como a
forma bruta, ou seja, aquilo que é realmente é armazenado no banco de dados, e
informações para se referir ao verdadeiro significado destes dados para o usuário ou
sistemas clientes.
É necessário “trabalhar os dados” para transformá-los em informações, para
53
compará-los com outros resultados, ou ainda para julgar sua adequação a
alguma teoria” (BUSSAB & MORETTIN, 2004).
Hardware: Os componentes de Hardware consistem basicamente em:
- Volume de armazenamento secundário – normalmente discos
magnéticos -, que são usados para manter os dados armazenados, juntamente com
dispositivos de I/O (Input/Output) associados (unidades de disco etc.), controladores
de dispositivos, canais I/O e assim por diante.
- Processador(es) de hardware e memória principal associada, que
são usados para dar suporte à execução do software do sistema de banco de dados.
Software: Entre o banco de dados físico, ou seja, os dados fisicamente
armazenados, e os usuários do sistema existe uma camada de software, conhecida
como sistema gerenciador de bancos de dados (SGBD). Todas as requisições de
acesso aos bancos de dados são tratadas pelo SGBD, os recursos descritos
anteriormente para acrescentar e remover arquivos e tabelas, buscar e editar dados
em tais tabelas são facilidades fornecidas pelo SGBD.
Uma função geral fornecida pelo SGBD é, portanto, a de isolar os
usuários do banco de dados dos detalhes no nível de hardware (assim como
sistemas de linguagens de programação isolam os programadores de aplicações
dos detalhes no nível de hardware). Em outras palavras, o SGBD oferece aos
usuários uma visão do banco de dados elevada e acima do nível de hardware, e ele
admite operações do usuário (como as operações SQL já citadas) que são
expressas em termos dessa visão de nível mais elevado.
O SGBD pode ser considerado o componente de software mais
importante de todo o sistema, mas não é o único. Outros componentes incluem
utilitários, ferramentas de desenvolvimento de aplicações, recursos para auxiliar no
projeto, geradores de relatórios e o gerenciador de transações ou monitor de TP
(Transaction Processing).
O termo SGBD também é utilizado para se referir genericamente a
algum produto específico de algum fornecedor em particular – por exemplo, o
produto DB2 Universal Database da IBM. O termo instância do SGBD, então,
costuma ser usado para se referir à cópia específica de tal produto que está sendo
54
executada em determinada instalação do computador.
Usuários: Consideramos basicamente, três classes gerais de usuários:
Primeiro, há os programadores de aplicações, responsáveis pela
escrita de programas de aplicações de bancos de dados em alguma linguagem de
programação, como COBOL, C++,Java, etc. Esses programas acessam o banco de
dados emitindo a requisição apropriada (normalmente, uma instrução SQL) ao
SGBD. Os programas propriamente ditos podem ser aplicações convencionais em
batch, ou então podem ser aplicações online cuja finalidade é permitir que um
usuário final acesse o banco de dados interativamente, por exemplo, a partir de uma
estação de trabalho ou terminal, ou de um micro-computador. A maioria das
aplicações modernas é do tipo online.
Em seguida, existem os usuários finais, que acessam o banco de
dados interativamente, como já dissemos. Determinado usuário final pode acessar o
banco de dados por meio de umas das aplicações online, ou então, podem usar uma
interface fornecida como parte integrante do SGBD. Essas interfaces oferecidas pelo
fornecedor são admitidas por meio de aplicações online, mas essas aplicações são
internas (built-in), e não escritas pelo usuário. A maior parte dos sistemas inclui pelo
menos uma aplicação interna, chamada processador de linguagem de consulta, por
meio do qual o usuário pode emitir requisições ao banco de dados, tais como
SELECT e INSERT, interativamente ao SGBD. SQL é um exemplo típico de uma
linguagem de consulta, embora comum, na realidade é mal utilizado, já que o verbo
“consultar” sugere apenas busca, enquanto outras linguagens de consulta
normalmente oferecem outras funções.
A última classe citada é o DBA (Data Base Administrator) ou
simplesmente, administrador de banco de dados. O Administrador de banco de
dados é a pessoa responsável pelo planejamento, implementação, manutenção e
reparação do banco de dados de uma organização. Estes profissionais estão
intimamente relacionados algumas outras profissões, como por exemplo, o analista
de banco de dados, o modelador de banco de dados, o analista programador e o
gerente de sistemas. Entre suas principais atividades estão, o monitoramente e
otimização do desempenho e capacidade do banco de dados, planejamento e
requisição para futuras expansões. Eles também podem planejar, coordenar e
implementar medidas de segurança para proteger o sistema de banco de dados.
55
As responsabilidades de um DBA incluem:
• Instalação de novos softwares –Instalar softwares relacionados com o
SGBD, inclusive novas versões e novos aplicativos que se relacionam
com ele.
• Configuração de hardware e software com o administrador do sistema –
Na maioria das vezes os sistemas de software são acessados somente
pelo administrador de sistema. Portanto, cabe ao DBA trabalhar em
conjunto com o administrador para que o software e hardware funcionem
de forma a otimizar o SGBD.
• Administração de segurança da base de dados – Uma das principais
funções do DBA é administrar a segurança do seu ambiente de banco de
dados, administrando contas de usuários, aplicando soluções preventivas
e resolvendo problemas de segurança no ambiente.
• Análise de dados – O Administrador de Banco de Dados analisa os dados
armazenados e deve fazer recomendações de melhoria relacionadas a
performance e ao armazenamento eficiente dos dados.
• Projeto da base de dados – O DBA pode ser envolvido nos primeiros
estágios de projeto de uma base de dados, prevenindo desta forma
alguns problemas que podem ocorrer no futuro.
• Modelagem e otimização de dados – Realizando a modelagem de dados,
é possível otimizar a estrutura do sistema.
Existem vários outros conceitos importantes para a compreensão dos
benefícios do desenvolvimento e uso de aplicações em um ambiente de banco de
dados, segue uma descrição introdutória a estes conceitos escrita com base na
descrição de Date.
Acesso aos dados: este conceito inclui as operações fundamentais
que podem ser aplicados aos dados. Todo sistema gerenciador de banco de dados
provê as seguintes operações básicas:
• Leitura dos dados contidos na base de dados;
• Adicionar dados ao contexto da base de dados;
56
• Atualização de conteúdo da base de dados de forma individual;
• Apagar partes dos dados contidos na base.
Os profissionais que utilizam os sistemas de banco de dados se
referem a estas operações básicas como CRUD:
• C - Create (Criação ou inserção de dados);
• R - Read (Leitura, recuperação de dados);
• U - Update (Atualização de dados);
• D - Delete (Remoção de dados).
Dicionário de Dados: Dentro do contexto de SGBD, um dicionário de
dados é um grupo de tabelas, habilitadas apenas para leitura ou consulta, ou seja, é
uma base de dados, propriamente dita, que entre outras coisas, mantém as
seguintes informações:
• Definição precisa sobre elementos de dados
• Perfis de usuários, papéis e privilégios
• Descrição de objetos
• Integridade de restrições
• Stored procedures (pequeno trecho de programa de computador,
armazenado em um SGBD, que pode ser chamado freqüentemente por
um programa principal) e triggers (ações que devem ser executadas
quando determinados gatilhos acontecerem)
• Estrutura geral da base de dados
• Informação de verificação
• Alocações de espaço
Um dos benefícios de um dicionário de dados bem preparado é a
consistência entre itens de dados através de diferentes tabelas. Por exemplo,
diversas tabelas podem conter números de telefones; utilizando uma definição de
um dicionário de dados bem feito, o formato do campo 'número de telefone' definido
57
com "( )9999-9999" deverá ser obedecido em todas as tabelas que utilizarem esta
informação.
Abstração de dados: é a habilidade para se esconder as
complexidades da estrutura da base de dados nos níveis onde ela não é necessária,
ou seja, a abstração de dados lida com a representação conceitual dos dados de
modo a se implementar algoritmos que possibilitem a solução mais prática dos
problemas apresentados.
Suporte a transação: a transação em uma base de dados se refere ao
modo de tornar a operação que está sendo executada mais segura, uma vez que a
transação é iniciada, ela deve completar todas as tarefas e deixar a base de dados
de uma forma consistente. A tecnologia do banco de dados permite que o SGBD
volte ao seu estado anterior à operação, caso ela não seja completada
corretamente.
O que garante que todas estas transações são executadas
apropriadamente é o gerenciamento de transações do SGBD, ou seja, a
correta execução de uma transação requer que ela forneça as propriedades
ACID (ULLMAN & WIDOW, 1994, Tradução nossa).
Segue a descrição de cada inicial dos quatro requisitos principais de
um processo de transação:
• Atomicidade: requer que todas as operações incluídas na transação
sejam realizadas de forma única, ou seja, uma transação não pode
permitir que apenas parte das operações sejam executadas e finalizadas.
• Consistência: o gerenciador de transações deve garantir que ao final da
execução a base de dados ofereça o nível total de consistência das
informações.
• Isolamento: quando duas ou mais transações são executadas
simultaneamente, seus efeitos devem ser isolados umas das outras. Este
procedimento é importante para evitar que as informações atualizadas em
uma transação, interfiram negativamente no resultado da outra.
58
• Durabilidade: se a transação foi completada com sucesso, as
informações atualizadas não devem ser perdidas por alguma falha do
sistema.
3.3 Arquitetura do banco de dados
Uma das principais vantagens de um banco de dados é que permitem
ao usuário a abstração de dados, que são desnecessários para a maioria dos
usuários de bancos de dados, facilitando desta forma seu uso mais eficiente.
Por estrutura de um banco de dados entendemos os tipos de dados,
relacionamentos e restrições que devem suportar os dados. A maioria dos modelos
também inclui uma série de operações básicas para a recuperação e atualizações
no banco de dados (ELMASRI & NAVATHE, 2005)
A Figura 9 ilustra a arquitetura de três esquemas, que foi proposta para
auxiliar a realização e visualização de algumas características importantes da
abordagem com uso de banco de dados.
• Separação de programas de dados (independência de dados e operação
de programas).
• Suporte a múltiplas visões (views) de usuários.
• Uso de catálogo para armazenar a descrição do banco de dados
(esquema).
Esta arquitetura possui três esquemas que podem ser definidos por
três níveis:
Nível Interno: tem um esquema interno, que descreve a estrutura do
armazenamento físico do banco de dados. Esse esquema utiliza o modelo de dado
físico e descreve os detalhes completos do armazenamento de dados e caminhos de
acesso ao banco de dados.
Nível Conceitual: possui um esquema conceitual, que descreve a
estrutura de todo o banco de dados para a comunidade de usuários. O esquema
conceitual oculta os detalhes das estruturas de armazenamento físico e se concentra
na descrição de entidades, tipos de dados, conexões, operações e usuários e
restrições. Geralmente, um modelo de dados representacional é usado para
59
descrever o esquema conceitual quando o sistema de banco de dados for
implementado. Esse esquema de implementação conceitual é normalmente baseado
em um projeto de esquema conceitual em um modelo de dados de alto nível.
Nível Externo: o nível externo é também conhecido como visão (view)
e abrange os esquemas externos ou visões de usuários. Cada esquema externo
descreve a parte do banco de dados que um grupo de usuários tem interesse e
oculta o restante do banco de dados desse grupo. Como no item anterior, cada
esquema externo é tipicamente implementado usando-se um modelo de dados
representacional, possivelmente baseado em um projeto de esquema externo em
um modelo de dados de alto nível.
Os três esquemas são apenas descrições dos dados, quando na
verdade o dado que existe de fato é o que está no nível físico. Na utilização deste
esquema, cada grupo de usuários refere-se apenas a seu próprio esquema externo,
ou seja, o SGBD deve transformar uma solicitação definida no esquema externo em
uma solicitação do esquema conceitual, para então transformá-la em uma solicitação
do esquema interno a fim de processar o banco de dados armazenado. Se a
solicitação for uma recuperação, o dado extraído do banco de dados armazenado
deve ser reformatado para adaptar-se à visão externa do usuário. Os processos de
transformação de solicitações e resultados entre os níveis são chamados
mapeamentos.
A maioria dos SGBDs não separa a arquitetura de três níveis
completamente, mas suporta a arquitetura de três esquemas de alguma forma.
3.4 A evolução dos sistemas de dados
Atualmente, a maioria das pessoas
sem conhecer seu real significado. Até mesmo entre os profissionais de Tecnologia
da Informação o conhecimento desta expressão não está em nível de detalhe
razoável. O que é banco de dados? O que são dados? É um software? É
onde se armazenam dados? Tem algo de especial na maneira de se armazenar os
dados? Como podemos recuperar estes dados armazenados? Quais são suas
funcionalidades e aplicações? Existem várias questões sobre este tema complexo.
Não só o departament
sistemas de banco de dados. As organizações dependem destes sistemas para
obter informações cruciais de seu negócio, principalmente para poder aproveitá
forma mais eficiente e oportuna possível. A área de
primária de suportar e manter os sistemas de banco de dados em funcionamento, e
devido a importância da base de dados para a empresa, esta responsabilidade é
estendida também aos profissionais a;em dos Administradores de banco de
os líderes de projeto, programadores, analistas de sistemas e de redes também
devem conhecer a importância da abordagem de um banco de dados.
Figura 9 - Esquema de níveis
A evolução dos sistemas de dados
Atualmente, a maioria das pessoas utiliza o termo “banco de dados”
sem conhecer seu real significado. Até mesmo entre os profissionais de Tecnologia
da Informação o conhecimento desta expressão não está em nível de detalhe
razoável. O que é banco de dados? O que são dados? É um software? É
onde se armazenam dados? Tem algo de especial na maneira de se armazenar os
dados? Como podemos recuperar estes dados armazenados? Quais são suas
funcionalidades e aplicações? Existem várias questões sobre este tema complexo.
Não só o departamento de Tecnologia de uma empresa que utiliza os
sistemas de banco de dados. As organizações dependem destes sistemas para
obter informações cruciais de seu negócio, principalmente para poder aproveitá
forma mais eficiente e oportuna possível. A área de TI tem a responsabilidade
primária de suportar e manter os sistemas de banco de dados em funcionamento, e
devido a importância da base de dados para a empresa, esta responsabilidade é
estendida também aos profissionais a;em dos Administradores de banco de
os líderes de projeto, programadores, analistas de sistemas e de redes também
devem conhecer a importância da abordagem de um banco de dados.
60
utiliza o termo “banco de dados”
sem conhecer seu real significado. Até mesmo entre os profissionais de Tecnologia
da Informação o conhecimento desta expressão não está em nível de detalhe
razoável. O que é banco de dados? O que são dados? É um software? É um lugar
onde se armazenam dados? Tem algo de especial na maneira de se armazenar os
dados? Como podemos recuperar estes dados armazenados? Quais são suas
funcionalidades e aplicações? Existem várias questões sobre este tema complexo.
o de Tecnologia de uma empresa que utiliza os
sistemas de banco de dados. As organizações dependem destes sistemas para
obter informações cruciais de seu negócio, principalmente para poder aproveitá-la da
TI tem a responsabilidade
primária de suportar e manter os sistemas de banco de dados em funcionamento, e
devido a importância da base de dados para a empresa, esta responsabilidade é
estendida também aos profissionais a;em dos Administradores de banco de dados,
os líderes de projeto, programadores, analistas de sistemas e de redes também
devem conhecer a importância da abordagem de um banco de dados.
61
Como as grandes organizações conduziam seus negócios antes dos
computadores começarem a ser usados? As empresas sempre precisaram de
informação para executar processos de negócio, vender produtos e serviços e para
satisfazerem a necessidade dos consumidores. Porém os arquivos que suportavam
as operações eram feitos manualmente, os cálculos e faturas eram preparados
manualmente, os departamentos financeiros escreviam manualmente as contas a
pagar e os contracheques.
Quando os computadores foram introduzidos nos anos 60, os sistemas
de computador substituíram estas rotinas manuais. Isto marcou de forma
significativa a forma de armazenar e recuperar dados para as operações do negócio.
A partir dos anos 70, dois fenômenos marcantes e notáveis foram
distintamente observados. A Figura 10 ilustra estes fenômenos.
Figura 10 - Crescimento da tecnologia e da demanda por informação. (Fonte:Database Design and
Development: An Essential Guide for IT Professionals, 2003.)
Primeiramente a demanda por informação teve um considerável
aumento e toda organização. As empresas estão lidando com uma concorrência
cada vez mais agressiva e por isso precisam de uma gama vasta e complexa de
informações para permanecerem no negócio de obter lucro. Segundo, nas ultimas
três décadas temos assistido um crescimento enorme da tecnologia da informação.
Processadores estão se tornando mais rápidos e baratos, os sistemas de operação
se tornaram mais robustos e poderosos, os dispositivos de “storage” tiveram sua
capacidade extremamente aumentada e seus preços se tornaram mais acessíveis.
62
As tecnologias de redes e comunicações agora podem conectar diversos sistemas
sem dificuldade. As aplicações de programação e suas interfaces com os usuários
foram aprimoradas.
A crescente demanda por informação e o crescimento da tecnologia da
informação trabalharam lado a lado para promover a evolução dos sistemas de
banco de dados. Podemos dizer que o crescimento da demanda por informação
influencia na demanda por melhores métodos de armazenagem e recuperação de
dados, por métodos mais rápidos de processamento de dados e métodos mais
eficientes de prover esta informação. O progresso tecnológico por sua vez, estimulou
a capacidade de prestação de diferentes tipos de informação, não somente o que
era executado no dia a dia das operações, mas apoiando a tomada de decisões
estratégicas.
Abaixo estão citados algumas comparações que evidenciam o
considerável crescimento tecnológico descrito neste capitulo. Estas evidências foram
retiradas do artigo “Database Design and Development: An Essential Guide for
IT Professionals” escrito por Paulraj Ponniah:
• Vinte e cinco anos atrás havia apenas 50.000 computadores em todo o
mundo, agora mais de 500.000 computadores são instalados por dia.
• Mais de 80% dos lares americanos possui ao menos um computador,
mais de 70% possui acesso a internet.
• O crescimento da internet e o uso da web tem ofuscado a descoberta do
PC. No início do ano 2000, cerca de 50 milhões de famílias em todo o
mundo foram estimadas para estar usando a internet, este número
cresceu mais de 10 vezes até o final de 2005.
• A 10 anos atrás haviam apenas 50 websites, atualmente, milhares de
websites são criados por minuto.
• Databases com capacidades medidas em terabytes são comuns, a alguns
anos atrás valores em gigabytes ainda eram incomuns.
63
• Nos anos 60, os programadores das grandes corporações tinham que
escrever programas para executar em máquinas de 12K, atualmente, os
computadores pessoais possuem 10.000 vezes mais memória.
O crescimento não está restrito aos casos listados e está presente
tanto no hardware quanto no software. Podemos perceber um crescimento explosivo
em todos os setores da tecnologia da informação.
3.5 Tipos de Banco de Dados
Após conhecer os conceitos de uma base de dados, percebe-se o
quanto este tipo de sistema é importante para a empresa, a informação é um
elemento fundamental para o negócio e deve ser gerenciada, protegida e utilizada
de forma adequada. O banco de dados de uma empresa que mantém seus dados é
uma fonte muito fértil de informações. As organizações são questionadas sobre onde
e como manter seus dados corporativos.
Onde deve a empresa manter estes dados? A empresa deve
centralizá-los em um repositório único? Se sim, quais são as vantagens e
desvantagens? Ou os dados da empresa devem ser separados e divididos em
fragmentos mantidos em localidades diferentes?
A organização deve primeiramente adotar uma destas abordagens,
cada tipo tem seus benefícios e desvantagens, ou seja, a organização deve optar
pela abordagem centralizada ou distribuída de acordo com a sua estrutura
organizacional e seus requisitos de informação.
Segue uma descrição de cada um dos dois tipos:
Centralizada:
64
Figura 11 - Abordagem centralizada. (Fonte:
http://www.shammas.eng.br/acad/sitesalunos0606/bdd/difer.htm).
Bases de dados personalizadas são sempre centralizadas em uma
localização. Se a empresa possui um sistema computacional centralizado, sua base
de dados deve residir em uma localização central. Na arquitetura cliente/servidor, a
base de dados reside em um servidor, toda a base de dados pode ser mantida em
uma única maquina e mantida em uma localização central.
Quando se utiliza o tipo centralizado de base de dados, a sua
manutenção e administração se torna mais fácil, é possível controlar o acesso
concorrente a informações mais facilmente, e controlar os acessos de segurança da
aplicação de uma forma menos trabalhosa. Porém, se a empresa necessita
Porém, se as informações da empresa estão distribuídas em locais
remotos, estes locais devem acessar o banco de dados centralizado
através de links de comunicação, neste caso, a disponibilidade dos dados depende
da capacidade e confiabilidade dos links de comunicação.
Distribuída:
A Figura 12 mostra como os fragmentos da base de dados estão
distribuídas remotamente:
65
Figura 12 - Abordagem distribuída. (Fonte:
http://www.shammas.eng.br/acad/sitesalunos0606/bdd/difer.htm).
As organizações globais e empresas com ampla atividade doméstica
podem ter benefícios com o tipo de bancos de dados distribuídos. Nestas
organizações o processamento computacional também é distribuído, com o
processamento dividido em cada local. Os dados ficam distribuídos em conjuntos
menores de dados. Normalmente, os dados podem ser divididos de acordo com a
sua necessidade de utilização. Cada fragmento dos dados em cada localização deve
ser gerenciado com o mesmo tipo de SGBD.
MySQL
Definimos anteriormente os conceitos principais de um sistema
gerenciador de banco de dados (SGBD), a partir destas definições foi possível
perceber o quanto o SGBD é importante para o funcionamento ideal de uma base de
dados, pois ele é responsável por tarefas fundamentais como manter e manipular, e
recuperar as informações presentes de forma otimizada.
Cada organização deve optar de forma cautelosa pelo sistema que se
adéqüe melhor à estrutura de sua aplicação, levando em consideração a estrutura
dos dados, desempenho, recursos e os contratos de suporte disponíveis. É
necessário se certificar se o SGBD escolhido atende todos os requisitos da
aplicação e sua compatibilidade com o hardware.
Para o desenvolvimento do sistema SGA (Sistema Gerenciador de
Autopeças) foi escolhido o MySQL como SGBD, pois ele é de fácil manutenção e
66
possui uma curva de aprendizado mais simples, além de ser encontrado facilmente
em sua versão livre de licenças (Open Souce). O MySQL atende todas as
necessidades do sistema implementado,
Como o próprio nome indica, o MySQL, utiliza a linguagem SQL
(Structured Query Language) que é o padrão de linguagem mais utilizado em
bancos de dados, e atende perfeitamente às necessidades do sistema
implementado. O sistema gerenciador de bancos de dados MySQL se tornou
popular devido a sua alta performance e principalmente devido à diversos fatores
como sua fácil manutenção e utilização, sua estabilidade em aplicações críticas e
baixo custo de aquisição.
Segundo a documentação do MySQL, o sistema possui as seguintes
características principais:
• Compatibilidade com diversas plataformas;
• Escalabilidade;
• Segurança;
• Conectividade;
• Suporte aos comandos e funções mais utilizados;
• Alta performance;
Funções SQL são implementadas por meio de uma biblioteca de
classes altamente otimizada e com o máximo de performance. Geralmente não há
nenhuma alocação de memória depois da inicialização da pesquisa.
3.6 Modelagem de banco de dados
A modelagem de dados nada mais é do que a tarefa de levantar os
dados utilizados pela empresa e estruturá-los de acordo com as regras de negócio
da corporação. É considerada uma fase essencial para o projeto do sistema de
banco de dados, pois permite o desenvolvimento de uma base de dados mais
consistente, que utiliza os recursos de forma otimizada e tem sua administração
simplificada.
67
“A modelagem de dados ajuda a organizar a forma de pensamento sobre os
dados, demonstrando o significado e a aplicação prática deles. Ela também
estabelece o vínculo entre as necessidades dos usuários e a solução de
software que as atende. Essa modelagem faz com que se tenha uma
redução na complexidade do projeto a um ponto que o projetista possa
compreender e manipular os dados”. (MULLER, 2002).
Normalmente a modelagem de um banco de dados compreende três
perspectivas, são elas, Modelagem Conceitual, Modelagem Lógica e Modelagem
Física. A primeira é usada como representação de alto nível e considera
exclusivamente o ponto do usuário e criador do dado, a segunda já considera alguns
detalhes de implementação, tais como as limitações impostas pelo SGBD, dentre
outras, e a Modelagem Física demonstra como os dados são armazenados
fisicamente.
Uma das abordagens de modelagem de dados mais conhecidas
certamente é a abordagem chamada de entidade/relacionamentos (E/R). Por esta
razão, utilizamos este modelo de dados para representação do projeto do SGA. O
modelo de entidade e relacionamentos é um tipo de modelo lógico baseado em
objetos e facilita a descrição dos dados nos níveis conceituais e de visão.
O modelo Entidade – Relacionamento baseia-se numa percepção do
mundo real que consiste em uma coleção de entidades e relacionamentos entre
estas entidades, permitindo representar graficamente a estrutura lógica do banco de
dados da aplicação desenvolvida.
Segue uma breve descrição dos principais elementos do modelo
Entidade-Relacionamento, escrita com base em (DATE, 2004):
Entidade: representa um objeto que tem importância para o sistema de
banco de dados. As entidades podem ser normais ou fracas, estas dependem
sempre de alguma outra entidade para poderem existir, enquanto as entidades
normais têm sentido por si mesmas. Além do fator de dependência necessário à
existência das entidades, elas também são divididas entre entidades concretas e
abstratas. As entidades concretas são aquelas que têm existência física, como um
Cliente ou um Produto, as entidades abstratas são aquelas que tem essência
68
somente conceitual.
Relacionamento: é basicamente a associação entre as entidades.
Esta associação ilustra a relação e a multiplicidade que as entidades possuem entre
si. O relacionamento entre entidades possui níveis que informam se a entidade se
relaciona consigo mesmo, com outra entidade ou com mais de uma entidade
diferente.
Atributo: corresponde a alguma propriedade específica que ajuda na
descrição de uma entidade. Cada atributo tem um nome e evidencia o tipo possível
para ele, por exemplo, todo os fornecedores tem um nome, um CNPJ, um endereço
e assim por diante. A entidade deve possuir um atributo único que a diferencia dos
demais, como, por exemplo, o atributo “fun_matricula” da entidade ”FUNCIONARIO”.
A modelagem de dados é a primeira etapa de um projeto que envolva banco
de dados e tem como seu principal objetivo o desenvolvimento de um
modelo que contenha entidades e relacionamentos, e que com isso seja
possível representar as especificações das informações do negócio
(OLIVEIRA, 2000).
Na Figura 13 é possível observar o diagrama de entidade e
relacionamento (DER) resultante do processo de modelagem do projeto:
69
Figura 13 - Diagrama Entidade e Relacionamento - DER
Explicando o Modelo
No diagrama de entidade e relacionamento apresentado na Figura 13 é
possível observar as seguintes entidades: Operação, Item, Venda, Compra,
Funcionário, Cliente, Fornecedor, UF e Produto.
A entidade Operação é uma generalização das entidades Compra e
Venda, quando alguma compra ou venda é realizada, cria-se uma operação com
alguns atributos que podem ser tanto de venda quanto de compra. O Atributo que
identifica a Operação é o “ope_codigo”. Cada Operação possui os atributos, tipo
(ope_tipo), data (ope_data) e valor(ope_valor) da venda ou compra realizada.
A entidade Venda possui como atributos o seu código (ven_codigo),
operação realizada (Operacao_ope_codigo), código do cliente que realizou a
compra (Cliente_cli_codigo), o tipo da venda realizada (vem_tipo) e a data agendada
para o pagamento (vem_data_pagamento).
70
Os dados de uma compra serão gravados na entidade Compra, que
possui como atributos o código da compra (com_codigo), código da operação
realizada (Operacao_ope_codigo), código do fornecedor daquela compra
(Fornecedor_for_codigo ), o tipo da compra (com_tipo) e a data agendada para
pagamento (com_data_pagamento).
A entidade Item os itens de uma operação de venda ou compra, possui
como chaves primárias os atributos número do item (ite_numero) e código da
operação (Operacao_ope_codigo), representando que uma compra pode conter
vários itens. Os itens são de um produto e possuem um preço unitário
(ite_valor_unitario) e uma quantidade (ite_quantidade).
O produto é identificado por seu código (pro_codigo), possui um nome
(pro_nome), uma descrição (pro_descricao), o preço pelo qual foi adquirido
(pro_preco_custo), a quantidade (pro_quantidade) e o preço de sua venda
(pro_preco_venda).
A entidade Fornecedor possui dados referentes a ele, bem como a
pessoa jurídica que o representa. A entidade conta com o atributo chave
“for_código” que representa o código do fornecedor. Possui dados importantes como
o número do CNPJ (for_cnpj), endereço (for_endereco) , nome da empresa
(for_nome) , telefone (for_telefone), dentre outros.
Para os dados dos clientes, foi implementado a entidade Cliente, que
possui como chave primária o atributo cli_código. Além do código do cliente, a
entidade armazena diversos dados importantes, como nome do cliente (cli_nome) ,
endereço (cli_endereco), telefone para contato (cli_telefone), CPF (cli_cpf_cnpj) ,
dentre outros.
A entidade UF apenas possui o código do estado (uf_codigo), utilizado
como chave primária, e o nome da Unidade (uf_nome).
Os dados dos funcionários da empresa são armazenados na entidade
Funcionario(fun_matricula). Cada funcionário possui um número de matricula único e
os demais dados utilizados para sua identificação (nome, endereço, telefone, CPF).
71
3.7 Mapeamento Objeto Relacional
3.7.1 Conceito
O mapeamento objeto/relacional é a automatização em relação a
persistência de objetos complexos nas tabelas de um SGBD relacional, ou seja,
ORM sigla em inglês de mapeamento objeto/relacional nada mais é que a maneira
com que são armazenados os objetos por uma aplicação Java no banco de dados
relacional no caso deste projeto.
ORM não é um plugin Visio? O acrônimo ORM também pode significar
modelagem do papel de objetos, e este termo foi inventado antes de o
mapeamento objeto/relacional tornar-se relevante. Ele descreve um método
para análise da informação, usado em modelagem de banco de dados, e é
suportado principalmente pela Microsoft Visio, uma ferramenta de
modelagem gráfica. (BAUER & KING, 2005)
O ORM consiste em quatro funções importantes:
• Uma API que executa as funções básicas: Criar, Ler, Atualizar e Apagar.
• Uma linguagem ou API que da suporte as referências as classes e suas
propriedades em consultas.
• Recurso para definir o mapeamento dos meta-dados.
• Técnicas de implementação onde a iteração com objetos transacionais
seja mais efetiva e otimizada.
O ORM foi criado com intuito de facilitar a vida do desenvolvimento
quando se pensa em persistência dos dados em se tratando de Orientação a
Objetos (OO). Então, fez-se necessário uma forma onde seja mais simples a
implementação de sistemas através de mapeamentos dos objetos utilizando
arquivos XML. Mas, se comenta em relação a novas tecnologias de SGBD’s que
suportarão tipos de dados mais complexos. SGBD’s OO que teoricamente
substituirão os relacionais.
Alem das funções apresentadas anteriormente o ORM, tem também
níveis de qualidade diferentes, são quatro ao todo:
72
Relacional Puro
Toda a parte que envolve persistência dos dados é construída
manualmente e diretamente em SQL / JDBC, ou seja, o código SQL estará presente
na aplicação, trazendo para o desenvolvedor em aplicações de pequeno porte
facilidades. Mas, uma grande dificuldade quando se tratar de grandes aplicativos,
perdendo a portabilidade que é o grande ganho com o ORM e suas API’s. Dessa
forma algumas atividades sejam interpretadas como do banco de dados e na
verdade fazem parte da camada de negócios.
Mapeamento de Objetos Leves
Classes representam diretamente as tabelas nos bancos relacionais,
através de mapeamentos feitos manualmente, utiliza padrões e são mapeamentos
muito utilizados em aplicações com poucas entidades.
Mapeamento Objetos Médios
Este tipo de mapeamento é utilizado através de framework. As
instruções SQL são geradas em tempo de execução em sua maioria ou em tempo
de construção. Pode-se utilizar uma linguagem que consegue interpretar expressões
orientadas a objetos, exemplo: HQL – Hibernate Query Language.
Mapeamento Completo de Objetos
Neste tipo de mapeamento podem-se conseguir vários tipos de
modelagens de objetos: a composição, herança e polimorfismo. O mapeamento
completo não é intrusivo, ou seja, não obriga que as classes tenham que herdar algo
de alguma classe da API, nem precise implementar nenhuma interface pré
estabelecida. Um mapeamento deste tipo requer muito tempo de desenvolvimento,
pois existem funcionalidades: busca ociosa e busca ávida e técnicas de
armazenamento que requerem maior criticidade.
3.7.2 Motivação do uso de ORM
Claro que existem muitas maneiras de se fazer persistência, mas, o
73
que levaria um desenvolvedor que já tem que utilizar várias ferramentas e
framework’s complexas e colocar em seu código outra ainda sim também complexa.
Diz-se que com ORM o desenvolvedor fica longe de instruções SQL,
mas, para que uma aplicação possa ter a persistência com ORM é preciso que o
desenvolvedor esteja bem familiarizado com tais instruções então, o ganho na
verdade não é a fuga do SQL e sim o ganho com produtividade e escalabiliade das
aplicações, acredita-se que com ORM possa diminuir e muito o tempo de
desenvolvimento de uma aplicação comercial e oferecer facilidade de manutenção
no futuro.
Produtividade
Com o mapeamento ORM, tem-se um ganho de produtividade grande,
pois muitas instruções SQL que eram feitas manualmente passam a serem
implementadas no código da aplicação. Neste projeto foi feito através de
“annotations” presentes no JDK 5.0, utilizando Hibernate como framework para este
procedimento.
Manutenção
O mais interessante de utilizar o ORM, é a portabilidade e facilidade de
manutenções futuras, pois dentro do código da aplicação têm-se anotações que
podem ser modificadas, e caso haja a necessidade de mudança na classe basta
mudar o mapeamento. E como se tem um código mais enxuto e compreensível
devido ao foco nas regras do negócio. Quando se cria manualmente tudo
relacionado a persistência se mudar algo em outra parte da aplicação isso pode
afetar a persistência também. Então, gera um retrabalho que não ajuda em nada o
desenvolvimento. Códigos que possam ser reaproveitados podem ajudar em futuras
intervenções.
Desempenho
Este assunto é bem discutido, pois busca-se a melhor performance a
todos custo mas, o que define se uma aplicação tem um bom ou mal desempenho
não é a maneira como foi implementada a sua persistência, pois em algumas casos
dependendo do banco de dados tem-se uma performance melhor e outros não, claro
74
que com o ORM ganha-se tempo no desenvolvimento mas, pode ou perder em
desempenho, depende da necessidade da aplicação, uma vez que quando se cria
algo manualmente, pode-se perder em escalabilidade.
Independência do Fornecedor
Hoje no mercado encontram-se vários fornecedores de banco de
dados, com o mapeamento objeto/relacional, temos um ganho considerável no que
diz respeito a tecnologias, claro que para termos uma grande portabilidade e poder
utilizar qualquer tecnologia, tem que se utilizar de recursos mais poderosos, no caso
deste projeto o Hibernate suporta vários tipos de bancos de dados diferentes, caso
houvesse a necessidade de mudança de tecnologia, bastaria neste caso mudar o
driver JDBC, para o SGBD, não afetando em nada a infra-estrutura da aplicação.
3.7.3 Ferramentas de mapeamento objeto/relacional
O Quadro 12 com as ferramentas que implementam o mapeamento
objeto/relacional e suas respectivas linguagens compatíveis:
Ferramenta Linguagem DBlx:Class Perl
SQLObject Python
/Hibernate Java
OJB Java
Django (framework web) Python
ECO – Enterprise Core Delphi
EntityORM .Net
Doctrine PHP
NHibernate .Net Quadro 12 - Listagem de ferramentas de ORM
3.7.4 Mapeamento objeto/relacional
No código a seguir pode-se ver como foi feito o mapeamento no objeto-
relacional no projeto SGA através de “annotations” do framework Hibernate:
A Figura 14 representa as anotações de atributos:
@Id � Para o identificador do objeto, que representa a chave primária
na tabela.
@GenerateValue
primária.
@Column �
colunas desde que os nomes dos atributos nas tabelas do banco
nomes de atributos nas classes entidades. Dentro desta anotação pode
comprimento se é de preenchimento obrigató
Na Figura 15
@GenerateValue � Define qual será a estratégia para gerar a chave
É opcional esta anotação para definir os nomes das
colunas desde que os nomes dos atributos nas tabelas do banco correspondam
nomes de atributos nas classes entidades. Dentro desta anotação pode
comprimento se é de preenchimento obrigatório e se é do tipo de registro único.
Figura 14 - Anotações dos atributos
pode-se ver as anotações referente a chave estrangeira.
75
Define qual será a estratégia para gerar a chave
É opcional esta anotação para definir os nomes das
correspondam aos
nomes de atributos nas classes entidades. Dentro desta anotação pode-se definir:
rio e se é do tipo de registro único.
se ver as anotações referente a chave estrangeira.
Figura
Na Figura 16 têm
@OneToOne
@OneToMany
@ManyToOne
@ManyToMany
3.8 Framework Hibernate
3.8.1 Introdução
Em muitos anos de tecnologias, era discutido em muitos casos sobre a
persistência dos dados, ou seja, em várias oportunidades o assunto era como
armazenar os dados dos aplicativos, uma vez que
e discrepantes de fazê-la, mas
dinâmica e simples de se persistir os dados.
Graças a esforços de uma equipe dedicada foi criado um
aonde teoricamente viria resolver todos os problemas com relação a persistência
dos dados, para que os procedimentos CRUD em SQL e JDBC sejam
automatizados e que possam ser acessados pelo desenvolvedor Java
primeiramente, depois se difundiu numa outra versão pa
NHibernate. A proposta do
Figura 15 - Anotação chave estrangeira
têm-se as anotações dos relacionamentos, que são elas:
@OneToOne � Um para um
@OneToMany � Um para muitos
@ManyToOne � Muitos para um
@ManyToMany � Muitos para muitos
Figura 16 - Anotação relacionamento
Framework Hibernate
Introdução
Em muitos anos de tecnologias, era discutido em muitos casos sobre a
persistência dos dados, ou seja, em várias oportunidades o assunto era como
armazenar os dados dos aplicativos, uma vez que existiam muitas formas d
, mas, não existia um padrão ou mesmo uma forma mais
dinâmica e simples de se persistir os dados.
Graças a esforços de uma equipe dedicada foi criado um
teoricamente viria resolver todos os problemas com relação a persistência
dos dados, para que os procedimentos CRUD em SQL e JDBC sejam
automatizados e que possam ser acessados pelo desenvolvedor Java
primeiramente, depois se difundiu numa outra versão para aplicações .Net o
. A proposta do Hibernate era promissora, pois muitas rotinas que eram
76
as anotações dos relacionamentos, que são elas:
Em muitos anos de tecnologias, era discutido em muitos casos sobre a
persistência dos dados, ou seja, em várias oportunidades o assunto era como
muitas formas diferentes
, não existia um padrão ou mesmo uma forma mais
Graças a esforços de uma equipe dedicada foi criado um framework
teoricamente viria resolver todos os problemas com relação a persistência
dos dados, para que os procedimentos CRUD em SQL e JDBC sejam
automatizados e que possam ser acessados pelo desenvolvedor Java
ra aplicações .Net o
era promissora, pois muitas rotinas que eram
77
feitas manualmente, por desenvolvedores seriam automatizadas com a criação de
entidades e métodos que executariam processos dentro dos SGBD’s.
3.9 Historia
O Hibernate tem um papel interessante e fundamental dentro dos
aplicativos Java, pois sendo uma linguagem OO tinha-se uma dificuldade enorme
em persistir tipos de objetos complexos em bancos de dados relacionais então,
devido ao surgimento do mapeamento do objeto/relacional chegou-se a esse
framework que não é intrusivo, ou seja, não exige que se estenda uma classe
própria ou que se implemente uma interface. Nos dias atuais o Hibernate já está
presente em muitos aplicativos comerciais e vem conquistando cada vez mais
espaço devido a sua licença gratuita LGPL e a documentação que está cada vez
mais completa e dando suporte a mais funcionalidades.
O Hibernate foi criado por uma equipe Java liderava por Gavin King,
que trabalhava neste projeto apenas nos tempos livres, mas como com o passar do
tempo o projeto tomou proporções maiores, passou a ser inviável continuar com esta
forma de trabalho, foi quando King decidiu aceitar uma proposta e passou a fazer
parte do JBoss Group, onde pode se dedicar integralmente ao projeto e ainda ser
remunerado por isso. O Hibernate teve uma versão lançada pela primeira vez em
2004 e já conta com sua versão 3.0 que proporciona mais funcionalidades e
ferramentas ao desenvolvedor tais como: Interceptor/Callback filtros parametrizáveis
e anotações do JDK 1.5. O framework é mantido pelo JBoss Group em duas
equipes, uma comanda por KING e outra dedicada exclusivamente ao Hibernate,
focada em treinamentos, suporte e consultoria aos usuários do Hibernate.
3.9.1 Arquitetura
O framework foi desenvolvido em vários pacotes Java, ou seja, cada
pacote tem funcionalidades diferentes que à medida que se necessite de recursos
pode-se utilizá-los, alguns pacotes se encontram disponíveis somente a partir do
JDK 1.5. No Quadro 13 abaixo se pode ver os pacotes e uma breve descrição dos
mesmos.
Pacote Hibernate Core Hibernate para Java, API’s nativas e metadados XMLHibernate Mapeia as classes com Hibernate API de persistência Java padrão para Java SE e Java EE.Hibernate Shards Framework para particionamento horizontal dos dadosHibernate Tools Ferramentas de desenvolvimento para Eclipse e AntHibernate Seam Framework para aplicações JSF, Ajax, EJB 3.0 / Java EE
Quadro 13 - Lista de pacotes Hibernate. Fonte
• Hibernate CoreHibernate CoreHibernate CoreHibernate Core
O Hibernate Core
está presente em todas as aplicações Java que utilizam o
ferramenta para o mapeamento objeto/relacional. Este pacote proporciona um
persistência transparente, exige apenas que para uma cl
mesma possua um construtor default, ou seja, um construtor sem parâmetros. Neste
pacote pode-se utilizar para consultas o próprio SQL diretamente, uma linguagem
própria do framework que é o HQL
consultas dinâmicas e orientadas a objetos ou ainda utilizar uma API de
“Criteria”, neste projeto foi utilizada a esta API.
Descrição Hibernate para Java, API’s nativas e metadados XMLMapeia as classes com anotações do JDK 1.5 API de persistência Java padrão para Java SE e Java EE.Framework para particionamento horizontal dos dadosFerramentas de desenvolvimento para Eclipse e AntFramework para aplicações JSF, Ajax, EJB 3.0 / Java EE
Lista de pacotes Hibernate. Fonte – Java Magazine 2009. Edição 73 p. 4
Hibernate Core como o próprio nome diz, é o coração do framework,
está presente em todas as aplicações Java que utilizam o Hibernate
ferramenta para o mapeamento objeto/relacional. Este pacote proporciona um
persistência transparente, exige apenas que para uma classe ser persistente, a
mesma possua um construtor default, ou seja, um construtor sem parâmetros. Neste
se utilizar para consultas o próprio SQL diretamente, uma linguagem
que é o HQL – Hibernate Query Language, o qual pro
consultas dinâmicas e orientadas a objetos ou ainda utilizar uma API de
, neste projeto foi utilizada a esta API.
Figura 17 - Construtor Entidade
78
Hibernate para Java, API’s nativas e metadados XML
API de persistência Java padrão para Java SE e Java EE. Framework para particionamento horizontal dos dados Ferramentas de desenvolvimento para Eclipse e Ant Framework para aplicações JSF, Ajax, EJB 3.0 / Java EE
Java Magazine 2009. Edição 73 p. 4
como o próprio nome diz, é o coração do framework,
Hibernate como
ferramenta para o mapeamento objeto/relacional. Este pacote proporciona uma
asse ser persistente, a
mesma possua um construtor default, ou seja, um construtor sem parâmetros. Neste
se utilizar para consultas o próprio SQL diretamente, uma linguagem
, o qual provê
consultas dinâmicas e orientadas a objetos ou ainda utilizar uma API de queries
Figura
• Hibernate AnnotationsHibernate AnnotationsHibernate AnnotationsHibernate Annotations
Era necessário metadados que gerenciassem no mapeamento
objeto/relacional as transformações de uma representação para outra. Em versões
anteriores à utilizada neste projeto era necessário configurações em arquivos XML
para que tivéssemos tal gerenciamento
era mais necessário, pois a partir do JDK 5.0 pode
através de anotações chamadas de
• HiberHiberHiberHibernate EntityManagernate EntityManagernate EntityManagernate EntityManager
A API EntityManager
Figura 18 - Consulta utilizando API Criteria
Hibernate AnnotationsHibernate AnnotationsHibernate AnnotationsHibernate Annotations
Era necessário metadados que gerenciassem no mapeamento
objeto/relacional as transformações de uma representação para outra. Em versões
anteriores à utilizada neste projeto era necessário configurações em arquivos XML
que tivéssemos tal gerenciamento. Mas, na versão 3.2 em diante isso já não
era mais necessário, pois a partir do JDK 5.0 pode-se fazer este mesmo papel
através de anotações chamadas de “annotations”.
Figura 19 - Annotations
nate EntityManagernate EntityManagernate EntityManagernate EntityManager
EntityManager tem por objetivo gerenciar unidades de
79
Era necessário metadados que gerenciassem no mapeamento
objeto/relacional as transformações de uma representação para outra. Em versões
anteriores à utilizada neste projeto era necessário configurações em arquivos XML
, na versão 3.2 em diante isso já não
se fazer este mesmo papel
tem por objetivo gerenciar unidades de
80
persistência, devido a muitas necessidades fez-se necessário a criação de unidades
de persistência onde possamos controlar e gerenciar dados em SGBD`s diferentes.
Com a API isso passou a ser possível e fácil para ser gerenciado.
• Hibernate ShardsHibernate ShardsHibernate ShardsHibernate Shards
O Hibernate Shards é um pacote que tem por objetivo particionar
horizontalmente a persistência para Hibernate Core, se se tem um grande volume de
dados e ainda em SGBD`s diferentes então, o Hibernate Shards vem para
encapsular e minimizar a complexidade trazendo suporte para o particionamento.
• Hibernate ValidatorHibernate ValidatorHibernate ValidatorHibernate Validator
Esta API não está vinculada a nenhuma camada da aplicação e está
disponível do lado do servidor com para os clientes desenvolvedores de aplicações
SWING. O objetivo principal é gerar restrições (validações) através de anotações
nas classes. Existem anotações pré definidas, ex: @NotNull, @Email, @Max, etc.
Mas, também pode-se implementar regras novas.
Exemplo de validação:
public class Address
{
@NotNull
private String line1;
private String line2;
private String zip;
private String state;
@Length(max = 20)
@NotNull
private String country;
@Range(min = -2, max = 50, message = "Floor out of range")
public int floor;
...
}
81
• Hibernate SearchHibernate SearchHibernate SearchHibernate Search
Esta API tem por objetivo aumentar o desempenho de consultas, pois
gerencia e a estrutura dos índices e a do modelo de domínio. A API cuida do objeto,
a tradução do índice, de forma a gerenciá-lo. Então se tem um índice sempre
atualizado, otimizado e com acesso transparente.
• Hibernate ToolsHibernate ToolsHibernate ToolsHibernate Tools
Hibernate Tools é um conjunto de ferramentas que auxiliam no
processo de desenvolvimento com o Hibernate.
• Editor Editor Editor Editor de mapeamentode mapeamentode mapeamentode mapeamento
Ferramenta para a edição de arquivos de mapeamento XML. Nesta
ferramenta pode-se fazer auto-realização e destaque da sintaxe do código XML.
Ainda têm-se auto-semântica de conclusão de nomes de classes, propriedades,
nomes de domínio, nomes de tabela e coluna de nomes.
• ConsoleConsoleConsoleConsole
Esta ferramenta proporciona a possibilidade de gerenciar conexões
com os SGBD’s e ainda possibilita a visualização de classes e seus
relacionamentos. Permite também consultas HQL interativamente, no BD e obter
seus resultados.
• Engenharia reversaEngenharia reversaEngenharia reversaEngenharia reversa
Ferramenta poderosa onde se conectando ao banco de dados da
aplicação pode-se gerar classes de domínio de modelo e arquivos de mapeamento
do Hibernate, EJB3 Beans de entidade anotada. Pode-se obter também toda
documentação em HTML ou até mesmo a aplicação JBoss Seams.
• AssistentesAssistentesAssistentesAssistentes
Existe vários assistentes para a geração automática de configurações
do Hibernate, como o arquivo (config.cfg.xml), até mesmo arquivos de configuração
do console do Hibernate.
82
• Tarefa AntTarefa AntTarefa AntTarefa Ant
Nesta ferramenta pode-se gerar o esquema, o mapeamento da
geração do mesmo ou a geração de código Java que faz parte da construção.
83
4 PROJETO DE INTERFACE
4.1 Introdução
Hoje em dia precisamos de dinamismo quanto às informações
acessadas, pois o mundo se modifica a cada instante. Além das informações, o
cliente necessita que o sistema seja usual, isto é, que seja intuitivo e que não canse
em sua utilização.
Pensando assim, optamos por desenvolver o Sistema de
Gerenciamento de Autopeças, onde o cliente pode acessar os dados referentes ao
seu dia a dia. Para que o sistema seja usável, desenvolvemos páginas dinâmicas
que tem mais flexibilidade no acesso as informações e agilidade na tomada de
decisões.
O projeto de interface é uma peça importante dentro do sistema, uma
vez que ela é a porta de entrada do sistema desenvolvido. Sommerville (2003)
enumera as vantagens do bom desenvolvimento de uma interface:
• Elas são relativamente fáceis de aprender e utilizar. Usuários sem
nenhuma experiência em computação podem aprender a utilizar a
interface depois de uma rápida sessão de treinamento.
• O usuário tem várias telas (janelas) para a interação com o sistema. É
possível alternar de uma tarefa para outra, sem perder de vista as
informações geradas durante a primeira tarefa.
• É possível a interação rápida de tela inteira, com acesso imediato a
qualquer ponto da tela.
• De acordo com as vantagens descritas acima, desenvolvemos uma
interface de fácil uso para que os usuários não tenham dificuldade no uso
e aceso aos dados e que a resposta de suas execuções sejam a mais
rápida possível.
4.2 Interface
Segundo Wazlawick (2004), o projeto de interface se divide em camada
de apresentação e aplicação. A primeira representa
e cujas responsabilidades se resumem a receber dados e comandos do usuário e
apresenta os resultados a ele. E o segundo control
abrindo e fechando janelas, habilitando e desabilitando botões, etc.
Estas camadas foram divididas em p
CSS (Cascading Style Sheets
executado tarefas dos usuário
tratados os dados inseridos e enviados ao tratamento correto de suas execuções
(aplicação). Um exemplo prático e simples é a inserção de um cliente no banco de
dados. Inicialmente o usuário do
assim que o usuário clica em Salvar o
obrigatório em branco, e se o campo CPF ou CNPJ são válidos. Se estiver tudo
certo, o Struts2 encaminha os dados a parte de código
informações inseridas. As
exemplo.
Figura
plicação. A primeira representa os objetos gráficos de interface
e cujas responsabilidades se resumem a receber dados e comandos do usuário e
apresenta os resultados a ele. E o segundo controla o comportamento
abrindo e fechando janelas, habilitando e desabilitando botões, etc.
Estas camadas foram divididas em páginas JSP, HTML
Cascading Style Sheets), onde são inseridos e apresentados os dados e
usuários (apresentação), e por fim o Struts2, onde são
tratados os dados inseridos e enviados ao tratamento correto de suas execuções
. Um exemplo prático e simples é a inserção de um cliente no banco de
dados. Inicialmente o usuário do sistema insere os dados na interface JSP/HTML e
assim que o usuário clica em Salvar o JavaScript verifica se há algum campo
obrigatório em branco, e se o campo CPF ou CNPJ são válidos. Se estiver tudo
certo, o Struts2 encaminha os dados a parte de código que trata os dados e salva as
figuras Figura 20, Figura 21 e Figura 22
Figura 20 - Tela de cadastro de clientes
84
os objetos gráficos de interface
e cujas responsabilidades se resumem a receber dados e comandos do usuário e
o comportamento da interface,
HTML, JavaScript, e
onde são inseridos e apresentados os dados e
, e por fim o Struts2, onde são
tratados os dados inseridos e enviados ao tratamento correto de suas execuções
. Um exemplo prático e simples é a inserção de um cliente no banco de
sistema insere os dados na interface JSP/HTML e
verifica se há algum campo
obrigatório em branco, e se o campo CPF ou CNPJ são válidos. Se estiver tudo
que trata os dados e salva as
22 ilustram este
Figura
Segundo Husted, Dumousin, Franciscus, & Winterfeldt (2004
aplicações Web usam Hipertext
o navegador executado em seu computador e a aplicação executada no servidor.
Este protocolo fornece um mecanismo para enviar dados de um formulário, mas
deixam o recebimento dos dados como um exercício para o desenvolvedor
O sistema web além de apresentar funcionalidade, deve ter boa
aparência e navegabilidade, facilitando ao público alvo
contidas nele, atendendo também às expectativas do negócio.
De acordo com
usuário significa que os comandos e os menus do sistema devem ter o mesmo
Figura 21 - Erro tratamento CPF
Figura 22 - Mensagem de cliente cadastrado
usted, Dumousin, Franciscus, & Winterfeldt (2004
Hipertext Transfer Protocol (HTTP) para mover os dados entre
o navegador executado em seu computador e a aplicação executada no servidor.
Este protocolo fornece um mecanismo para enviar dados de um formulário, mas
deixam o recebimento dos dados como um exercício para o desenvolvedor
O sistema web além de apresentar funcionalidade, deve ter boa
aparência e navegabilidade, facilitando ao público alvo acessar as informações
contidas nele, atendendo também às expectativas do negócio.
De acordo com Sommerville (2003), a consistência da interface com o
usuário significa que os comandos e os menus do sistema devem ter o mesmo
85
usted, Dumousin, Franciscus, & Winterfeldt (2004),
(HTTP) para mover os dados entre
o navegador executado em seu computador e a aplicação executada no servidor.
Este protocolo fornece um mecanismo para enviar dados de um formulário, mas
deixam o recebimento dos dados como um exercício para o desenvolvedor.
O sistema web além de apresentar funcionalidade, deve ter boa
as informações
a interface com o
usuário significa que os comandos e os menus do sistema devem ter o mesmo
86
formato, os parâmetros devem ser fornecidos a todos os comandos da mesma
maneira e a pontuação utilizada nos comandos deve ser similar. Interfaces
consistentes reduzem o tempo de aprendizagem do usuário. O conhecimento
apreendido em um comando ou uma aplicação vale para outras partes do sistema.
De acordo com Sommerville (2003) sobre o princípio da interface
podemos constatar que se a interface tiver uma boa aparência e ter boa
navegabilidade a necessidade de treinamentos podem ser reduzidos, assim
minimizando os custos da empresa. O acesso as informações terão que ser rápidas,
portanto ele precisa ser leve e requisitar o mínimo de recursos da estação que o
executa.
4.3 Usabilidade
É o mesmo que facilidade de uso. Pensando nesta definição, se o
sistema SGA for fácil de ser manuseado, podemos considerar que grande parte do
nosso objetivo foi atingida.
O tipo de interface desenvolvidas em sistemas web é o GUI (interface
gráfica do usuário) onde trás a facilidade no uso, pois ao invés de escrevermos o
que queremos, com um simples click do mouse executamos uma operação.
As interfaces do tipo GUI são normalmente baseadas em metáforas, na
qual os elementos visuais imitam alguma coisa da nossa experiência cotidiana. A
metáfora está presente no desktop do Windows, Mac OS e nas interfaces do Linux
(CAMPOS & SILVA, 2008).
Seguindo a idéia de metáfora, no SGA existem menus que facilitam o
trabalho do usuário do sistema pela facilidade e uso intuitivo dos comandos de
acordo com a Figura 23.
87
Figura 23 - Menu da tela inicial
4.4 Padrões utilizados
A internet é uma rede em evolução que a cada dia nos apresenta algo
novo e se não existisse padronizações, seria complicado atender as demandas
propostas.
Ao pesquisar e estudar padrões/frameworks pode-se pensar na idéia
que “um framework é uma aplicação reutilizável e semicompleta que pode ser
especializada para produzir aplicações personalizadas” (HUSTED, DUMOUSIN,
FRANCIUSCUS, & WINTERFELDT, 2004).
O Consórcio World Wide Web, conhecido também como W3C, é um
consórcio internacional no qual organizações filiadas, uma equipe em tempo integral
e o público trabalham juntos para desenvolver padrões para a Web. A W3C
basicamente cumpre sua missão com a criação de padrões e diretrizes para a Web.
A Principal missão do W3C é:
“Conduzir a World Wide Web para que atinja todo seu potencial,
desenvolvendo protocolos e diretrizes que garantam seu crescimento de
longo prazo.” (W3C, 2008)
Os Padrões Web são recomendações do W3C, as quais são
destinadas a orientar os desenvolvedores para o uso de boas práticas que tornam a
web acessível para todos. A grande vantagem de desenvolver utilizando os padrões
estabelecidos é que ao desenvolver um Site, o mesmo poderá ser acessado por
qualquer pessoa através de qualquer aparelho ou software. Sites que não seguem
esse padrão não são interpretados corretamente pelos navegadores.
Vários padrões e boas práticas definidas em diversas áreas como o
88
HTML semântico, XHTML, CSS e Usabilidade foram definidos. Para facilitar na
manutenção do sistema, o layout do sistema foi definido em uma folha de estilo
separada do conteúdo e da estrutura. A Folha de estilo, conhecida como CSS visa
em separar a apresentação e o conteúdo das páginas, já as marcações HTML
definem como será a semântica do conteúdo e a sua estrutura.
Ao utilizar folha de estilo, é possível visualizar várias vantagens como a
velocidade que o sistema é carregado e facilita em alterações futuras.
A tecnologia utilizada para o desenvolvimento das páginas dinâmicas
foi o JSP, o layout em conjunto com o HTML e Javascript. Para facilitar o
desenvolvimento e aumentar a produtividade foi utilizado uma biblioteca, conhecida
como jQuery, que é um arquivo Javascript gravado com a típica extensão .js, cuja
função é simplificar a sintaxe Javascript. O jQuery possui algumas vantagens de uso
sobre o Javascript tradicional, por exemplo:
• Emprego Cross-Browser (é possível rodar em vários browsers sem afetar
seu funcionamento).
• Manipulação de conteúdos de forma simples, rápida e sem limitações.
• É possível criar vários efeitos de animação com apenas algumas linhas de
código.
Utilizamos alguns frameworks que auxiliaram no direcionamento do
desenvolvedor para os problemas relacionados às regras de negócio do cliente e à
apresentação das informações necessárias para a boa tomada de decisões, onde o
aumento da produtividade, reutilização dos códigos, manutenção simplificada, e a
redução da curva de aprendizagem nos faziam alcançar um objetivo comum que é
minimizar os custos.
4.5 Arquitetura da interface
A estrutura do sistema foi projetada com um menu horizontal abaixo do
nome do sistema desenvolvido usando a biblioteca JQuery, implementada por
JavaScript. Ao passar o mouse sobre qualquer menu abre um sub-menu com as
respectivas atividades, trazendo ao usuário do sistema uma facilidade no que se diz
ao acesso as funcionalidades do SGA, conforme Figura 24.
89
Figura 24 - Estrutura do menu do sistema
Ao utilizarmos o JQuery para implementar as funcionalidades do
JavaScipt conseguimos mais tempo para nos dedicar as funcionalidades chave do
sistema que seria o desenvolvimento dos requisitos e necessidades de negócio da
empresa.
Com o Struts2 conseguimos integrar a interface com a camada de
negócio nos trazendo uma facilidade na implementação das páginas JSP.
Para que o sistema tenha o controle de acesso ao sistema, decidimos
pela utilização Interceptor, que é um framework que filtra toda ação que o Struts2
tentar executar. Configuramos o Interceptor para que nenhuma página seja
acessada sem verificar se existe um usuário conectado.
Segundo Husted, Dumousin, Franciscus, & Winterfeldt (2004), as tags
JSP do Struts fornecem ao desenvolvedor Java a funcionalidade de que eles
precisam atualmente. As tags na biblioteca HTML correspondem muito aos
elementos HTML padrões que geralmente podem ser trocados um pelo outro. Outras
tags do Struts são designadas para afastar o desenvolvedor dos scriplets e ajudá-los
a recompor as aplicações Modelo 1 (Cliente-Servidor) para Modelo 2 (MVC). Em
geral, combinar as tags JSP com a arquitetura MVC Modelo 2 fornece uma
construção mais robusta atualmente e abre a porta para futuras possibilidades.
Pensando em implementação podemos pensar no modelo MVC como
um grande aliado ao desenvolvedor, que na medida em que um está desenvolvendo
uma classe de negócio, o webdesigner pode se preocupar somente com as
funcionalidades da interface, uma vez que se ele estiver ciente das classes de
negócio onde está a descrição dos objetivos de implementação de cada tela do
sistema não terá dificuldades em implementar uma tela de cadastro de clientes por
90
exemplo, conforme a Figura 25.
Figura 25 - Código cadastrarCliente.jsp
Na Figura 25, podemos ver que quando utilizamos a tag label nos
referimos a uma classe de negócio que por sua vez tem um atributo que pode ser
acessado pelo input do código. Desenvolvendo através de camadas, podemos
interagir com as outras camadas e não precisamos saber o que e como realmente
cada camada trabalha, e nem com qual plataforma de desenvolvimento.
Dentro do nosso contexto e ainda trabalhando com a flexibilidade de
troca entre plataformas, implementamos uma WebService que nada mais é que:
“[...] um sistema de software projetado para suportar interação maquina-
maquina interligadas pela web. Tem uma inteface descrita em um formato
processável por máquina (especificamente WSDL). Outros sistemas
interagem com o serviço Web de uma maneira prescrita por sua descrição
usando mensagens SOAP, tipicamente transmitida usando HTTP com
serialização XML em conjunto com outras normas relacionadas à Web.”
(W3C, 2004 – Tradução nossa)
No SGA, implementamos uma WebService implementado em páginas
PHP, apenas para fins de aprendizagem, onde implementamos somente o login do
usuário e o relatório de diversos itens requisitando do sistema desenvolvido em Java
os dados do banco de dados e mostrando na página PHP. As Figura 26 e Figura 27
ilustram um pouco desta implementação.
Figura
Figura
4.6 Resultados
No estudo de
nos tópicos anteriores e que foram aplicadas no SGA. Iremos focar na página
cadastrarCliente.jsp para exemplificarmos nosso estudo.
Quando o usuário logar no sistema
assegurar que o usuário pode acessar estas áreas de trabalho. O
o responsável por guardar esta sessão.
sessão do login do usuário.
Figura 26 - Tela inicial do WebService
Figura 27 - Relatório de clientes cadastrados
No estudo de caso iremos apresentar as tecnologias já demonstradas
nos tópicos anteriores e que foram aplicadas no SGA. Iremos focar na página
cadastrarCliente.jsp para exemplificarmos nosso estudo.
usuário logar no sistema é criado uma sessão para
que o usuário pode acessar estas áreas de trabalho. O Interceptor
o responsável por guardar esta sessão. A Figura 28 mostra o código para salvar a
sessão do login do usuário.
91
caso iremos apresentar as tecnologias já demonstradas
nos tópicos anteriores e que foram aplicadas no SGA. Iremos focar na página
criado uma sessão para
Interceptor que é
mostra o código para salvar a
92
Figura 28 - Código do interceptor criando sessão
Após o usuário ter suas credenciais validadas e a sessão criada, ele
será redirecionado a tela principal do sistema telaInicial.jsp onde é apresentada toda
a área de trabalho do usuário, conforme Figura 29.
Figura 29 - Tela inicial do sistema
Na tela inicial ao pensarmos na usabilidade dos menus e no sistema
como um todo, utilizamos o CSS e JavaScript para arquitetarmos a interace. A
estrutura desta foi dividido em cabeçalho, rodapé, corpo e menu, e que não tem
vínculo uma com a outra, assim quando abrirmos uma funcionalidade não
precisaríamos novamente desenvolver outro menu, cabeçalho, rodapé, etc.
Para que tal implementação funcione, utilizamos uma tag para
incluirmos as partes em uma pagina, conforme Figura 30. Nesta figura estão as
chamadas da tag include onde são incluídas as partes que são em comuns a todas
as páginas. As tags estão destacadas na Figura 30 abaixo em negrito.
93
Figura 30 - Código da página telaInicial.jsp
O menu foi projetado para ao movimentar o cursor do mouse em cima
do menu os submenus são automaticamente abertos. A Figura 31 ilustra como o
menu fica ao mover o cursor ao item desejado.
Figura 31 - Menu de cliente
94
5 ARQUITETURA E CÓDIGO
Arquitetura de software envolve a identificação das principais partes do
sistema e das formas como essas partes devem se comunicar. O framework
estrutural básico para este sistema também é estabelecido no processo de projeto
de arquitetura.
Conforme comentado por Fowler (2003), a arquitetura de um sistema
pode ser compreendida como um “entendimento do design do sistema,
compartilhado por todos os desenvolvedores, que inclui o entendimento de como o
sistema será dividido em componentes e como estes componentes irão interagir”.
Segundo ele, a arquitetura diz respeito às “coisas importantes no sistema, não
importando o que elas sejam”, o que faz dela uma construção social, pelo fato de
depender não apenas do software em si, mas também de quais de suas partes são
importantes para as pessoas envolvidas na sua definição.
Especificar a arquitetura de um sistema é bastante complexo e de
grande importância, já que a arquitetura vai afetar diretamente o desempenho, a
robustez e a facilidade de distribuição e manutenção do sistema. Segundo
Sommerville (2003), a definição da arquitetura depende dos requisitos não
funcionais do sistema, tais como desempenho, proteção, segurança, disponibilidade
e facilidade de manutenção. Conforme o autor, o que aumenta ainda mais a
complexidade para definir a arquitetura é a possibilidade de conflito entre alguns
desses requisitos. Por exemplo, o desempenho é melhorado pelo uso de
componentes de maior granularidade e a facilidade de manutenção, pelo uso de
componentes de menor granularidade. Caso ocorra este conflito, é necessário
encontrar uma solução intermediária, que pode ser conseguida pelo uso de
diferentes estilos de arquitetura para diferentes partes do sistema.
A arquitetura de software de um programa ou sistema computacional é a
estrutura ou estruturas do sistema que abrange componentes de software,
as propriedades externamente visíveis desses componentes e as relações
entre eles. (PRESSMAN, 2006)
Ao se definir de maneira coesa a arquitetura de um sistema, são
95
garantidos alguns benefícios que não seriam atingíveis sem um bom projeto de
arquitetura. Sommerville (2003) afirma que entre estes benefícios podemos
destacar:
• Facilidade de comunicação entre os stakeholders (partes interessadas): em alto nível, a arquitetura é a apresentação do sistema, e pode ser utilizada como ponto de partida de discussão para uma gama de diferentes stakeholders;
• Possibilita uma melhor análise do sistema: ao se tornar clara e explícita a arquitetura em um estágio inicial do sistema já se pode efetuar alguma análise, de forma que as decisões poderão ser mais sólidas, decisões estas que terão um impacto profundo em todo o trabalho de engenharia de software seqüente. Isto será importante também no resultado final do sistema;
• Reutilização em larga escala: a arquitetura do sistema apresenta um modelo relativamente pequeno e inteligível de como o sistema é estruturado e de como seus componentes interagem entre si; este modelo pode ser utilizado para fornecer apoio ao reuso dos componentes do sistema em grande escala.
O processo de projeto de arquitetura pode ser visto de diversas
maneiras diferentes, e a escolha do processo utilizado pelo arquiteto pode depender
de diversas variáveis, como conhecimento, habilidade e intuição. Entretanto, há
algumas atividades que são comuns a todos os processos, tais como, Estruturação
de Sistema, Modelagem de Controle e Decomposição Modular.
5.1 O enfoque de camadas
Atualmente, praticamente todos os sistemas com base em grandes
computadores são sistemas distribuídos, que quase sempre utilizam o modelo de
arquitetura de cliente-servidor. Este modelo proporciona uma visão de como os
dados e o processamento são distribuídos em diversos processadores. De acordo
com Sommerville (2003), os componentes mais importantes desse modelo são:
• Um conjunto de servidores em stand-alone, que oferece serviços a outros subsistemas;
• Um conjunto de clientes que solicita os serviços disponibilizados pelos servidores;
96
• Uma rede que permita esta comunicação entre os clientes e os servidores.
Para analisar uma aplicação distribuída, independente dos
computadores físicos nos quais essa aplicação é executada, é necessário analisar
seus processos lógicos que estão fortemente ligados a distribuição em camadas,
pois se a distribuição em camadas for bem elaborada de forma que a distinção entre
as camadas seja clara, torna-se possível distribuir cada camada em um computador
diferente.
Existem várias maneiras de se distribuir um sistema em camadas.
Porém, é mais comum a divisão em duas ou em três camadas. As arquiteturas
cliente-servidor de duas camadas podem ser de dois tipos: cliente-magro e cliente-
gordo. No cliente-magro, o servidor é responsável pelo processamento da aplicação
e gerenciamento de dados; o cliente somente executa o software de apresentação.
Já no cliente-gordo, o cliente excuta o software de apresentação e também a lógica
da aplicação, enquanto o servidor é responsável somente pelo gerenciamento de
dados. Porém, alguns problemas podem ocorrer ao se usar apenas duas camadas:
se o modelo for cliente-magro, podem ocorrer problemas com a escalabilidade e o
desempenho, e se o modelo for cliente-gordo, há grande probabilidade de
problemas com o gerenciamento do sistema. Para solucionar tais problemas, pode-
se utilizar uma arquitetura cliente-servidor de três camadas (Figura 32– As três
camadas lógicas de um sistema em camadas). Neste modelo cada camada é
processada de forma logicamente separada.
Figura 32 - As três camadas lógicas de um sistema em camadas. (Adaptado de Sommerville, 2003,
p.209)
Para desenvolver um sistema em três camadas não é necessário ter
três sistemas de computador conectados à rede. Apenas um computador já é
suficiente para executar o processamento de aplicações e o gerenciamento de
dados, como servidores lógicos separados. Entretanto, caso haja necessidade, será
97
simples a separação física destas camadas.
As responsabilidades das camadas são distribuídas de forma
individual, e de acordo com Bezerra (2002) é na camada de apresentação que
ocorre a interação com o usuário, ela contem os componentes de interface gráfica. A
camada de integração ou camada de dados é responsável por armazenar,
recuperar, alterar e consultar os dados da aplicação, para isso, o banco de dados é
utilizado, e também reside nesta camada. A por ultimo, a camada de aplicação, ou
camada de negócios, esta camada determina de que forma os dados serão
utilizados, é nesta camada que se encontram as regras do negócio.
Ao projetar a arquitetura em camadas é necessário determinar a forma
que cada camada vai comunicar com as outras levando em consideração que uma
camada não pode ser fortemente ligada as demais, para que, caso haja
necessidade, será possível alterar uma camada se ter que mudar as demais, por
exemplo, ao mudar o nome de algum campo no banco de dados, não será
necessário ajustar a interface, nem a camada de negócios, teremos que mudar
apenas a camada de integração.
5.2 O padrão MVC
Modelo Visão Controle (Model View Controller, MVC) é um modelo de
infra-estrutura, que separa em três camadas uma aplicação interativa, Pressman
(2006) explica que este modelo tem o objetivo de separar a interface com o usuário
das regras de negócio e do armazenamento dos dados do sistema.
Conforme mencionado por Krasner & Pope (1998) o MVC é um padrão
de projeto arquitetural desenvolvido para ambiente Smalltalk e pode ser usado para
qualquer aplicação interativa. Uma representação esquemática da arquitetura MVC é
mostrada na Figura 33 – O padrão MVC.
98
Figura 33 - O padrão MVC. (Adaptado de Pressman, 2006, p.443)
Cada camada do modelo MVC possui uma função específica, a saber:
o Modelo contém todo conteúdo e lógica de processamento específicos da
aplicação. A Visão permite a apresentação do conteúdo, lógica de processamento e
funcionalidades de processamentos requeridas pelo usuário final. O Controlador
gera o acesso entre o modelo e a visão e coordena o fluxo de dados entre eles.
Trabalhando com o modelo MVC, é possível diminuir o acoplamento
entre os domínios, assim, obtém-se agilidade no desenvolvimento e manutenção do
sistema, alem de garantir um aumento no reuso dos componentes do sistema.
99
5.3 Servlets e Java Server Pages
Hall & Brown (2005) explicam que, servlets são programas Java que
rodam em servidores de aplicativos ou na Web, e possui o papel de camada
intermediária entre as requisições feitas pelo usuário e os aplicativos do servidor e o
banco de dados. Suas principais tarefas são: ler o dado explícito enviado pelo
cliente, ler o dado de requisição HTTP implícito enviado pelo browser, gerar os
resultados, enviar os dados explícitos para o cliente e enviar os dados de resposta
HTTP implícitos.
O Java Server Pages JSP é uma tecnologia que permite misturar
HTML estático com um conteúdo gerado dinamicamente, pode-se dizer que, JSP é
uma pagina HTML regular normal acrescentada o código dinâmico utilizando tags
especiais.
Uma visão um tanto super-simplificada de servlets é que são programas
Java com HTML embutido dentro deles. Uma visão um pouco super-
simplificada de documentos JSP é que são páginas HTML com código Java
embutido dentro deles. (HALL & BROWN, 2005)
Definindo essas duas tecnologias de forma superficial, pode se afirmar
que, Servlets e JSPs são tecnologias que provêem conteúdo dinâmico em
aplicações WEB. Ambas serão abordadas de forma mais detalhada mais adiante.
5.4 O Framework Struts2
O Struts2 é um framework opensource direcionado para a criação de
aplicações Web com Java. Segundo Todd e Szolkowski (2003) foi desenvolvido por
Craig McClanahan e doado, em maio de 2002, à Apache Foudation. Baseado na
tecnologia de Servlets e JSP da Sun Microsystems tornou-se muito popular na
construção de aplicações Web que utilizam o padrão MVC.
Apesar de ser parte da camada de apresentação, fornece componentes
responsáveis pelo controle da aplicação. O controle da aplicação ocorre pelo
gerenciamento de ações que atenderão às solicitações feitas e então encaminhadas
para a serem visualizadas da forma correta. Este gerenciamento das solicitações
concentra todas as requisições e as respostas em um único ponto, facilitando o
100
desenvolvimento das aplicações.
Entre os recursos implementados pelo Struts para o controle, tanto da
aplicação, quanto da apresentação, estão:
• Um servlet controlador, chamado ActionServlet;
• Uma classe “action” genérica, chamada “ActionSupport” que sendo
estendida por outras classes do sistema prove uma poderosa ferramenta
para controle da lógica de negócio;
• Uma biblioteca de “tags”, que facilitam a criação de páginas JSP
dinâmicas;
• Um mapeamento, feito em XML, de todas as ações do sistema, chamado
de ActionMapping.
A Figura 34 representa o seu funcionamento simplificado:
Figura 34 - Framework Struts 2. (Fonte: Roughley, 2006, p.11)
Os componentes chamados FilterDispatcher e Interceptors constituem
a implementação do controlador, que recebe e delega requisições. O arquivo
web.xml, presente em todas as aplicações web, contém as informações de
configuração para a aplicação, definindo entre outras coisas qual será o controlador.
O ActionMapping, que é arquivo chamado struts.xml é responsável pelo
101
mapeamento das ações. Cada requisição feita à aplicação é tratada como uma
ação. As actions, que são estendidas da classe ActionSupport, manipulam as
classes de negócio. Ao fim do tratamento da requisição, as páginas JSPs são
responsáveis pela apresentação do conteúdo dinâmico.
O Struts2 encapsula toda a lógica das requisições e resposta, tornando
necessária apenas a configuração do ActionMapping, e a criação das classes action
derivadas da ActionSupport e das páginas JSPs destinadas às respectivas
respostas, com o auxilio das tags do Struts2.
Os passos de uma requisição podem ser resumidos da seguinte forma:
1. A requisição chega à aplicação.
2. O FilterDispatcher filtra a requisição e determina para qual ação ela deve ser encaminhada através do ActionMapping.
3. Interceptors são aplicados: Interceptors são configurados para aplicar funcionalidades comuns tais como validação, upload de arquivos, etc.
4. Uma action executa um método que corresponde à ação específica.
5. A saída é gerada.
6. Ocorre o retorno da requisição através da classe ActionForward.
7. O resultado é exibido para o usuário em uma página JSP.
O uso do Struts traz muitos benefícios para o desenvolvedor, entre eles
o encapsulamento da lógica do MVC e a redução do tempo e do custo de
desenvolvimento do projeto.
5.5 Java Enterprise Edition (JEE)
Java Enterprise Edition é uma plataforma de desenvolvimento Java
voltada para o desenvolvimento de aplicações multicamadas, baseada amplamente
em componentes modulares que serão executados em um servidor de aplicações.
Foi criada a partir da unificação, pelo Java Community Process (JCP), das diversas
APIs e padrões utilizados por desenvolvedores na linguagem Java, sobretudo em
ambiente corporativo. É considerado um padrão de desenvolvimento, uma vez que
os desenvolvedores devem se conformar a diversas especificações estabelecidas
pela plataforma. Entre as especificações podemos citar JDBC, utilizada para acesso
102
a banco de dados, Servlets e JSP, já tratados anteriormente e EJB, usado na
construção de componentes, facilitando na modularidade.
Segundo Alur, Cupi, & Malks (2004), a plataforma J2EE oferece
inúmeras vantagens para corporações, entre elas:
• Estabelece padrões para diversas áreas da empresa que necessitam de
computação;
• Promove implementações baseadas em padrões abertos, preservando o
investimento em tecnologia;
• Proporciona uma plataforma de desenvolvimento portável, independente
de um único fornecedor;
• Aumenta a produtividade dos desenvolvedores, uma vez que é
relativamente fácil aprender a usar as tecnologias baseadas em J2EE;
• Diminui o tempo necessário para o desenvolvimento dos produtos, já que
boa parte da estrutura já é implementada por diversos fornecedores de
acordo com os padrões estabelecidos;
• Promove interoperabilidade em ambientes heterogêneos.
5.6 Padrões de projeto
Padrões de projeto de software são soluções de projetos já utilizadas
em trabalhos anteriores, com um bom resultado. Alur, Crupi e Malks (2004), afirmam
que esses padrões foram popularizados através da obra Design Patterns: Elements
of Reusable Object-Oriented Software, de Erich Gamma, Richard Helm, Ralph
Johnson e John Vlissides (também conhecidos como Gang of Four – Gof, ou gangue
dos quatro). Ainda segundo eles,
[...] um padrão é a comunicação de idéias e soluções
permanentes para problemas recorrentes em um
determinado contexto e que podem ser aplicadas
repetidamente. (ALUR, CRUPI, & MALKS, 2004)
Sommerville (2003) define ‘padrão’ como uma descrição do problema e
a essência de sua solução, de modo que essa solução possa ser utilizada em
diversos casos. O padrão não é uma especificação detalhada para a solução de um
103
problema, mas um conjunto de conhecimentos e experiências acumuladas que
podem ser aplicados. Ainda segundo ele, os padrões de projeto têm estado
inevitavelmente associados com a orientação a objetos.
Neste trabalho foram utilizados os padrões definidos pela arquitetura
JEE. De acordo com Alur, Crupi, & Malks (2004), o catalogo de padrões JEE é
subdividido de acordo com as três camadas de arquitetura: apresentação (visão),
negócio (controle) e integração (modelo). A Figura 35, mostra a divisão em camadas
aplicada à plataforma J2EE, utilizada na arquitetura do SGA.
Figura 35 - Enfoque em camadas. (Adaptado de Alur, Crupi e Malks, 2004, p.102)
Nesta plataforma, a camada de apresentação, ou visão, encapsula a
lógica de representação necessária para atender aos clientes do sistema. Ela
intercepta as solicitações, controla o acesso a serviços de negócios, constrói as
respostas e devolve aos clientes. As classes de fronteira, os Servlets e as JSPs, por
produzirem os elementos de interface, são encontradas aqui. Os padrões de projeto
utilizado aqui foram:
• Context Object: compartilha as informações do sistema de um modo
independente de camada, aprimorando a capacidade de reutilização e
manutenção da aplicação. É implementado através de uma classe POJO
que encapsula os dados do sistema e cujo estado é compartilhado por
toda a aplicação, possibilitando um melhor desacoplamento entre as
camadas.
• Front Controller: fornece um ponto de entrada centralizado para tratar as
104
solicitações de forma a separar os códigos de criação e de visualização,
visando reduzir ao máximo a existência de lógica de controle no código de
visualização e aumentando significativamente a reutilização do código. No
desenvolvimento deste trabalho, o este padrão foi implementado através
do uso do framework Struts2, já discutido anteriormente.
Já a camada de negócios, ou controle, fornece os serviços de negócios
necessários aos clientes das aplicações, ou seja, centraliza a lógica e o
processamento do negocio. Nesta camada foram utilizados, além do EJB, os
seguintes padrões:
• Business Object (BO): encapsula e gerencia os dados de negócio,
comportamento e persistência, ajudando a separar a lógica de
persistência da lógica de negocio. Permite que o armazenamento e
recuperação dos dados sejam delegados para outro objeto de
persistência, como um DAO, por exemplo.
Por fim, a camada de integração, ou modelo, é responsável pelo
acesso aos dados de negócios e recursos externos. O Data Access Object (DAO) foi
o padrão utilizado nessa camada.
• Data Access Object (DAO): implementa o mecanismo de acesso para
trabalhar com a fonte de dados da aplicação, ocultando os detalhes da
implementação de seus clientes. De acordo com Alur, Crupi e Malks
(2004), o DAO atua como um adaptador entre o componente e a fonte de
dados, fornecendo interfaces que permitem a alteração da implementação
do DAO ou mesmo da fonte de dados sem alterar a implementação do
cliente.
5.7 Enterprise Java Bean (EJB)
Neste trabalho foi utilizada o padrão JEE chamado de Enterprise Java
Beans, ou EJB, usado para definir os diversos componentes que comporão uma
aplicação JEE voltada para serviços. Esses componentes se localizarão em um
contêiner EJB e podem ser relacionados com acesso a dados, lógica, troca de
mensagens, acesso a banco ou gerenciamento de transações. Em suas versões
mais atuais o EJB também tem a capacidade de interagir com terminais Web
105
services. Todd & Szolkowski (2003), definem três funções para os EJBs:
• Beans de entidade – utilizados para acesso a dados e que permitem ao
contêiner acessar o banco de dados e gerenciar transações, tornando
este acesso transparente para o desenvolvedor.
• Beans de sessão – utilizados para controle da lógica do negócio. Estes
beans são controlados pelo contêiner e alocados de acordo com sessões
EJB, que podem ser mapeadas para clientes específicos ou através da
interação com Web Services. Esse controle torna o controle do ciclo de
vida desses componentes automático.
• Beans baseados em mensagens – utilizados para a troca de mensagens
assíncronas.
5.8 Conteiner Web e Aplicações Web
Todd & Szolkowski (2003), afirmam que o contêiner web é o ambiente
onde as aplicações Web baseadas na plataforma JEE são hospedadas, ou seja, ele
hospeda a lógica de controle e de apresentação dessas aplicações e fornece
interfaces para diversos serviços J2EE, por isso deve incluir as suas APIs, como por
exemplo, dos EJBs, Servlets e JSPs. Além disso, o contêiner pode trabalhar com
outros formatos de dados como HTML, imagens e dados XML para clientes. De
acordo com a definição da SUN MICROSYSTEMS, um web contêiner é
[...] um contêiner que implementa um contrato da arquitetura J2EE. Este
contrato especifica um ambiente de execução para componentes web que
inclui segurança, concorrência, gerência de ciclo de vida, transação,
deployment, e outros serviços[...]. (tradução nossa).
A Figura 36 mostra a estrutura básica de um contêiner web.
106
Figura 36 - O contêiner web (Adaptado de Todd e Szolkowski,2003, p.10)
Para o desenvolvimento deste trabalho foi utilizado como contêiner
Web o servidor de aplicações (ou servido web) de código aberto da Red Hat,
conhecido como JBoss. Ele é também um contêiner EJB, que é responsável pelo
gerenciamento e controle do ciclo de vida dos componentes Enterprise Java Bean.
Um servidor de aplicação permite o desenvolvimento de aplicações multicamadas
distribuídas. Ele age como a interface entre os clientes, as bases de dados e outros
sistemas externos à aplicação. A SUN MICROSYSTEMS define um servidor de
aplicações web como:
Software que provê serviços para acessar a Internet, uma intranet, ou uma
extranet. Um Web Server hospeda web sites, prove suporte para HTTP e
outros protocolos, e executa programas do lado do servidor (como scripts
CGI ou Servlets) que desenvolvem determinadas funções. Na arquitetura
J2EE, um web Server provê serviços para um web contêiner. [...] (tradução
nossa).
A Figura 37, apresenta uma estrutura de pastas predefinida para uma
aplicação WEB.
107
Figura 37 - A estrutura de uma aplicação Web. (Adaptado de Todd e Szolkowski, 2003, p.90)
A pasta raiz é o primeiro nível de uma aplicação web. A pasta WEB-
INF contém informações relativas à configuração, como o arquivo web.xml, o
diretório lib, que armazena as bibliotecas utilizadas pela aplicação e o diretório onde
ficam as classes da aplicação. A página index e as pastas de conteúdo (HTML, JSP,
etc.) podem ser distribuídas no mesmo nível da pasta WEB-INF.
5.9 Web Services
Web Service é uma solução utilizada na integração de sistemas e na
comunicação entre aplicações diferentes de forma normatizada, independentemente
da plataforma em que foram construídas, de forma a serem capazes de invocar
recursos umas das outras e delegar tarefas de diversos níveis de complexidade.
Segundo Todd & Szolkowski (2003) um web service é um componente
de software que pode ser invocado por meio de uma rede, não necessariamente
uma rede de HTTP, utilizando tecnologia XML de forma a garantir que a linguagem e
a plataforma de um componente sejam transparentes para o seu chamador.
5.10 Arquitetura e Projeto do SGA
Como comentado anteriormente, foram utilizados o padrão MVC e a
plataforma J2EE e alguns de padrões de projeto e tecnologias para o
108
desenvolvimento de arquitetura do sistema web proposto. A Figura 38 demonstra a
arquitetura do aplicativo SGA.
Figura 38 - Arquitetura do sistema SGA
As classes de fronteira que interagem com o usuário e recebem suas
solicitações são as páginas JSP, que tem seu layout determinado por arquivos CSS.
As solicitações encaminhadas por estas páginas chegam em formato de requisições
HTTP ao FilterDispacher, filtro central de requisições do Struts2, que decide para
qual classe denominada “action” a requisição deverá ser encaminhada, conforme o
mapeamento feito no arquivo struts.xml.
As classes action estendem a classe ActionSupport do framework
Struts e são responsáveis, individualmente, pelo controle de um caso de uso
especifico, e em conjunto, pelo controle de toda a aplicação. São elas que
instanciam um objeto BO responsável por fazer a interface como o EJB, que irá
executar a lógica do negócio e utilizar as classes de entidade para fazer o acesso ao
sistema de banco de dados.
As requisições ao EJB podem ser feitas também através de serviços
externos, utilizando Web Services, que realizam a comunicação através de arquivos
XML. Neste caso especifico, a apresentação fica a cargo de uma aplicação
construída em PHP, que extrai relatórios a partir das informações vindas do EJB.
Para as classes de entidade têm-se as classes DAO e POJO,
responsáveis pelo mapeamento objeto relacional e persistência dos dados. O
acesso aos dados foi implementado com a utilização do framework Hibernate3.
A reposta volta ao cliente por esses objetos e é exibida no navegador
de acordo com o mapeamento do struts.xml.
109
Todas essas classes estão hospedadas em um servidor de aplicações
web, o JBoss, que fornece uma ampla estrutura de apoio aos serviços EJB e Web
Services. O SGBD usado é o MySQL, funcionando em um ambiente externo ao
contêiner.
Os casos de uso que foram desenvolvidos no sistema possuem um
conjunto de classes necessárias para seu funcionamento, sendo no mínimo uma
página JSP, um POJO e uma classe action no servidor que faz o acesso remoto aos
EJBs, e no servidor que contem os serviços EJBs estão uma classe BO, uma classe
DAO, uma entidade e um POJO. Existe ainda, um controlador central que faz o
“roteamento” das requisições e respostas. A seguir serão apresentados alguns
diagramas, que apresentarão esta estrutura de forma mais detalhada.
5.10.1 Diagrama de pacotes
Para demonstrar a maneira que as classes do sistema foram
organizadas, será utilizado um diagrama de pacotes, um dos diagramas estruturais
contidos na UML. Através deste diagrama, é possível ter uma visão das partes que
compõem um sistema, tanto a organização dos arquivos dentro do mesmo sistema,
como os subsistemas.
Os pacotes são pastas, criados com o objeto de organizar os arquivos
do sistema. Para dividir o sistema, pode se utilizar diversas variáveis. Uma forma de
explorar melhor esta divisão é separando os arquivos de acordo com a finalidade de
cada um, no SGA os pacotes foram criados da seguinte maneira:
• Projeto que roda no servidor:
o br.SGA.interfaces: nele estão contidos os EJBs remotos. É
através deles que os outros sistemas conseguem utilizar os
serviços disponibilizados nas classes contidas no pacote de
negócios;
o br.SGA.negocio: as classes deste pacote são responsáveis
por implementar as lógicas de negócio;
o br.SGA.persistencia: este pacote contem as classes
responsáveis por efetuar as tarefas de persistência de dados,
110
com o auxilio das classes contidas no pacote
br.SGA.entidades;
o br.SGA.entidades: as classes deste pacote representam os
objetos que podem ser persistidos, nelas estão os
mapeamentos relacionados as tabelas do banco de dados,
através de anotação do framework Hibernate;
o br.SGA.util: os serviços que podem ser utilizados por vários
contextos diferentes são armazenados nas classes deste
pacote;
o br.SGA.exception: Armazena as exceções particulares do
sistema;
o br.SGA.model: Aqui são armazenadas as classes que são
utilizadas ao realizar interfaces com outros sistemas, estas
classes são classes POJO idênticas às entidades. Porém,
elas não possuem as anotações do framework Hibernate.
• Sistema que roda no servidor WEB:
o br.SGA.model: A mesma funcionalidade do pacote model do
servidor de aplicações.
o br.SGA.action: neste pacote estão as classes que estendem a
classe ActionSuppot, estas classes implementam as ações
chamadas pelo arquivo struts.xml, que foi mais detalhado a no
capitulo 4.
A Figura 39 mostra o diagrama de pacotes do sistema SGA, onde são
apresentados todos os pacotes divididos em dois contextos: uma aplicação WEB e
outra que disponibiliza serviços na forma de um EJB, bem como as dependências
que há entre eles.
111
Figura 39 - Diagrama de pacotes do software SGA
Para melhor entendimento da interação entre as classes, será
apresentado na Figura 40 o diagrama de classes do - Detalhe do caso de uso CSU -
01 Manutenção de Clientes, este é um diagrama de nível de projeto que mostra
quais classes foram implementadas para este caso de uso.
112
Figura 40 - Diagrama de classes de projeto do caso de uso Manutenção de Clientes
5.10.2 Diagrama de Distribuição
Para demonstrar como o sistema foi distribuído fisicamente, será
utilizado um diagrama de distribuição, ou deployment, conforme especificado na
113
UML. Através deste diagrama, é possível ter uma visão de alto nível da distribuição
dos componentes do sistema dentro do ambiente em que ele será executado.
A Figura 41 apresenta o diagrama de distribuição do sistema SGA,
onde é apresentada a distribuição física do sistema e seus componentes no
ambiente, bem como o fluxo de informação entre estes componentes, usuários e os
serviços dos quais eles fazem uso.
Figura 41 - Diagrama de distribuição do software SGA
O sistema foi distribuído em dois computadores separados, ligados por
uma rede local. No primeiro computador, foi instalado o servidor de aplicações, o
JBoss, que provê serviços necessários para o funcionamento do sistema e onde o
114
sistema é efetivamente executado. São eles, entre outros:
• Contêiner Web – necessário para a execução dos Servlets e tratamento
das paginas JSP.
• JDBC e JPA– serviços necessários para a comunicação com as bases de
dados e integração com o framework Hibernate 3.
• EJB 3 – serviço necessário para o controle, criação e tratamento dos
beans EJB.
Hospedados no JBoss encontram-se os dois pacotes que são os
componentes principais do sistema SGA, responsáveis por diferentes papéis
especificados no modelo MVC:
1 SGA, responsável pela apresentação e controle;
2 SGA EJB3, responsável pela lógica de negocio e persistência
dos dados.
As requisições podem chegar ao SGA através de uma intranet ou da
Internet, vindas de um web browser ou de uma aplicação cliente através de web
services. As requisições vindas de um browser são passadas para o pacote SGA,
que gerencia o fluxo e cria as páginas a serem exibidas. O JBoss gerencia a
comunicação deste pacote com o SGA EJB3 e a criação dos beans EJB,
responsáveis pela lógica de negócio e persistência de dados.
As requisições que chegam através de web services são tratadas
diretamente pelo pacote EJB3, que as processa e responde utilizando o mesmo
protocolo.
O pacote SGA EJB3 realiza a persistência e a consulta de dados
utilizando o framework Hibernate3 para se comunicar via rede com o servidor
MySQL, instalado no segundo computador. Devido à utilização de componentes, o
servidor de banco de dados pode ser alterado sem modificar a estrutura já utilizada,
bastando apenas alterar a configuração de IP e o componente chamado de
“conector”, utilizado para conectar com servidores específicos de banco. Esta
facilidade foi melhor apresentada no capítulo 3.
115
6 CONCLUSÕES
A partir do momento que nos propomos a suprir as dificuldades do
cliente desenvolvendo um sistema web para que o mesmo tenha uma gestão mais
especializada nas vendas de peças automotivas, nos empenhamos a aprender as
melhores práticas para a análise e desenvolvimento de um sistema que fizesse com
que a tomada de decisões fosse mais precisa e eficaz.
A partir das entrevistas com o cliente podemos verificar as suas reais
necessidades nos trouxe uma oportunidade de aprendizagem e conviver com o
mundo corporativo, nos tornado assim, melhores profissionais no que diz no trato
com o cliente.
As ferramentas UML vieram de encontro com nossos objetivos (que era
satisfazer as necessidades do cliente) fazendo com que o SGA fosse bem
diagramado de forma concisa e objetiva através de seus vários diagramas e análises
criteriosas.
Com a linguagem UML, o engenheiro representa os diferentes
aspectos de um sistema, sejam eles funcionais, informacionais ou comportamentais.
Além disso, a linguagem ainda auxilia na criação de diversos diagramas para
posterior análise. Com as ferramentas de criação dos documentos de análise,
tivemos um grande apoio na obtenção, gestão, modelagem e validação dos
requisitos do sistema. Com uma boa análise e com os atributos de uso do sistema
bem claros, a qualidade do produto final foi sempre aumentando, deixando o cliente
cada vez mais satisfeito com a nova ferramenta de tomadas de decisão.
A escolha de uma ferramenta de análise nos fez entender melhor o
funcionamento da empresa, e facilitou as apresentações do projeto para os
interessados no sistema. Para tal, escolhemos a ferramenta Enterprise Architect
para documentação, visualização e especificação das funcionalidades do sisitema.
O padrão arquitetural usado na engenharia deste software foi o modelo
MVC, este divide uma aplicação em três componentes: modelo, visão e controlador,
ou seja, cada camada tem uma função específica que separa a interface do usuário
dos dados do sistema e das regras de negócio. Esse modelo atualmente está sendo
usado em aplicações Web, ele propiciou agilidade no desenvolvimento e
116
manutenção do sistema, facilitando assim para os desenvolvedores e analistas.
Para a criação das aplicações Web foi usado o framework Struts2 que
é baseado nas tecnologias Servlets e JSP e garante com o padrão Front Controller o
gerenciamento das requisições em um único ponto. Com esse padrão as
solicitações feitas são encaminhadas e visualizadas de forma correta, facilitando o
desenvolvimento da aplicação multicamada, sem contar que permite a simplificação
do código. Além disso, também foi utilizado o padrão Business Object, responsável
pela camada de negócio ele separa a lógica de persistência da lógica de negócio, se
adequando assim as necessidades do sistema e dos desenvolvedores.
O padrão arquitetural usado na engenharia deste software foi o modelo
MVC, este divide uma aplicação em três componentes: modelo, visão e controlador,
ou seja, cada camada tem uma função específica que separa a interface do usuário
dos dados do sistema e das regras de negócio. Esse modelo atualmente está sendo
usado em aplicações Web, ele propiciou agilidade no desenvolvimento e
manutenção do sistema, facilitando assim para os desenvolvedores e analistas.
O padrão Data Access Object conjugado com o framework Hibernate
foi responsável pela manipulação dos dados, tornando transparente para os
desenvolvedores as operações junto ao banco de dados, o MySQL, que apresentou
boa performance.
Após o desenvolvimento deste projeto verificamos que uma
informatização pode ser considerada eficiente quando traz mais eficiência nos
processos da empresa, antes do uso de tais tecnologias. A eficiência fundamenta-se
em dados concisos assim gerando agilidade na inclusão e recuperação nas
informações diminuindo assim os custos da mesma.
O desenvolvimento desse projeto foi importante para compreendermos
o quanto cada assunto abordado no curso é necessário para o desenvolvimento de
um sistema. Os documentos foram válidos e devem ser preenchidos para auxiliar os
analistas e desenvolvedores. O sistema implementado também comprova que é
possível desenvolver um sistema web para uma autopeça seja ela de grande ou
pequeno porte. E não importa o tamanho do projeto, os requisitos devem ser
seguidos a risca com os preceitos na Engenharia de Software.
117
REFERÊNCIAS BIBLIOGRÁFICASREFERÊNCIAS BIBLIOGRÁFICASREFERÊNCIAS BIBLIOGRÁFICASREFERÊNCIAS BIBLIOGRÁFICAS
ALUR, D., CRUPI, J., & MALKS, D. (2004). Core J2EE Patterns. Rio de Janeiro.
BAUER, C., & KING, G. (2005). Hibernate em Ação. Rio de Janeiro: Ciência
Moderna.
BEZERRA, E. (2002). Princípio de Análise e Projeto de Sistemas com UML. Rio
de Janeiro: Elsevier.
BOOCH, G., RUMBAUGH, J., & JACOBSON, I. (2000). UML: Guia do Usuário. (F. F.
Silva, Trad.) Rio de Janeiro: Campus.
BUSSAB, W. O., & MORETTIN, P. A. (2004). Estatística Básica (5 ed.). São Paulo:
Saraiva.
BUTOW, E. (2007). User Interface Design for Mere Mortals. Boston: Pearson
Education.
CAMPOS, F. F., & SILVA, J. W. (2008). Interface Homem-Maquina: Melhores
Práticas de Usabilidade. São Bernardo do Campo: Faculdade de Tecnologia
Temomecânica.
CANGÜE, F. J., GODEFROID, L. B., & SILVA, E. (2004). Análise Atual do Setor
Automobilístico Nacional. Lavras, MG, Brasil.
DATE, C. J. (2004). Introdução a Sistemas de Banco de Dados. (D. Vieira, Trad.)
Rio de Janeiro: Campus.
ELMASRI, R., & NAVATHE, S. B. (2005). Sistemas de Banco de Dados (4 ed.). (M.
G. Pinheiro, C. C. Canhette, & G. C. Valim Melo, Trads.) São Paulo: Person Addison
Wesley.
FOWLER, M. (2003). Who Needs an Architect?: IEEE Software. Acesso em 01 de
dez de 2009, disponível em
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
HALL, M., & BROWN, L. (2005). Core Servlets e JavaServer Pages. (C. R. Pistilli,
Trad.) Rio de Janeiro: Ciência Moderna.
HUSTED, T., DUMOUSIN, C., FRANCIUSCUS, G., & WINTERFELDT, D. (2004).
Struts em Ação. Rio de Janeiro: Ciência Moderna.
118
KRASNER, G. E., & POPE, S. T. (1998). A cookbook for using the Model-View-
Controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented
Programming .
MELO, R. N; SILVA, S. D; TANAKA, A. K. Banco de dados em aplicações cliente-
servidor: distribuição de processamento, fundamento de banco de dados, banco de
dados distribuídos e banco de dados heterogêneos. Rio de Janeiro: Infobook, 1997.
MULLER, R. (2002). Projeto de Banco de Dados. São Paulo: Berkeley.
OLIVEIRA, W. J. (2000). Banco de Dados Interbase com Delphi. Florianópolis:
Visual Books.
PERA, M. (2009). Segunda Prorrogação da Redução do IPI Vige até Outubro.
Acesso em 03 de Mai de 2010, disponível em Auto Diario:
http://www.autodiario.com.br/conteudo/segunda-prorrogacao-da-reducao-do-ipi-vige-
ate-outubro
PONNIAH, Paulraj. Database Design and Development: An Essential Guide for IT
Professionals. 2003.
PRESSMAN, R. (2006). Engenharia de Software (6 ed.). (R. D. Penteado, Trad.)
São Paulo: McGraw-Hill.
ROUGHLEY, I. (2006). Starting Struts2. C4Media.
SARAIVA, J. (2007). TI permite diferencial à indústria de autopeças. Acesso em
01 de Mai de 2010, disponível em IT Web:
http://www.itweb.com.br/noticias/noticias_imprimir.asp?cod=42117
SILVA, S. M., BONIN, M. R., & PALUDO, M. A. (03 de mai de 2006). Levantamento
de Requisitos segundo Método Volere. 1 . Paraná, Santa Catarina, Brasil.
SILVA, P. C. B. Utilizando UML: Diagrama de Classes. SQL Magazine, Rio de
Janeiro, Ed. 63, ano 5, p. 10-17, 2007.
SOMMERVILLE, I. (2003). Engenharia de Software (6 ed.). (A. M. Ribeiro, Trad.)
São Paulo: Addison Wesley.
TODD, N., & SZOLKOWSKI, M. (2003). Java Server Pages: O Guia do
Desenvolvedor. (E. Furmankiewicz, Trad.) Rio de Janeiro: Elsevier.
ULLMAN, & WIDOW, J. (1994). "The TSIMMIS Project: Integration of
119
Heterogeneous Information Sources".
W3C. (2008). Acesso em 27 de Outubro de 2009, disponível em W3C:
http://www.w3c.br/sobre
W3C. (2004). Acesso em 02 de Julho de 2010, disponível em W3C:
http://www.w3.org/TR/ws-arch/#whatis
WAZLAWICK, R. S. (2004). Análise e Projeto de Sistemas de Informação
Orientado a Objetos. Rio de Janeiro: Campus.
ANEXO A – DADOS IMPORTANTES
// Código do arquivo struts.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
<package name="default" extends="struts-default">
<interceptor>
<interceptor name="login" class="br.SGA.action.LoginInterceptor" />
<interceptor-stack name="loginStack">
<interceptor-ref name="servlet-config" />
<interceptor-ref name="params" />
<interceptor-ref name="login" />
<interceptor-ref name="prepare" />
<interceptor-ref name="chain" />
<interceptor-ref name="model-driven" />
<interceptor-ref name="fileUpload" />
<interceptor-ref name="static-params" />
<interceptor-ref name="params" />
<interceptor-ref name="conversionError" />
<interceptor-ref name="validation" />
120
<interceptor-ref name="workflow" />
</interceptor-stack>
</interceptor>
<default-interceptor-ref name="loginStack" />
<global-results>
<result name="login">login.jsp</result>
</global-results>
<!-- Ações para efetuar Login -->
<action name="efetuar" method="efetuar" class="br.SGA.action.LoginAction">
<result name="ok" type="redirect-action">telaInicial</result>
<result name="erro">login.jsp</result>
</action>
<action name="logout" class="br.SGA.action.LoginAction" method="logout">
<result name="ok">login.jsp</result>
</action>
<action name="telaInicial" class="br.SGA.action.LoginAction" method="telaInicial">
<result name="input">telaInicial.jsp</result>
</action>
<!-- Fim das ações para efetuar login -->
<!--Ações para manutenção de Usuario -->
<action name="setUpForInsertOrUpdateUsuario" method="setUpForInsertOrUpdateUsuario"
class="br.SGA.action.UsuarioAction">
<result name="success">CadastrarUsuario.jsp</result>
</action>
<action name="setUpForInsertOrUpdateUsuarioMessage"
method="setUpForInsertOrUpdateUsuarioMessage" class="br.SGA.action.UsuarioAction">
<result name="success">CadastrarUsuario.jsp</result>
</action>
<action name="insereAtualizaUsuario" method="insereAtualizaUsuario"
class="br.SGA.action.UsuarioAction">
<result name="input">CadastrarUsuario.jsp</result>
121
<result name="sccessMessage" type="redirect-
action">setUpForInsertOrUpdateUsuarioMessage</result>
</action>
<!--Fim das ações para manutenção de Usuario-->
<!--Ações para manutenção de Produto-->
<action name="insereAtualizaProduto" method="insereAtualizaProduto"
class="br.SGA.action.ProdutoAction">
<result name="input">CadastrarProduto.jsp</result>
<result name="successMessage" type="redirect-
action">setUpForInsertOrUpdateProdutoMessage</result>
</action>
<action name="deleteProduto" method="deleteProduto" class="br.SGA.action.ProdutoAction">
<result name="success" type="redirect-action">irParaPesquisaProdutos</result>
</action>
<action name="setUpForInsertOrUpdateProduto" method="setUpForInsertOrUpdateProduto"
class="br.SGA.action.ProdutoAction">
<result name="success">CadastrarProduto.jsp</result>
</action>
<action name="setUpForInsertOrUpdateProdutoMessage"
method="setUpForInsertOrUpdateProdutoMessage" class="br.SGA.action.ProdutoAction">
<result name="success">CadastrarProduto.jsp</result>
</action>
<action name="pesquisarProdutos" method="pesquisarProdutos"
class="br.SGA.action.ProdutoAction">
<result name="success">ResultsProduto.jsp</result>
</action>
<action name="irParaPesquisaProdutos" method="irParaPesquisaProdutos"
class="br.SGA.action.ProdutoAction">
<result name="success">ResultsProduto.jsp</result>
</action>
<!--Fim das ações para manutenção de Produto-->
<!--Ações para manutenção de Cliente-->
122
<action name="insereAtualizaCliente" method="insereAtualizaCliente"
class="br.SGA.action.ClienteAction">
<result name="input">CadastrarCliente.jsp</result>
<result name="successMessage" type="redirect-
action">setUpForInsertOrUpdateClienteMessage</result>
</action>
<action name="deleteCliente" method="deleteCliente" class="br.SGA.action.ClienteAction">
<result name="success" type="redirect-action">irParaPesquisaClientes</result>
</action>
<action name="setUpForInsertOrUpdateCliente" method="setUpForInsertOrUpdateCliente"
class="br.SGA.action.ClienteAction">
<result name="success">CadastrarCliente.jsp</result>
</action>
<action name="setUpForInsertOrUpdateClienteMessage"
method="setUpForInsertOrUpdateClienteMessage" class="br.SGA.action.ClienteAction">
<result name="success">CadastrarCliente.jsp</result>
</action>
<action name="pesquisarClientes" method="pesquisarClientes" class="br.SGA.action.ClienteAction">
<result name="success">ResultsCliente.jsp</result>
</action>
<action name="irParaPesquisaClientes" method="irParaPesquisaClientes"
class="br.SGA.action.ClienteAction">
<result name="success">ResultsCliente.jsp</result>
</action>
<!--Fim das ações para manutenção de Cliente-->
<!--Ações para manutenção de Fornecedor-->
<action name="irParaPesquisaFornecedores" method="irParaPesquisaFornecedores"
class="br.SGA.action.FornecedorAction">
<result name="success">ResultsFornecedor.jsp</result>
</action>
<action name="pesquisarFornecedores" method="pesquisarFornecedores"
class="br.SGA.action.FornecedorAction">
123
<result name="success">ResultsFornecedor.jsp</result>
</action>
<action name="setUpForInsertOrUpdateFornecedor" method="setUpForInsertOrUpdateFornecedor"
class="br.SGA.action.FornecedorAction">
<result name="success">CadastrarFornecedor.jsp</result>
</action>
<action name="setUpForInsertOrUpdateFornecedorMessage"
method="setUpForInsertOrUpdateFornecedorMessage" class="br.SGA.action.FornecedorAction">
<result name="success">CadastrarFornecedor.jsp</result>
</action>
<action name="insereAtualizaFornecedor" method="insereAtualizaFornecedor"
class="br.SGA.action.FornecedorAction">
<result name="input">CadastrarFornecedor.jsp</result>
<result name="successMessage" type="redirect-
action">setUpForInsertOrUpdateFornecedorMessage</result>
</action>
<action name="deleteFornecedor" method="deleteFornecedor"
class="br.SGA.action.FornecedorAction">
<result name="success" type="redirect-action">irParaPesquisaFornecedores</result>
</action>
<!--Fim das ações para manutenção de Fornecedor-->
<!--Ações para manutenção de Funcionario -->
<action name="insereAtualizaFuncionario" method="insereAtualizaFuncionario"
class="br.SGA.action.FuncionarioAction">
<result name="input">CadastrarFuncionario.jsp</result>
<result name="successMessage" type="redirect-
action">setUpForInsertOrUpdateFuncionarioMessage</result>
</action>
<action name="deleteFuncionario" method="deleteFuncionario"
class="br.SGA.action.FuncionarioAction">
<result name="success" type="redirect-action">irParaPesquisaFuncionario</result>
</action>
124
<action name="setUpForInsertOrUpdateFuncionario" method="setUpForInsertOrUpdateFuncionario"
class="br.SGA.action.FuncionarioAction">
<result name="success">CadastrarFuncionario.jsp</result>
</action>
<action name="setUpForInsertOrUpdateFuncionarioMessage"
method="setUpForInsertOrUpdateFuncionarioMessage" class="br.SGA.action.FuncionarioAction">
<result name="success">CadastrarFuncionario.jsp</result>
</action>
<action name="pesquisarFuncionario" method="pesquisarFuncionarios"
class="br.SGA.action.FuncionarioAction">
<result name="success">ResultsFuncionario.jsp</result>
</action>
<action name="irParaPesquisaFuncionario" method="irParaPesquisaFuncionarios"
class="br.SGA.action.FuncionarioAction">
<result name="success">ResultsFuncionario.jsp</result>
</action>
<!--Fim das ações para manutenção de Funcionarios -->
</package>
</struts>