SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS

Tamanho: px
Começar a partir da página:

Download "SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS"

Transcrição

1 FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS DAIANE LOPES SILVA EDUARDO STUART RODRIGUES DE VASCONCELOS EVERTON ALVES CUNHA LEONARDO LUCIO CARVALHO OLIVEIRA LEONARDO CESAR BRITO JHARBAS ARAUJO RODRIGUES MÁRIO LÚCIO DE ARAÚJO BRUM SALGER LUIS DE OLIVEIRA Uberlândia 2010/1

2 DAIANE LOPES SILVA EDUARDO STUART RODRIGUES DE VASCONCELOS EVERTON ALVES CUNHA LEONARDO LUCIO CARVALHO OLIVEIRA LEONARDO CESAR BRITO JHARBAS ARAUJO RODRIGUES MARIO LUCIO DE ARAUJO BRUM SALGER LUIS DE OLIVEIRA SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS Trabalho de Final de curso submetido à UNIMINAS como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp. Márcio Aurélio Ribeiro Moreira Uberlândia 2010/1

3 DAIANE LOPES SILVA EDUARDO STUART RODRIGUES DE VASCONCELOS EVERTON ALVES CUNHA LEONARDO LUCIO CARVALHO OLIVEIRA LEONARDO CESAR BRITO JHARBAS ARAUJO RODRIGUES MARIO LUCIO DE ARAUJO BRUM SALGER LUIS DE OLIVEIRA SOFTWARE DE GERENCIAMENTO DE AUTOPEÇAS Trabalho de Final de curso submetido à UNIMINAS como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp. Márcio Aurélio R. Moreira Uberlândia, 06 de Junho de 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

4 A nossa família pela força e costumeira atenção.

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

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

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

8 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

9 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

10 LISTA DE QUADROS Quadro 1 - Requisitos do sistema 27 Quadro 2 - Regra de negócio RN Quadro 4 Regra de negócio RN Quadro 5 - Regra de negócio RN Quadro 6 - Detalhe do caso de uso CSU Quadro 7 - Detalhe do caso de uso CSU Quadro 8 - Detalhe do caso de uso CSU Quadro 9 - Detalhe do caso de uso CSU Quadro 10 - Detalhe do caso de uso CSU Quadro 11 - Detalhe do caso de uso CSU Quadro 12 - Detalhe do caso de uso CSU Quadro 13 - Listagem de ferramentas de ORM 74 Quadro 14 - Lista de pacotes Hibernate. Fonte Java Magazine Edição 73 p. 4 78

11 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

12 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

13 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

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

15 SUMÁRIO 1 INTRODUÇÃO Breve Histórico Cenário atual A tecnologia nas empresas de autopeça Identificação do problema Objetivos do trabalho Objetivos Gerais Objetivos Específicos Justificativa para a pesquisa Organização do Trabalho Especificação do Problema ANÁLISE DE PROJETO DE SISTEMAS Introdução Ferramenta de modelagem Requisitos Regras de negócio Descrição dos atores Casos de uso Documentação dos casos de uso Manutenção de Cliente Manutenção de Funcionário Manutenção de Fornecedor Manutenção de Produtos Login de Usuário Registrar Compra Registrar Venda... 40

16 2.8 Classes de análise Diagrama de classes de análise Diagramas de Seqüência PERSISTÊNCIA DE DADOS Conceitos de banco de dados Sistema gerenciador de banco de dados SGBD Arquitetura do banco de dados A evolução dos sistemas de dados Tipos de Banco de Dados Modelagem de banco de dados Mapeamento Objeto Relacional Conceito Motivação do uso de ORM Ferramentas de mapeamento objeto/relacional Mapeamento objeto/relacional Framework Hibernate Introdução Historia Arquitetura PROJETO DE INTERFACE Introdução Interface Usabilidade Padrões utilizados Arquitetura da interface Estudo de Caso... Erro! Indicador não definido. 5 ARQUITETURA E CÓDIGO O enfoque de camadas...95

17 5.2 O padrão MVC Servlets e Java Server Pages O Framework Struts Java Enterprise Edition (JEE) Padrões de projeto Enterprise Java Bean (EJB) Conteiner Web e Aplicações Web Web Services Arquitetura e Projeto do SGA Diagrama de pacotes Diagrama de Distribuição CONCLUSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A DADOS IMPORTANTES

18 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

19 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é cm³ de 7% para 0% e dos carros entre cm³ e 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

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

21 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

22 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

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

24 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

25 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

26 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

27 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

28 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

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

30 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

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

32 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

33 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. de uso. Ator(es) secundário(s): nome dos demais atores participantes do caso 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

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

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

36 Manutenção de Funcionário A documentação do caso de uso Manutenção de funcionário, conforme o Quadro 6, descreve o fluxo para o cadastro de funcionários no sistema e identifica se os mesmos já está cadastrado ou não. Nome Manutenção de Funcionário CSU-02 Sumário Caso de Uso que descreve os passos para o cadastro de funcionário. Ator primário: Gerente Ator(es) secundário(s): - Pré-condição: O gerente deve estar logado no sistema. Pós-condição: O funcionário é cadastrado. Fluxo Principal 1. O gerente solicita ao sistema o cadastro do funcionário; 2. O sistema solicita como campos (CPF, nome do funcionário, telefone, sexo, endereço, número do endereço, complemento, bairro, CEP, estado e cidade do funcionário); 3. O gerente informa os dados e confirma o cadastro do funcionário; 4. O sistema valida o CPF e retorna uma mensagem informando que o funcionário foi cadastrado com sucesso e encerra o caso de uso. Fluxo Alternativo[1]: Busca de funcionário 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 O sistema emite uma mensagem informando que o funcionário já está cadastrado; 4.2. O sistema retorna ao passo 2. Fluxo de Exceção [4]: Violação da Regra de Negócio RN O sistema emite uma mensagem informando que o CPF do funcionário é inválido; 4.2. O sistema retorna ao passo 2. Regras de Negócios associadas RN - 02 Quadro 6 - Detalhe do caso de uso CSU - 02

37 Manutenção de Fornecedor A documentação do caso de uso Manutenção de fornecedor, conforme o Quadro 7, descreve o fluxo para o cadastro de fornecedores no sistema e identifica se já está cadastrado ou não. Nome Manutenção de Fornecedor CSU-03 Sumário Caso de Uso que descreve os passos para o cadastro de fornecedor. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: O funcionário deve estar logado no sistema. Pós-condição: O fornecedor é cadastrado. Fluxo Principal 1. O funcionário solicita ao sistema o cadastro do fornecedor; 2. O sistema solicita como campos (CPF/CNPJ), nome do fornecedor, telefone, sexo, endereço, número do endereço, complemento, bairro, CEP, estado e cidade do fornecedor); 3. O funcionário informa os dados e confirma o cadastro do fornecedor; 4. O sistema valida o CPF/CNPJ e retorna uma mensagem informando que o fornecedor foi cadastrado com sucesso e encerra o caso de uso. Fluxo Alternativo [1]: Busca de fornecedor 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 O sistema emite uma mensagem informando que o fornecedor já está cadastrado; 4.2. O sistema retorna ao passo 2. Fluxo de Exceção [4]: Violação da Regra de Negócio RN O sistema emite uma mensagem informando que o CPF/CNPJ do fornecedor é inválido; 4.2. O sistema retorna ao passo 2. Regras de Negócios associadas RN - 02 Quadro 7 - Detalhe do caso de uso CSU Manutenção de Produtos A documentação do caso de uso Manutenção de produtos, conforme

38 37 o Quadro 8, descreve o fluxo para o cadastro de produtos no sistema e identifica os produtos cadastrados. Nome Manutenção de Produto CSU-04 Sumário Caso de Uso que descreve os passos para o cadastro de produto. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: O funcionário deve estar logado no sistema. Pós-condição: O produto é cadastrado. Fluxo Principal 1. O funcionário solicita ao sistema o cadastro do produto; 2. O sistema solicita como campos (código, nome do produto, grupo de produto, preço de custo, preço de venda e utilização da peça); 3. O funcionário informa os dados e confirma o cadastro do produto; 4. O sistema retorna uma mensagem informando que o produto foi cadastrado com sucesso e encerra o caso de uso. Fluxo Alternativo [1]: Busca de Produto 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 O sistema emite uma mensagem informando que o produto já está cadastrado; 4.2. O sistema retorna ao passo 2. Regras de Negócios associadas Quadro 8 - Detalhe do caso de uso CSU - 04

39 Login de Usuário A documentação do caso de uso Login de Usuário, conforme o Quadro 9, descreve o fluxo de funções que o ator deve aplicar para efetuar login no sistema. O caso de uso verifica se o usuário e senha estão corretos, se a senha estiver errada volta para a tela de login. Nome Login de usuário CSU-05 Sumário Caso de Uso que descreve os passos para o usuário do sistema efetuar login. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: - Pós-condição: O funcionário é logado. Fluxo Principal 1. O funcionário inicia o sistema; 2. O sistema solicita como campos (nome do usuário, e senha); 3. O funcionário informa os dados e efetua o login; 4. O sistema verifica se o nome do usuário e a senha estão corretos e o sistema é logado. Fluxo de Exceção[4]: Usuário ou senha inválidos O sistema emite uma mensagem informando que o usuário ou senha estão inválidos 4.2. O sistema retorna ao passo 2. Regras de Negócio Associadas -- Quadro 9 - Detalhe do caso de uso CSU - 05

40 Registrar Compra No Quadro 10 estão descritas as funções para o ator Registrar Compra. Nesse caso de uso, o funcionário informa os dados necessários para o registro, o sistema adiciona os dados e atualiza o estoque da peça comprada. Nome Registrar compra CSU-06 Sumário Caso de Uso que descreve os passos para o funcionário registrar uma compra feita. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: O funcionário tem que estar logado no sistema. Pós-condição: O funcionário registra a compra. Fluxo Principal 1. O funcionário seleciona a opção desejada; 2. O sistema solicita como campos (código do produto, quantidade, preço de compra, preço de venda, data da compra; 3. O funcionário informa os dados e registra a compra. 4. O sistema adiciona os dados no banco e atualiza o estoque da peça comprada. Fluxo de Exceção [2]: Violação da Regra de Negócio RN O sistema emite uma mensagem informando que o preço de venda está menor que o preço de compra O sistema retorna ao passo 2, solicitando os campos novamente. Regras de Negócio Associadas RN 03 Quadro 10 - Detalhe do caso de uso CSU - 06

41 Registrar Venda No Quadro 11 estão descritas as funções para o ator Registrar Venda. Nesse caso de uso, o funcionário informa os dados necessários para o registro, o sistema adiciona os dados e atualiza o estoque da peça vendida. Nome Registrar venda CSU-07 Sumário Caso de Uso que descreve os passos para o funcionário registrar uma venda. Ator primário: Funcionário Ator(es) secundário(s): - Pré-condição: O funcionário tem que estar logado no sistema. Pós-condição: O funcionário registra a venda. Fluxo Principal 1. O funcionário seleciona a opção desejada; 2. O sistema solicita como campos (nome do cliente, nome ou código da peça e a quantidade); 3. O funcionário informa os dados e registra a venda. 4. O sistema registra a venda e encerra o caso de uso. Fluxo de Exceção[2]: Nome do cliente inválido 2.1. O sistema emite uma mensagem informando que o nome do cliente é inválido O sistema retorna ao passo 2. Regras de Negócio Associadas -- Quadro 11 - Detalhe do caso de uso CSU 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.

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

43 Figura 2 - Diagrama de classes 42

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

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

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

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

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

49 Figura 7 - Diagrama de Seqüência do Caso de Uso Efetuar Login 48

50 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

51 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

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

53 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

54 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

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

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

57 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

58 57 com "( ) " 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.

59 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). três níveis: Esta arquitetura possui três esquemas que podem ser definidos por 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

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

61 60 Figura 9 - Esquema de níveis 3.4 A evolução dos sistemas de dados Atualmente, a maioria das pessoas utiliza o termo banco de dados sem conhecer seu real significado. Até mesmo entre os profissionais de Tecnologia da Informação o conhecimento desta expressão não está em nível de detalhe razoável. O que é banco de dados? O que são dados? É um software? É um lugar onde se armazenam dados? Tem algo de especial na maneira de se armazenar os dados? Como podemos recuperar estes dados armazenados? Quais são suas funcionalidades e aplicações? Existem várias questões sobre este tema complexo. Não só o departamento de Tecnologia de uma empresa que utiliza os sistemas de banco de dados. As organizações dependem destes sistemas para obter informações cruciais de seu negócio, principalmente para poder aproveitá-la da forma mais eficiente e oportuna possível. A área de TI tem a responsabilidade primária de suportar e manter os sistemas de banco de dados em funcionamento, e devido a importância da base de dados para a empresa, esta responsabilidade é estendida também aos profissionais a;em dos Administradores de banco de dados, os líderes de projeto, programadores, analistas de sistemas e de redes também devem conhecer a importância da abordagem de um banco de dados.

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

63 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 computadores em todo o mundo, agora mais de 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 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.

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

65 64 Figura 11 - Abordagem centralizada. (Fonte: 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: distribuídas remotamente: A Figura 12 mostra como os fragmentos da base de dados estão

66 65 Figura 12 - Abordagem distribuída. (Fonte: 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

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

68 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

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

70 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).

71 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).

72 Mapeamento Objeto Relacional 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:

73 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 Motivação do uso de ORM Claro que existem muitas maneiras de se fazer persistência, mas, o

74 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

75 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 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 Mapeamento objeto/relacional No código a seguir pode-se ver como foi feito o mapeamento no objetorelacional no projeto SGA através de annotations do framework Hibernate: A Figura 14 representa as anotações de atributos: na Para o identificador do objeto, que representa a chave primária

76 75 Define qual será a estratégia para gerar a É opcional esta anotação para definir os nomes das colunas desde que os nomes dos atributos nas tabelas do banco correspondam aos nomes de atributos nas classes entidades. Dentro desta anotação pode-se definir: comprimento se é de preenchimento obrigatório rio e se é do tipo de registro único. Figura 14 - Anotações dos atributos Na Figura 15 pode-se ver as anotações referente a chave estrangeira.

77 76 Figura 15 - Anotação chave estrangeira Na Figura 16 têm-se as anotações dos relacionamentos, que são Um para Um para Muitos para Muitos para muitos Figura 16 - Anotação relacionamento 3.8 Framework Hibernate Introdução Em muitos anos de tecnologias, era discutido em muitos casos sobre a persistência dos dados, ou seja, em várias oportunidades o assunto era como armazenar os dados dos aplicativos, uma vez que existiam muitas formas diferentes e discrepantes de fazê-la, 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 framework 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 para aplicações.net o NHibernate.. A proposta do Hibernate era promissora, pois muitas rotinas que eram

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

79 78 Pacote Hibernate Core Descrição Hibernate para Java, API s nativas e metadados XML Hibernate Mapeia as classes com anotações do JDK 1.5 Hibernate API de persistência Java padrão para Java SE e Java EE. Hibernate Shards Framework para particionamento horizontal dos dados Hibernate Tools Ferramentas de desenvolvimento para Eclipse e Ant Hibernate Seam Framework para aplicações JSF, Ajax, EJB 3.0 / Java EE Quadro 13 - Lista de pacotes Hibernate. Fonte Java Magazine Edição 73 p. 4 Hibernate Core O 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 como ferramenta para o mapeamento objeto/relacional. Este pacote proporciona uma persistência transparente, exige apenas que para uma classe ser persistente, a mesma possua um construtor default, ou seja, um construtor sem parâmetros. Neste pacote pode-se utilizar para consultas o próprio SQL diretamente, uma linguagem própria do framework que é o HQL Hibernate Query Language,, o qual provê consultas dinâmicas e orientadas a objetos ou ainda utilizar uma API de queries Criteria,, neste projeto foi utilizada a esta API. Figura 17 - Construtor Entidade

80 79 Figura 18 - Consulta utilizando API Criteria Hibernate 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. 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 Hibernate EntityManager A API EntityManager tem por objetivo gerenciar unidades de

81 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 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 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é @Max, etc. Mas, também pode-se implementar regras novas. Exemplo de validação: public class Address private String line1; private String line2; private String zip; private String = private String = -2, max = 50, message = "Floor out of range") public int floor;... }

82 81 Hibernate 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 Tools Hibernate Tools é um conjunto de ferramentas que auxiliam no processo de desenvolvimento com o Hibernate. Editor de 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. Console 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 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. Assistentes 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.

83 82 Tarefa 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.

84 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

85 84 de apresentação e aplicação. A primeira representa os objetos gráficos de interface e cujas responsabilidades se resumem a receber dados e comandos do usuário e apresenta os resultados a ele. E o segundo controla o comportamento da interface, abrindo e fechando janelas, habilitando e desabilitando botões, etc. Estas camadas foram divididas em páginas JSP, HTML, JavaScript, e CSS (Cascading Style Sheets), onde são inseridos e apresentados os dados e executado tarefas dos usuários (apresentação), e por fim o Struts2, onde são tratados os dados inseridos e enviados ao tratamento correto de suas execuções (aplicaçã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 obrigatório em branco, e se o campo CPF ou CNPJ são válidos. Se estiver tudo certo, o Struts2 encaminha os dados a parte de código que trata os dados e salva as informações inseridas. As figuras Figura 20, Figura 21 e Figura 22 ilustram este exemplo. Figura 20 - Tela de cadastro de clientes

86 85 Figura 21 - Erro tratamento CPF Figura 22 - Mensagem de cliente cadastrado Segundo Husted, Dumousin, Franciscus, & Winterfeldt (2004), aplicações Web usam Hipertext Transfer Protocol (HTTP) para mover os dados entre o navegador executado em seu computador e a aplicação executada no servidor. Este protocolo fornece um mecanismo para enviar dados de um formulário, mas deixam o recebimento dos dados como um exercício para o desenvolvedor. O sistema web além de apresentar funcionalidade, deve ter boa aparência e navegabilidade, facilitando ao público alvo acessar as informações contidas nele, atendendo também às expectativas do negócio. De acordo com Sommerville (2003), a consistência da interface com o usuário significa que os comandos e os menus do sistema devem ter o mesmo

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

88 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

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

90 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

91 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 maquinamaquina 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.

92 91 Figura 26 - Tela inicial do WebService Figura 27 - Relatório de clientes cadastrados 4.6 Resultados No estudo de caso iremos apresentar as tecnologias já demonstradas nos tópicos anteriores e que foram aplicadas no SGA. Iremos focar na página cadastrarcliente.jsp para exemplificarmos nosso estudo. Quando o usuário logar no sistema é criado uma sessão para assegurar que o usuário pode acessar estas áreas de trabalho. O Interceptor que é 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.

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

94 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

95 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

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

97 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 clientegordo. 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, podese 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á

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

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

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

101 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

102 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 respostas, com o auxilio das tags do Struts2. destinadas às respectivas 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

103 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

104 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

105 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

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

107 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). aplicação WEB. A Figura 37, apresenta uma estrutura de pastas predefinida para uma

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

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

110 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 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 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; 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,

111 110 com o auxilio das classes contidas no pacote br.sga.entidades; o o o 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; br.sga.util: os serviços que podem ser utilizados por vários contextos diferentes são armazenados nas classes deste pacote; br.sga.exception: Armazena as exceções particulares do sistema; 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 o br.sga.model: A mesma funcionalidade do pacote model do servidor de aplicações. 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.

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

113 112 Figura 40 - Diagrama de classes de projeto do caso de uso Manutenção de Clientes 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

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64

Geração e execução de scripts de teste em aplicações web a partir de casos de uso direcionados por comportamento 64 direcionados por comportamento 64 5 Estudo de caso Neste capítulo serão apresentadas as aplicações web utilizadas na aplicação da abordagem proposta, bem como a tecnologia em que foram desenvolvidas, o

Leia mais

Modelos de Sistemas Casos de Uso

Modelos de Sistemas Casos de Uso Modelos de Sistemas Casos de Uso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2000 Slide 1 Casos de Uso Objetivos Principais dos Casos de Uso: Delimitação do contexto de

Leia mais

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011

CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 CURSO DESENVOLVEDOR JAVA WEB E FLEX Setembro de 2010 à Janeiro de 2011 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma

Leia mais

Unioeste Universidade Estadual do Oeste do Paraná

Unioeste Universidade Estadual do Oeste do Paraná Unioeste Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Especificação de Requisitos e Modelagem Orientada

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2009

CURSO DESENVOLVEDOR JAVA Edição 2009 CURSO DESENVOLVEDOR JAVA Edição 2009 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério.

Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério. EDSON GONÇALVES Este livro é dedicado a minha esposa Edna e a todos os desenvolvedores que fizeram do software livre um meio profissional levado a sério. AGRADECIMENTOS Primeiramente gostaria de agradecer

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

Leia mais

Modelos de Sistemas Casos de Uso

Modelos de Sistemas Casos de Uso Modelos de Sistemas Casos de Uso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2000 Slide 1 Modelagem de Sistema UML Unified Modeling Language (Linguagem de Modelagem Unificada)

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

UNIMINAS SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA

UNIMINAS SOFTWARE PARA GESTÃO COMERCIAL DE PAPELARIA ALBERTO DUMONT ALVES OLIVEIRA MARCOS ARAÚJO DA CUNHA UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO SOFTWARE PARA GESTÃO COMERCIAL

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Desenvolvimento WEB II. Professora: Kelly de Paula Cunha

Desenvolvimento WEB II. Professora: Kelly de Paula Cunha Desenvolvimento WEB II Professora: Kelly de Paula Cunha O Java EE (Java Enterprise Edition): série de especificações detalhadas, dando uma receita de como deve ser implementado um software que utiliza

Leia mais

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

Leia mais

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES Hugo Henrique Rodrigues Correa¹, Jaime Willian Dias 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil hugohrcorrea@gmail.com, jaime@unipar.br Resumo.

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos

Ricardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos Históricos e Modelagem Orientada a Objetos Histórico Diversas metodologias e métodos surgiram para apoiar OO. Evolução a partir de linguagens C++ e SmallTalk. Anos 80 Anos 80-90: diversidade de autores.

Leia mais

Prova Específica Cargo Desenvolvimento

Prova Específica Cargo Desenvolvimento UNIVERSIDADE FEDERAL DO PIAUÍ Centro de Educação Aberta e a Distância CEAD/UFPI Rua Olavo Bilac 1148 - Centro CEP 64.280-001 Teresina PI Brasil Fones (86) 3215-4101/ 3221-6227 ; Internet: www.uapi.edu.br

Leia mais

UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE ESTOQUE

UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE ESTOQUE UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE ESTOQUE ÉDER ALUÍSIO SIMÕES Discente da AEMS Faculdades Integradas de Três Lagoas HEITOR DE OLIVEIRA SARAIVA Discente da AEMS Faculdades Integradas

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto

Leia mais

FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ. Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8

FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ. Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8 FACULDADE DE CIÊNCIAS SOCIAIS E APLICADAS DO PARANÁ Sistema de Gestão Escolar PROJETO FINAL Schola Ratio Versão 8 CURITIBA Nov 2012 DJULLES IKEDA OSNIR FERREIRA DA CUNHA Sistema de Gestão Escolar PROJETO

Leia mais

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS

SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS SISTEMA DE GESTÃO DE PRODUÇÃO DE EVENTOS Rodrigo das Neves Wagner Luiz Gustavo Galves Mählmann Resumo: O presente artigo trata de um projeto de desenvolvimento de uma aplicação para uma produtora de eventos,

Leia mais

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com ANÁLISE E PROJETO ORIENTADO A OBJETOS Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Análise Descrição do problema a ser implementado Descrição dos objetos e classes que fazem parte do problema, Descrição

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

Leia mais

Uma Abordagem sobre Mapeamento Objeto Relacional com Hibernate

Uma Abordagem sobre Mapeamento Objeto Relacional com Hibernate Uma Abordagem sobre Mapeamento Objeto Relacional com Hibernate Luis Gustavo Zandarim Soares 1, Késsia Rita da Costa Marchi 1 1 Universidade Paranaense (Unipar) Paraná PR Brasil luisgustavo@live.co.uk,

Leia mais

ANEXO III PERFIL DOS PROFISSIONAIS, FORMAÇÃO E ATIVIDADES A DESENVOLVER PARA MANUTENÇÃO E DESENVOLVIMENTO

ANEXO III PERFIL DOS PROFISSIONAIS, FORMAÇÃO E ATIVIDADES A DESENVOLVER PARA MANUTENÇÃO E DESENVOLVIMENTO CONCORRÊNCIA DIRAD/CPLIC-008/2008 1 ANEXO III PERFIL DOS PROFISSIONAIS, FORMAÇÃO E ATIVIDADES A DESENVOLVER PARA MANUTENÇÃO E DESENVOLVIMENTO 1. INFORMAÇÕES GERAIS E CARACTERÍSTICA DO ATUAL AMBIENTE CORPORATIVO

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC

DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC DESENVOLVENDO APLICAÇÕES UTILIZANDO JAVASERVER FACES E MVC Felipe Moreira Decol Claro 1, Késsia Rita da Costa Marchi 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil felipe4258@hotmail.com, kessia@unipar.br

Leia mais

Casos de Uso - definições

Casos de Uso - definições Casos de Uso - definições Um caso de uso é uma descrição narrativa de uma seqüência de eventos que ocorre quando um ator (agente externo) usa um sistema para realizar uma tarefa [Jacobson 92] Um caso de

Leia mais

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II UNIOESTE - Universidade Estadual do Oeste do Paraná CCET - Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Curso de Bacharelado em Informática PROJETO DA DISCIPLINA PES II Processo de

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR

UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR UNIVERSIDADE FEDERAL FLUMINENSE IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO VEICULAR NITERÓI 2010 IVY MARTINS SALLES SATCAR: SISTEMA DE GERÊNCIA DE UMA EMPRESA DE RASTREAMENTO

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

Leia mais

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML

WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Carlos Henrique Pereira WebUML: Uma Ferramenta Colaborativa de Apoio ao Projeto e Análise de Sistemas Descritos em Classes UML Florianópolis - SC 2007 / 2 Resumo O objetivo deste trabalho é especificar

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

Documento de Projeto de Software

Documento de Projeto de Software Documento de Projeto de Software Projeto: Vídeo Locadora Passatempo Versão: 1.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta o documento de projeto (design) do sistema de

Leia mais

Associação Carioca de Ensino Superior Centro Universitário Carioca

Associação Carioca de Ensino Superior Centro Universitário Carioca Desenvolvimento de Aplicações Web Lista de Exercícios Métodos HTTP 1. No tocante ao protocolo de transferência de hipertexto (HTTP), esse protocolo da categoria "solicitação e resposta" possui três métodos

Leia mais

CURSO DESENVOLVEDOR JAVA Edição 2010

CURSO DESENVOLVEDOR JAVA Edição 2010 CURSO DESENVOLVEDOR JAVA Edição 2010 O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos e com o uso

Leia mais

IplanRio DOP - Diretoria de Operações GIT - Gerência de Infraestrutura Tecnológica Gerente da GIT

IplanRio DOP - Diretoria de Operações GIT - Gerência de Infraestrutura Tecnológica Gerente da GIT 1. IDENTIFICAÇÃO Padrão Segmento Código P06.002 Revisão v. 2014 Plataformas Web 2. PUBLICAÇÃO Recursos Tecnológicos Versão Data para adoção Publicação v. 2014 23 de dezembro de 2014 PORTARIA N Nº 225 de

Leia mais

Diagramas de Casos de Uso

Diagramas de Casos de Uso Diagramas de Casos de Uso Não diga pouco em muitas palavras, mas sim, muito em poucas. Pitágoras Casos de uso O modelo de casos de uso modela os requisitos funcionais do sistema. É uma técnica de modelagem

Leia mais

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Sumário. Java 2 Enterprise Edition. J2EE (Java 2 Enterprise Edition)

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Sumário. Java 2 Enterprise Edition. J2EE (Java 2 Enterprise Edition) Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) J2EE () Sumário Introdução J2EE () APIs J2EE Web Container: Servlets e JSP Padrão XML 2 J2EE é Uma especificação para servidores

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

E-Commerce Master. Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM

E-Commerce Master. Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM E-Commerce Master Versão: 1.0 Data: 05/06/2013 Identificador do documento: EM Histórico de revisões Versão Data Autor Descrição Localização 1.0 05/06/2013 Thyago Ferreira 1.0 05/06/2013 Vilmar de Sousa

Leia mais

SCE-557. Técnicas de Programação para WEB. Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br

SCE-557. Técnicas de Programação para WEB. Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br SCE-557 Técnicas de Programação para WEB Rodrigo Fernandes de Mello http://www.icmc.usp.br/~mello mello@icmc.usp.br 1 Cronograma Fundamentos sobre servidores e clientes Linguagens Server e Client side

Leia mais

Documento de Projeto de Sistema

Documento de Projeto de Sistema Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda,

Leia mais

Banco de Dados de Músicas. Andre Lima Rocha Campos Osório Pereira Carvalho

Banco de Dados de Músicas. Andre Lima Rocha Campos Osório Pereira Carvalho Banco de Dados de Músicas Andre Lima Rocha Campos Osório Pereira Carvalho Definição Aplicação Web que oferece ao usuário um serviço de busca de músicas e informações relacionadas, como compositor, interprete,

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA. Informatização de farmácias publicas utilizando software livre.

UNIVERSIDADE FEDERAL DE SANTA CATARINA. Informatização de farmácias publicas utilizando software livre. UNIVERSIDADE FEDERAL DE SANTA CATARINA Informatização de farmácias publicas utilizando software livre. MURILO NUNES ELIAS FLORIANÓPOLIS SC 2007/2 UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS 1/38 DOCUMENTO DE REQUISITOS GED Gerenciamento Eletrônico de Documentos Versão 1.1 Identificação do Projeto CLIENTE: NOME DO CLIENTE TIPO DO SISTEMA OU PROJETO Participantes Função Email Abilio Patrocinador

Leia mais

Sistema de Automação Comercial de Pedidos

Sistema de Automação Comercial de Pedidos Termo de Abertura Sistema de Automação Comercial de Pedidos Cabana - Versão 1.0 Iteração 1.0- Release 1.0 Versão do Documento: 1.5 Histórico de Revisão Data Versão do Documento Descrição Autor 18/03/2011

Leia mais

Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso

Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso Análise Orientada a Objetos Modelagem Requisitos usando Casos de Uso Não diga pouco em muitas palavras, mas sim, muito em poucas. Pitágoras Especificação e Modelagem de Requisitos Regras de Negócio Glossário

Leia mais

Modelagem de Casos de Uso! Um modelo funcional

Modelagem de Casos de Uso! Um modelo funcional Modelagem de Casos de Uso Diagrama de Casos de Uso Especificação de Cenários! Um modelo funcional! Mostra como os valores são processados, sem preocupações com:! ordenamento (seqüência) das ações;! as

Leia mais

GERADOR DE CÓDIGO JSP BASEADO EM PROJETO DE SGBD. Acadêmico: Maicon Klug Orientadora: Joyce Martins

GERADOR DE CÓDIGO JSP BASEADO EM PROJETO DE SGBD. Acadêmico: Maicon Klug Orientadora: Joyce Martins GERADOR DE CÓDIGO JSP BASEADO EM PROJETO DE SGBD Acadêmico: Maicon Klug Orientadora: Joyce Martins Roteiro Introdução Objetivos do trabalho Fundamentação teórica Desenvolvimento do trabalho Conclusão Extensões

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 MANTER FUNCIONÁRIO RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Programação WEB Introdução

Programação WEB Introdução Programação WEB Introdução Rafael Vieira Coelho IFRS Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul Campus Farroupilha rafael.coelho@farroupilha.ifrs.edu.br Roteiro 1) Conceitos

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS

ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS ESPECIFICAÇÃO DO ESCOPO DE SISTEMA DE SOFTWARE A PARTIR DA UTILIZAÇÃO DA ENGENHARIA DE REQUISITOS Rosiane da Silva Biscaia Discente do curso Tecnologia em Análise e Desenvolvimento de Sistemas Faculdades

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

Leia mais

Fundação Universidade Estadual de Maringá

Fundação Universidade Estadual de Maringá Fundação Universidade Estadual de Maringá PAD/DIRETORIA DE MATERIAL E PATRIMÔNIO AVISO DE LICITAÇÃO EDITAL 485/2007 CONCORRÊNCIA PÚBLICA - PROC.: N 15344/2007 OBJETO: CONTRATAÇÃO DE UMA EMPRESA ESPECIALIZADA

Leia mais

UNIMINAS SOFTWARE PARA GESTÃO DE ACADEMIA ALESSANDRO DE SOUZA VITOR EDUARDO ELIAS DE LIMA FILHO RICARDO DA SILVA JORGE

UNIMINAS SOFTWARE PARA GESTÃO DE ACADEMIA ALESSANDRO DE SOUZA VITOR EDUARDO ELIAS DE LIMA FILHO RICARDO DA SILVA JORGE UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO SOFTWARE PARA GESTÃO DE ACADEMIA

Leia mais

Sistema Pizzaria.Net. Especificação de requisitos do sistema. Preparado por Cabaça Tech. Preparado para Pizzaria entrega rápida. Versão 1.

Sistema Pizzaria.Net. Especificação de requisitos do sistema. Preparado por Cabaça Tech. Preparado para Pizzaria entrega rápida. Versão 1. Especificação de requisitos do sistema Preparado por Cabaça Tech Preparado para Pizzaria entrega rápida Versão 1.0 Histórico de revisão Data Versão Autor Descrição 29/06/2009 1.0 Josino Rodrigues Versão

Leia mais

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1

DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 DEFINIÇÃO DE REQUISITOS SISTEMA DE CONTROLE DE FINANÇAS WEB 1.0 BAIXA DE CONTAS A PAGAR RELEASE 4.1 SUMÁRIO DEFINIÇÃO DE REQUISITOS 4 1. INTRODUÇÃO 4 1.1 FINALIDADE 4 1.2 ESCOPO 4 1.3 DEFINIÇÕES, ACRÔNIMOS

Leia mais

Processo de Engenharia de Software II

Processo de Engenharia de Software II UNIOESTE - Universidade Estadual do Oeste do Paraná CCET Centro de ciências Exatas e Tecnológicas Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Processo de Engenharia

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Documento de Visão. Versão 2.5 Projeto SysTrack - Grupo 01

Documento de Visão. Versão 2.5 Projeto SysTrack - Grupo 01 Documento de Visão Versão 2.5 Projeto SysTrack - Grupo 01 Junho de 2011 Histórico de revisão: DATA VERSÃO DESCRIÇÃO AUTORES 19/02/2011 1.0 Versão inicial. João Ricardo, Diogo Henrique. 24/02/2011 2.0 Modificação

Leia mais