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


EVERTON ALVES CUNHA


LEONARDO CESAR BRITO


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


DAIANE LOPES SILVA


EVERTON ALVES CUNHA




MARIO LUCIO DE ARAUJO BRUM



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


EVERTON ALVES CUNHA




MARIO LUCIO DE ARAUJO BRUM



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 10 - Detalhe do caso de uso CSU - 05 _____________________________________________________ 38



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


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.1. O sistema emite uma mensagem informando que o CPF do funcionário é inválido;



RN - 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.




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.1. O sistema emite uma mensagem informando que o CPF/CNPJ do fornecedor é inválido;



RN - 02


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.




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;




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.



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


Regras de Negócio Associadas

--


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.



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.


RN – 03


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.



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.


--


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”



razoável. O que é banco de dados? O que são dados? É um software? É




Não só o departamento de Tecnologia de uma empresa que utiliza os


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



estendida também aos profissionais a;em dos Administradores de banco de



60

utiliza o termo “banco de dados”



razoável. O que é banco de dados? O que são dados? É um software? É um lugar




o de Tecnologia de uma empresa que utiliza os


obter informações cruciais de seu negócio, principalmente para poder aproveitá-la da

TI tem a responsabilidade



estendida também aos profissionais a;em dos Administradores de 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



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



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:



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



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


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


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




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




, 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


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


. 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


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


o comportamento da interface,

HTML, JavaScript, e

onde são inseridos e apresentados os dados e

, e por fim o Struts2, onde são


. 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


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



deixam o recebimento dos dados como um exercício para o desenvolvedor


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


85

usted, Dumousin, Franciscus, & Winterfeldt (2004),

(HTTP) para mover os dados entre



deixam o recebimento dos dados como um exercício para o desenvolvedor.


as informações

a interface com o


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


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


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>



<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>





<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>





<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"


<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"


<result name="success">ResultsProduto.jsp</result>

</action>

<action name="irParaPesquisaProdutos" method="irParaPesquisaProdutos"


<result name="success">ResultsProduto.jsp</result>

</action>

122

<action name="insereAtualizaCliente" method="insereAtualizaCliente"

class="br.SGA.action.ClienteAction">

<result name="input">CadastrarCliente.jsp</result>


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"


<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"


<result name="success">ResultsCliente.jsp</result>

</action>





<action name="irParaPesquisaFornecedores" method="irParaPesquisaFornecedores"

class="br.SGA.action.FornecedorAction">

<result name="success">ResultsFornecedor.jsp</result>

</action>

<action name="pesquisarFornecedores" method="pesquisarFornecedores"

123

<result name="success">ResultsFornecedor.jsp</result>

</action>

<action name="setUpForInsertOrUpdateFornecedor" method="setUpForInsertOrUpdateFornecedor"


<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"


<result name="input">CadastrarFornecedor.jsp</result>


action">setUpForInsertOrUpdateFornecedorMessage</result>

</action>

<action name="deleteFornecedor" method="deleteFornecedor"


<result name="success" type="redirect-action">irParaPesquisaFornecedores</result>

</action>





<action name="insereAtualizaFuncionario" method="insereAtualizaFuncionario"

class="br.SGA.action.FuncionarioAction">

<result name="input">CadastrarFuncionario.jsp</result>


action">setUpForInsertOrUpdateFuncionarioMessage</result>

</action>

<action name="deleteFuncionario" method="deleteFuncionario"


<result name="success" type="redirect-action">irParaPesquisaFuncionario</result>

</action>

124

<action name="setUpForInsertOrUpdateFuncionario" method="setUpForInsertOrUpdateFuncionario"


<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"


<result name="success">ResultsFuncionario.jsp</result>

</action>

<action name="irParaPesquisaFuncionario" method="irParaPesquisaFuncionarios"


<result name="success">ResultsFuncionario.jsp</result>

</action>



</package>

</struts>

SOFTWARE DE GERENCIA MENTO DE AUTOPEÇAS · Gerenciamento de Autopeças (SGA) was partly developed....

Documents

Transcript of SOFTWARE DE GERENCIA MENTO DE AUTOPEÇAS · Gerenciamento de Autopeças (SGA) was partly developed....