Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE. Lucas da Silva Inácio

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

Download "Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE. Lucas da Silva Inácio"

Transcrição

1 UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Lucas da Silva Inácio CASCAVEL 2011

2 LUCAS DA SILVA INÁCIO Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação, do Centro de Ciências Exatas e Tecnológicas da Universidade Estadual do Oeste do Paraná - Campus de Cascavel Orientador: Prof. Dr. Clodis Boscarioli CASCAVEL 2011

3 LUCAS DA SILVA INÁCIO Desenvolvimento de um Sistema Web para Gerenciamento de Programas de Pós-Graduação Stricto Sensu da UNIOESTE Monografia apresentada como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação, pela Universidade Estadual do Oeste do Paraná, Campus de Cascavel, aprovada pela Comissão formada pelos professores: Prof. Dr. Clodis Boscarioli (Orientador) Colegiado de Ciência da Computação, UNIOESTE Prof. Dr. Marcio Seiji Oyamada Colegiado de Ciência da Computação, UNIOESTE Prof. MSc. Anibal Mantovani Diniz Colegiado de Ciência da Computação, UNIOESTE Cascavel, 07 de Novembro de 2011.

4 DEDICATÓRIA Dedico à minha família, meus professores e meus amigos que sempre me dão força e motivação, proporcionando a realização deste e outros trabalhos. Sem eles, este momento não seria possível.

5 Lista de Figuras Figura 1 - Cubo com as dimensões produto, tempo e região [5] Figura 2 Data warehouse no contexto do sistema [15] Figura 3 - Star Schema [10] Figura 4 - Snowflake Schema [10] Figura 5 - Modelo SD (Dependências Estratégicas) Figura 6 Diagrama de Requisitos Não-Funcionais Figura 7 - Diagrama de Casos de Uso Figura 8 - Diagrama de Funções dos Atores do Sistema Figura 9 - Diagrama de Processo da Gerência de Cronograma e Etapa Figura 10 - Diagrama de Processo da Gerência de Programa, Nível e Disciplina Figura 11 - Diagrama de Processo da Gerência de Áreas e Linha de Pesquisa Figura 12 - Diagrama de Processo da Gerência de Oferta de Disciplina Figura 13 - Diagrama de Processo da Gerência das Inscrições Regulares Figura 14 - Diagrama de Processo da Gerência das Inscrições Especiais Figura 15 - Diagrama de Processo da Gerência Matrícula em Disciplina Figura 16 - Diagrama de Processo do Lançamento de Notas e Frequência Figura 17 - Camadas do Sistema Figura 18 - Diagrama de Classe organizado em camadas e pacotes do sistema Figura 19 - Diagrama Relacional Figura 20 - Modelo de Classe da Camada de Aplicação Figura 21 - Arquitetura dos Componentes Ext JS Figura 22 - Página principal do sistema Figura 23 - Star Schema do Sistema Proposto Figura 24 - Interface JPalo para o Cubo v

6 Lista de Abreviaturas e Siglas OLAP IBM APL MOLAP ROLAP HOLAP DOLAP WOLAP MDX PGEAGRI PRPPG SGBD UML SD NFR SQL MR RF RNF MVC ETL OLTP KDD API PAT On-Line Analytical Processing International Business Machines A Programming Language Multidimensional On-Line Analytical Processing Relational On-Line Processing Hybrid On-Line Analytical Processing Desktop On-Line Analytical Processing Web On-Line Analytical Processing Multi-Dimensional Expressions Programa de Pós-Graduação de Engenharia Agrícola Pró-Reitoria de Pesquisa e Pós-Graduação Sistema Gerenciador de Banco de Dados Unified Modeling Language Strategic Dependency Non-Functional Requirements in Software Engineering Structured Query Language Modelo Relacional Requisito Funcional Requisito Não-Funcional Model-View-Controller Extraction Transformation Loading On-Line Transaction Processing Knowledge Discovery in Databases Application Programming Interface Pentaho Analysis Tool vi

7 Sumário LISTA DE FIGURAS... V LISTA DE ABREVIATURAS E SIGLAS... VI RESUMO... VIII CAPÍTULO INTRODUÇÃO... 9 CAPÍTULO OLAP E VISUALIZAÇÃO DE DADOS Conceitos Operações multidimensionais OLAP Arquiteturas Data Warehouse Data Mart Estrutura de Armazenamento Ferramentas CAPÍTULO PLANEJAMENTO DO SISTEMA Resumo do Processo Atual A Solução Proposta CAPÍTULO ESTRUTURA DO SISTEMA Camada de Dados Camada de Aplicação Camada de Apresentação Módulo OLAP CAPÍTULO CONSIDERAÇÕES FINAIS APÊNDICE A REQUISITOS FUNCIONAIS APÊNDICE B REQUISITOS NÃO-FUNCIONAIS APÊNDICE C CASOS DE USO REFERÊNCIAS BIBLIOGRÁFICAS vii

8 Resumo Este documento faz um descritivo dos requisitos para o desenvolvimento de um sistema que tem por finalidade gerenciar e otimizar os processos gerenciais dos Programas de Pós-Graduação Stricto Sensu, utilizados atualmente pela Universidade Estadual do Oeste do Paraná (UNIOESTE). O sistema inclui também um módulo preliminar para gerenciar relatórios, trazendo uma opção de front-end para os usuários modelarem de forma dinâmica suas visões de relatório, por meio de OLAP (On-Line Analytical Processing). O trabalho apresenta também, as etapas do processo de desenvolvimento, iniciado pelo levantamento de requisitos, passando pela modelagem e posteriormente à implementação, onde se discute o estado atual do sistema e suas perspectivas. Palavras-chave: Processo de Desenvolvimento de Software, Relatórios Dinâmicos, OLAP. viii

9 Capítulo 1 Introdução Todas as organizações demandam gerenciamento e informação. Quando o domínio em questão é grande e envolve diversos processos e pessoas, os processos manuais tornam-se complexos de serem gerenciados, necessitando de Sistemas de Informação, que são fundamentais para agilizar as rotinas e auxiliar gestores em suas tarefas de controle e tomada de decisão. A Universidade Estadual do Oeste do Paraná UNIOESTE, uma universidade composta por cinco campi e com diversos sistemas para atender as necessidades da comunidade universitária, necessita, para auxílio em seus processos, realizar a junção das áreas de Sistemas de Informação e Tecnologia da Informação, para com isso, gerenciar com dinamismo e organização as suas questões gerenciais. Na UNIOESTE, há o Núcleo de Tecnologia da Informação (NTI), responsável pela produção das dezenas de sistemas utilizados pela instituição e outros a serem projetados, de demanda já confirmada. Um desses sistemas a serem projetados é o de gerenciamento dos Programas de Pós-Graduação Stricto Sensu da Universidade, objeto de investigação desse estudo. Atualmente, o gerenciamento de candidatos e acadêmicos de Programas de Pós- Graduação Stricto Sensu da UNIOESTE é realizado de forma manual, sem um padrão institucional, demandando muito tempo dos colaboradores da Universidade no processo de inscrição, seleção, matrícula e gerenciamento dos alunos. A obtenção de dados referentes aos cursos é prejudicada por esses processos manuais que tornam as respostas lentas. Essas são algumas das características que evidenciam a necessidade da implantação de um sistema informatizado para o seu controle e gerenciamento. 9

10 A UNIOESTE contém diversos Programas de Pós-Graduação Stricto Sensu, espalhados pelos diversos Campi da Universidade, o que dificulta a gestão e padronização dos processos relacionados aos Programas. Este projeto tem por finalidade o início do desenvolvimento de uma aplicação web que gerencie as transações e atividades que envolvam os processos organizacionais do sistema supracitado. Também, o estudo e desenvolvido de um módulo que gere relatórios dinâmicos, mais interativos ao usuário final, para que este tenha uma maior facilidade em manipular os dados do sistema, usufruindo da dinâmica de filtrar informações para análise sem a necessidade de recorrer ao programador do sistema toda vez que necessite gerar um relatório diferente. OLAP (On-Line Analytical Processing), que são aplicações onde o usuário final tem acesso as informações da base de dados para construir relatórios capazes de responder ou apoiar as suas questões gerenciais e proporcionam condições de análise de dados necessárias para auxiliar a tomada de decisão dos analistas ou gerentes que utilizam o sistema [1], será investigado e utilizado neste contexto. Este documento está organizado como segue: O Capítulo 2 aborda conceitos e características de uma aplicação OLAP, bem como apresenta a ferramenta OLAP a ser utilizada. No Capítulo 3 é apresentado o domínio do sistema, descrevendo a forma manual de execução atualmente vigente e o sistema proposto, com todos os requisitos funcionais e não funcionais levantados. No Capítulo 4 são apresentadas as camadas do sistema e a forma como foi desenvolvida abrangendo as camadas de dados, aplicação e visão, também, um descritivo das etapas realizadas para a construção do módulo OLAP do sistema, da camada de dados à visão. O Capítulo 5 traz as considerações finais do trabalho desenvolvido, comentando sobre as dificuldades encontradas e de trabalhos futuros. O Apêndice A traz a descrição dos requisitos funcionais e os respectivos usuários de cada requisito. No Apêndice B são descritos os requisitos não-funcionais do sistema. No Apêndice C são listados os Casos de Uso do sistema, descrevendo os passos para a sua implementação. 10

11 Capítulo 2 OLAP e Visualização de Dados Neste capítulo, OLAP será abordado, de forma a descrever sua origem, seus conceitos, as arquiteturas de armazenamento utilizadas e, como este provê apoio ao usuário final na tomada de decisão por meio de seus relatórios dinâmicos. 2.1 Conceitos A IBM desenvolveu e implementou a primeira linguagem com análise multidimensional no final da década de 60 chamada de APL (A Programming Language). Definida matematicamente, baseada em símbolos gregos, foi amplamente utilizada na década de 80 e 90 em aplicações de negócio. Antes disso, existiam somente aplicações OLTP (On- Line Transaction Processing), cujo foco é proporcionar, de forma planar, aos usuários a criação, atualização e recuperação das informações sobre registros individuais. Na década de 90 introduziu-se então uma nova classe de ferramentas, batizada de OLAP, possuindo a maioria dos conceitos introduzidos pala linguagem APL, e com maior integridade na utilização dos dados fontes. O termo OLAP foi usado pela primeira vez por Edgar Frank Codd, o qual definiu doze regras que caracterizam uma aplicação OLAP [2]. 1. Conceito de visão multidimensional: tornou-se a característica fundamental no desenvolvimento destas aplicações [4]. Nele, os dados são modelados em diversas dimensões, podendo haver cruzamento de todos os tipos de informações. 2. Transparência: define-se que OLAP deve atender a todas as solicitações do analista, não importando de onde os dados virão. Todas as implicações devem ser transparentes para os usuários finais. 11

12 3. Acessibilidade: diz-se que as ferramentas OLAP devem permitir conexão com todas as bases de dados legadas. A distribuição de informações deve ser mapeada para permitir o acesso a qualquer base de dados. 4. Desempenho consistente de relatório: refere-se a não degradação de desempenho do sistema a medida com que o número de dimensões ou a base de dados vão crescendo. É fundamental para manter a facilidade de uso para o usuário final. 5. Arquitetura cliente/servidor: OLAP deve ser construída em arquitetura clienteservidor para que possa atender a qualquer usuário em qualquer ambiente operacional. 6. Dimensionamento genérico: diz respeito à capacidade de tratar informações em qualquer quantidade de dimensões. 7. Tratamento dinâmico de matrizes esparsas: Para conseguir operações de cruzamento dimensional irrestritas é necessário tratar a esparsidade 1 dos dados. Devido ao grande volume de informações armazenadas nas diversas dimensões de um modelo multidimensional, a esparsidade se torna comum, e então essas células nulas devem ser tratadas para evitar custos com memória. 8. Suporte a multiusuários: nas grandes organizações é comum vários analistas trabalharem com a mesma base de dados. 9. Operações de cruzamento dimensional irrestritas: as ferramentas OLAP devem ser capazes de navegar nas diversas dimensões existentes. 10. Manipulação intuitiva de dados: os usuários devem ser capazes de manipular os dados livremente, sem necessitar de qualquer tipo de ajuda. 11. Relatórios flexíveis: O usuário deve ter a flexibilidade na geração de relatórios, para efetuar qualquer tipo de consulta. 12. Níveis de dimensões e agregações ilimitados: diz respeito ao número de dimensões simultâneas de dados que podem ser cruzadas. A recomendação é de pelo menos quinze, devendo haver vários níveis de agregação dos dados. 1 Esparsidade: uma base de dados com grande proporção de elementos nulos. 12

13 OLAP é uma das tecnologias que compõem Business Intelligence, 2 com capacidade para manipular e analisar um grande volume de dados sob múltiplas perspectivas, utilizada para apoiar as empresas na análise de suas informações, visando obter análises (novos conhecimentos) a serem empregadas na tomada de decisão. 2.2 Operações multidimensionais OLAP A multidimensionalidade é um conceito chave da análise feita por ferramentas OLAP. Neste tipo de análise os dados são modelados em uma estrutura conhecida como cubo e envolve conceitos como: dimensão, hierarquia, membro e medida para representar a visão multidimensional. Figura 1 - Cubo com as dimensões produto, tempo e região [5] Na Figura 1, o cubo nos fornece a idéia de navegação em vários assuntos (dimensões), são elas: produto, tempo e região, para uma mesma base de dados, ou seja, é uma estrutura onde armazenam os dados de negócio em formato multidimensional. A dimensão é uma unidade de análise que agrupa dados de negócio relacionados. Uma dimensão pode ser definida como uma característica ou um atributo de um conjunto de dados. Cada dimensão contém membros que compartilham características comuns e os membros são frequentemente organizados hierarquicamente dentro da dimensão [6]. Uma hierarquia é composta por todos os níveis de uma dimensão e medida é uma dimensão especial utilizada para realizar comparações [4]. Considerando os dados em um cubo multidimensional, cada célula de um cubo poderia conter dados para um objeto específico e os dados podem ser consultados em 2 Business Intelligence pode ser definido como um conjunto de modelos matemáticos e metodologias de análise que exploram os dados disponíveis para gerar informações e conhecimentos úteis para o complexo processo decisório [3]. 13

14 qualquer combinação das dimensões. A mudança de uma hierarquia dimensional (orientação) para outra é realizada em um cubo de dados pela técnica chamada de pivoteamento ou rotação, como se houvesse uma rotação no cubo para mostrar uma orientação diferente dos eixos. Também há flexibilidade de fazer roll-up e drill-down. Apresentações roll-up se movem para cima na hierarquia de uma dimensão, agrupando dados, como se estivesse percorrendo uma dimensão do seu detalhamento para a generalização. Já drill-down é a capacidade oposta, fornecendo uma visão de granularidade mais fina [8]. Como exemplo, considere um relatório por região: fazendo drill-up é como se estivesse passando da visão cidade para estado, e assim sucessivamente. Para drill-down é o inverso, detalhando mais os dados, passando de estado para cidade, de cidade para bairro, e assim sucessivamente. Existem ferramentas para a visualização dos dados que permitem aplicação dos conceitos acima, de acordo com a escolha das dimensões. Ferramentas dessa natureza serão utilizadas neste trabalho para a implantação destas funcionalidades no sistema proposto. 2.3 Arquiteturas Existem várias maneiras de classificar uma ferramenta OLAP quanto a sua arquitetura. Vamos dividir essa análise de arquiteturas em relação ao tipo de dado acessado e ao processamento desses dados. Todas elas provêm acesso cliente-servidor e à visão multidimensional dos dados, independente de onde os dados foram extraídos (INMON, 1997) apud [1]. Os dados podem ser armazenados de diferentes formas conforme a seguinte taxonomia: MOLAP (Multidimensional On-Line Analytical processing): acessam bases de dados multidimensionais, elas extraem informação de estruturas de dados pré-processadas, geralmente em forma de cubos, onde estes cubos contêm todas as informações desejadas e pré-estipuladas. Sua implementação varia de acordo com a ferramenta OLAP, podendo ser implementado em um banco de dados relacional, porém não na terceira forma normal. Sua vantagem está na predeterminação dos dados, pois a estrutura fica calculada e otimizada para as consultas. Uma de suas limitações é a possibilidade dos dados serem esparsos (nem todo cruzamento das dimensões contém dados), ocorrendo a chamada explosão de armazenamento de dados, ou seja, um imenso banco de dados multidimensional contendo poucos dados 14

15 armazenados [1]. Outras limitações dessa ferramenta estão relacionadas ao fato dos bancos multidimensionais serem sistemas proprietários que não seguem padrões, ou seja, cada desenvolvedor cria a sua própria estrutura para o banco e as próprias ferramentas de suporte (CARVALHO, 2004) apud [1]. ROLAP (Relational On-Line Processing): não utilizam os cubos pré-calculados, atendem melhor usuários que não tem um escopo de análise bem definido. A medida que o usuário monta uma consulta, a ferramenta faz a consulta em uma base de dados relacional. A principal característica é a flexibilidade de fazer qualquer consulta, mas há desvantagens no tempo de resposta, pois dependendo do tamanho da consulta, o tempo de resposta pode ser muito longo. Ao comparar as duas arquiteturas em termos de desenvolvimento, a MOLAP se torna mais fácil de construir, pois a ferramenta já realiza as agregações e não requer tuning 3 específico de um banco de dados multidimensional. Já a arquitetura ROLAP requer a criação de um projeto lógico específico, tuning do banco de dados relacional e a criação e manutenção das tabelas sumarizadas [9]. HOLAP (Hybrid On-Line Analytical Processing): é a integração das duas arquiteturas acima, oferecendo escolha entre um banco de dados relacional e multidimensional, carregando resultados de consultas relacionais em bancos de dados multidimensionais. Utiliza um banco de dados multidimensional para fazer um cache dos dados com um nível maior de agregação e usar um banco de dados relacional para fazer um acesso dinâmico aos dados detalhados [9]. DOLAP (Desktop On-Line Analytical Processing): seu foco é a utilização em desktops, é uma ferramenta de baixo custo que acessam os dados localmente através de uma base de dados local multidimensional ou um repositório local. A vantagem é a redução da sobrecarga do servidor de banco de dados, uma vez que todos os processos OLAP ocorrem na máquina cliente. A desvantagem é no tamanho do cubo, o qual não pode ser muito grande, caso contrário sobrecarregaria a máquina local e a máquina não suportaria [1]. WOLAP (Web On-Line Analytical Processing): é a utilização de uma ferramenta OLAP em um browser (navegador web). A diferença desta ferramenta para as outras é sua abrangência, facilitando a distribuição e o acesso remoto dos dados aos usuários. 3 Tuning: afinação, otimização ou personalização da base de dados. 15

16 Neste trabalho será utilizada a arquitetura WOLAP juntamente com uma base de dados relacional, pois sua implementação será disponibiliza on-line, oferecendo escalabilidade e facilidade de acesso ao usuário do sistema. Ao usar uma base de dados relacional para a montagem do cubo ganha-se flexibilidade ao poder fazer qualquer consulta na parte relacional. O fato de ser uma base de dados relacional o funcionamento de uma ferramenta com características OLAP exigirá a criação de um projeto lógico específico que será adotado na Seção Data Warehouse Data warehouse, segundo (INMON, 2005) apud [14], é uma coleção de dados orientada por assuntos, integrada, variante no tempo e não volátil, que tem por objetivo dar suporte aos processos de tomada de decisão. Pode ser traduzido como depósito de dados e seu objetivo é trabalhar com uma grande quantidade de informação e principalmente dados históricos. Analisando bem, são os acontecimentos históricos que levam a uma melhor tomada de decisão e à prevenção de eventos futuros. Um data warehouse é orientado a assunto, diferente dos sistemas transacionais existentes que são orientados por processos comuns. Em uma companhia de seguros, por exemplo, as aplicações transacionais poderiam estar divididas em automóvel, vida, saúde, e perdas. Já as áreas de assunto para essa companhia poderiam, por exemplo, estar divididas em cliente, apólice, prêmio e indenização [14]. Já a integração dos dados quer dizer que as inconsistências encontradas em dados provenientes de diversos sistemas são desfeitas. Um exemplo é o caso da codificação do gênero, onde podem existir diversas formas de representação entre os sistemas, porém, ao serem incorporados ao data warehouse, estes dados necessitam representar o mesmo fato, independente da sua codificação inicial [14]. A característica do data warehouse de ser não volátil, está ligada primeiramente a atualização dos dados, que geralmente não ocorre neste ambiente. Os dados são carregados e acessados normalmente em grandes quantidades. E as operações de processamento neste ambiente se restringem a inclusão de novos registros e consulta aos registros existentes, [14]. 16

17 O fato de ser variável em relação ao tempo quer dizer que os dados do data warehouse representam resultados operacionais em um determinado momento de tempo, o momento em que foram capturados da base de dados operacional. Como estes dados representam um estado da organização em um período de tempo eles não podem ser atualizados [14]. A seguir, uma figura ilustrando onde o data warehouse se enquadra no contexto dos sistemas. Figura 2 Data warehouse no contexto do sistema [15] A Figura 2 demonstra claramente onde o data warehouse encaixa-se no sistema. Primeiramente, são coletados dados de sistemas transacionais OLTP (On-Line Transaction Processing), arquivos etc., reunindo-os por meio de uma ferramenta ETL (Extraction Transformation Loading Extração, Transformação e Carga) fazendo todo o tratamento necessário nos dados para garantir sua padronização para posterior inserção na base de dados do data warehouse. O processo ETL é dividido em etapas e é responsável pela integridade, qualidade e consolidação das informações provenientes das fontes de dados até o armazenamento no data warehouse. Assim, o usuário poderá acessar os dados do data warehouse por meio de uma ferramenta Olap Analysis, onde fazem a leitura das informações do data warehouse e apresentam em front-end com a funcionalidade de manipular dimensões e hierarquias. 17

18 O objetivo deste trabalho não é a modelagem de um data warehouse completo para o sistema proposto no Capítulo 3, mas sim para dar sustentação ao subconjunto de dados necessários para a montagem de um data mart, para validar a hipótese do uso de OLAP no domínio da aplicação estudada Data Mart Conforme (INMON, 2005) apud [14], um data mart é uma estrutura de dados dedicada em servir as necessidades de análise de um grupo de pessoas. Segundo (LAUDON, 2007) apud [14], data mart é um subconjunto de um data warehouse, no qual uma porção resumida ou altamente focalizada dos dados da organização é colocada em um banco separado destinado a uma população específica de usuários. Neste trabalho, será realizada a modelagem de um data mart, que será o servidor de dados para alimentar um cubo OLAP, destinado para análise de um grupo de usuários do sistema Estrutura de Armazenamento Os cubos possuem suas características e elementos, assim como possuem a modelagem de suas estruturas ditando basicamente sua forma de organização e suas dimensões. Os dois modelos mais utilizados são Star Schema (esquema estrela) e Snowflake Schema (esquema flocos de neve). O modelo Star é uma representação genérica de um modelo dimensional em um banco de dados relacional em que uma tabela de fatos contendo métricas usadas para medir o desempenho do negócio e com chaves compostas é unida a várias tabelas de dimensão. É altamente desnormalizado com o intuito de reduzir o número de junções (joins) envolvido nas consultas [15]. A Figura 3 representa a estrutura da modelagem do Star Schema, este modelo está representando o armazenamento de dados em tabelas, relacionando o fato da venda com suas dimensões produto, cliente, revenda e tempo. 18

19 Figura 3 - Star Schema [10] O modelo Snowflake possui a diferença que as dimensões e as respectivas tabelas de dimensões são normalizadas. Esta característica garante maior organização nos dados manipulados. Segundo [15], s tipos de medidas ou métricas são aditivas, semi aditivas ou não aditivas: - Aditivas: são as mais frequentes, podem ser somadas cruzando-se qualquer uma de suas dimensões. Exemplo: lucro líquido. - Semi aditivas: podem ser somadas através de apenas uma parte de suas dimensões. Exemplo: quantidade em estoque (não faz sentido somá-la através da dimensão tempo) - Não aditivas: medidas não aditivas não podem ser somadas por nenhuma de suas dimensões. O exemplo mais comum desse tipo de medidas são valores percentuais. O modelo Snowflake é uma extensão do modelo Star, sendo o resultado da decomposição (normalização) de uma ou mais dimensões, formando hierarquias nessas dimensões. Esse tipo de modelo é usado quando há dimensões muito grandes, estáticas ou semi-estáticas. A vantagem do seu uso está na diminuição do volume de dados trazido para a memória. No entanto, caso a navegação dentro da hierarquia da dimensão seja inevitável, a maior quantidade de joins torna a consulta mais complexa [15]. A Figura 4 representa a estrutura da modelagem do Snowflake Schema, representando o armazenamento de dados em tabelas. As dimensões Revenda e Cliente estão normalizadas em relação às informações de Logradouro, Bairro, Cidade, Estado e Região. 19

20 Figura 4 - Snowflake Schema [10] Outro conceito importante a ser considerado ao se fazer um modelo é o da granularidade. Granularidade é o nível no qual os dados do data warehouse ou data mart estão sumarizados. O grão é o nível mais detalhado do dado. Se definir o grão num nível muito detalhado, o usuário poderá ver a informação em qualquer nível de agregação. No entanto, a escolha de um nível baixo demais pode acarretar um aumento muito grande do volume de dados armazenado e, consequentemente, o prejuízo do desempenho. Por outro lado, se a granularidade definida for muito alta, o usuário ficará impossibilitado de realizar consultas mais detalhadas, como afirma [15]. Com o objetivo de ganhar desempenho nas operações de consulta ao manipular as dimensões e hierarquias em uma ferramenta OLAP, optou-se por implementar a estrutura Star, com um conjunto de dados desnormalizados mas com um ganho de desempenho. Como as dimensões não serão grandes, não faz sentido utilizar o esquema Snowflake. 20

21 2.5 Ferramentas Atualmente existem no mercado diversos produtos OLAP (Analysis Services da Microsoft [17], o Cognos da IBM [18], OLAP da Oracle [19] e Pentaho [20]), os quais se diferenciam em funcionalidades, arquitetura, interfaces e impacto sobre a organização, o que pode dificultar a escolha da ferramenta OLAP mais adequada às necessidades de uma organização. Como um dos objetivos deste trabalho é não ter gastos com compra de produtos, optou-se por utilizar o pacote Pentaho, uma aplicação open source bastante utilizada na área de Business Intelligence open source, como destaca [10]. Pentaho possui um módulo chamado Pentaho Analysis, que incorpora o servidor OLAP Mondrian e o cliente OLAP JPivot. Mondrian executa consultas escritas na linguagem MDX (Multi-Dimensional Expressions), lendo dados de um banco de dados relacional, e os apresenta em um formato multidimensional utilizando-se de uma API (Application Programming Interface) Java. Além do cliente JPivot do Pentaho, existem outros clientes que interagem com o módulo servidor do Pentaho. Como exemplo, além do JPivot tem-se o JPalo [21] e PAT (Pentaho Analysis Tool) [22]. Por uma questão de usabilidade neste trabalho, ao invés de utilizar o cliente JPivot, será utilizado JPalo, que traz ao usuário final uma interface gráfica mais rica 4 e com maior facilidades na manipulação dos dados. Em [16], é apresentada uma comparação entre ferramentas Business Intelligence e constatou-se que JPalo possui vantagem nesse sentido. 4 Aplicações de Internet Rica (da sigla em inglês RIA - Rich Internet Application): são Aplicações Web que tem características e funcionalidades de softwares tradicionais do tipo Desktop. RIA típicos transferem todo o processamento da interface para o navegador da internet, porém mantém a maior parte dos dados (por exemplo, o estado do Programa, dados do banco) no servidor de aplicação. 21

22 Capítulo 3 Planejamento do Sistema Este capítulo tem por finalidade apresentar o levantamento de todos os requisitos que deram origem ao desenvolvimento de uma aplicação web para gerenciar as transações e atividades que envolvam os processos organizacionais do sistema de Pós-Graduação Stricto Sensu da UNIOESTE. Um dos primeiros Programas de Pós-Graduações Stricto Sensu da Unioeste, o PGEAGRI (Programa de Pós-Graduação de Engenharia Agrícola), foi utilizado para o levantamento e modelagem dos requisitos do sistema; além disso, também foram coletados requisitos com a PRPPG (Pró-Reitoria de Pesquisa e Pós-Graduação), com analistas do NTI e usuários da Secretaria Acadêmica da Universidade. A modelagem destes foi realizada de maneira a tentar atender a todos os Programas de Pós-Graduações Stricto Sensu da universidade, e também, foram criados procedimentos gerais únicos, baseados nos requisitos elicitados e validados com os usuários requerentes e especialistas no domínio da aplicação. 3.1 Resumo do Processo Atual Os processos resumem-se em inscrição, seleção, matrícula, gerência dos processos dos alunos e defesas de qualificação e defesa final. O processo se inicia com a divulgação do edital de abertura do Programa, que define as datas e prazos para as etapas de seleção do candidato. Na sequência, são realizadas as inscrições dos candidatos, os quais comparecem na Coordenação do Programa para a realização da mesma munidos dos documentos necessários para a efetivação da inscrição juntamente com o formulário de inscrição de aluno regular, formulário de carta de apresentação e formulário de anteprojeto de dissertação e tese, respectivamente preenchidos 22

23 (disponíveis no site de cada Programa de Pós-Graduação 5 ). De posse destes documentos, a Coordenação efetua a avaliação do candidato para ingresso no Programa de acordo com pontuações especificadas em itens de avaliação do Programa disponível no site. A Coordenação divulga a pontuação do candidato, referente ao processo de seleção. Os candidatos aprovados são convocados para realizar a matrícula junto a Secretaria Acadêmica da Universidade. Posteriormente, a matrícula é encaminhada a Coordenação para análise e homologação e retorna para a Secretaria Acadêmica. Após a efetivação da matrícula o acadêmico realiza, juntamente com um Orientador estipulado pela Coordenação, o cronograma do projeto e tarefas a serem compridas durante o Curso. A Secretaria Acadêmica tem a função de realizar a matrícula dos acadêmicos e arquivar os documentos recebidos, atender localmente requerimentos, fazer cancelamento de matrícula, emissão dos diários de classe, lançamento de notas e outros. A Coordenação realiza a inscrição, seleção e homologação da matrícula dos candidatos, organização do cronograma do acadêmico e todos os processos posteriores à etapa do processo seletivo do candidato que é a ministração de aulas pelos professores do Programa de Pós-Graduação, e todos os processos que envolvam o candidato até sua formação, passando pela qualificação e dissertação final. O problema vivenciado hoje é a demora na comunicação entre as Coordenações e a Secretaria Acadêmica no encaminhamento de formulários e declarações entre eles. Também a falta de flexibilidade para que os candidatos realizem suas inscrições, as quais são feitas somente presencialmente. Outro fator é o atendimento local de acadêmicos, que sobrecarrega a Secretaria Acadêmica. Neste contexto, propõe-se a construção de um sistema web para atender todos os usuários do sistema e a centralização dos dados em um SGBD (Sistema Gerenciador de Banco de Dados), facilitando o acesso e comunicação por todos os usuários. 3.2 A Solução Proposta O sistema proposto tem por finalidade otimizar a comunicação entre seus usuários, fazendo este um meio onde todos os usuários possam ter acesso centralizado às informações 5 Vide, por exemplo, o site do PGEAGRI: 23

24 do sistema. Uma solução é a implantação de um sistema web para a gerência dos processos das Pós-Graduações Stricto Sensu. A seguir, nas Figuras 5 e 6, são apresentados e detalhados os Requisitos Funcionais e Não-Funcionais do sistema proposto. Também, na Figura 7, os Casos de Uso utilizando o padrão UML (Unified Modeling Language) que facilita a visualização no processo de Engenharia de Requisitos e auxilia em um melhor planejamento do projeto em geral. Os requisitos funcionais de um sistema descrevem diversas funções que a instituição e usuários do sistema almejam que o software ofereça. Nesta primeira parte são descritos os requisitos funcionais do sistema de forma geral, e posteriormente, são detalhados nos Casos de Uso do sistema. O sistema envolve os seguintes tipos de usuário: Coordenação, Secretaria Acadêmica, Acadêmico, PRPPG, Professor, Orientador e Candidato, onde cada um terá um nível de acesso delimitado de acordo com as características que cada usuário necessita para trabalhar no sistema. Quando o requisito é nomeado como gerenciar, refere-se à inclusão, edição, exclusão e pesquisa no sistema. Os requisitos funcionais são listados no Apêndice A. A Figura 5 ilustra os requisitos funcionais do sistema através da técnica i*, utilizando o modelo SD (Modelo de Dependências Estratégicas), onde pode-se visualizar as interações que ocorrem a partir de um ator que tem uma meta e espera um resultado. O diagrama SD ilustra os oito atores do sistema interagindo, o Coordenador, o Sistema, o Orientador, o Acadêmico, o Candidato, a Secretaria Acadêmica, a PRPPG (Pró-Reitoria de Pesquisa e Pós- Graduação) e o Professor. Destes, o Sistema é o ator que gerencia todas as metas. 24

25 Figura 5 - Modelo SD (Dependências Estratégicas) 25

26 Os requisitos não-funcionais referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. O sistema está dividido nos seguintes requisitos não-funcionais: desempenho, segurança, usabilidade e custo. No Apêndice B esses requisitos são listados. A seguir, o Diagrama NFR (Non- Functional Requirements in Software Engineering) ilustra os requisitos não-funcionais. Figura 6 Diagrama de Requisitos Não-Funcionais Os estados marcados com os símbolos de aceitação como ilustra a legenda da figura, serão garantidos ou atendidos na implementação do sistema, já os rejeitados, marcados com um X, talvez não possam ser garantidos na implementação do sistema. O desempenho será garantido pela velocidade da rede, aplicação Java web e sistema gerenciador de banco de dados SQL Server, onde os três itens supracitados estão disponíveis na Universidade. A estrutura de rede hoje disponível na UNIOESTE é nova e já atende adequadamente a outros sistemas em funcionamento. Por se utilizar Java web, o custo do sistema fica reduzido e, como a Universidade já possui licença do SGBD (Sistema Gerenciador de Banco de Dados) SQL Server [23], o seu uso não acarretará custos extras. 26

27 Quanto ao espaço disponível para a aplicação também é garantido pela base de dados SQL Server escalonável. Quanto à segurança, tem-se a disponibilidade, integridade e confidencialidade, que serão todas garantidas. O acesso a qualquer hora é possível pela boa estrutura de rede disponível atualmente juntamente com os novos servidores e o sistema será web, facilitando a disponibilidade da aplicação para vários usuários. Para garantir integridade será utilizado um SGBD SQL Server, concentrando os dados da aplicação em uma única base de dados. Já a confidencialidade será garantida através da autenticação dos usuários que terão acesso ao sistema através de uma senha previamente criptografada. Quanto a usabilidade, o sistema terá interfaces padrões para que o usuário tenha maior facilidade no entendimento dos comandos do sistema. Para o desenvolvimento do sistema, foram elaborados previamente os casos de uso para cada funcionalidade pertencente ao sistema. O caso de uso descreve os passos necessários que os atores necessitam para cumprir uma determinada função no sistema. Os casos de uso são listados no Apêndice C. A seguir, será apresentado o Diagrama de Casos de Uso onde ilustra os atores do sistema com suas respectivas funções. Um Diagrama de Caso de Uso descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. É nele que o cliente vê as principais funcionalidades de seu sistema. Na Figura 7, os bonecos estão representando os atores do sistema, as elipses o caso de uso, e entre o ator e a elipse a uma ligação representando as funções do ator no sistema. 27

28 Figura 7 - Diagrama de Casos de Uso 28

29 Para melhor compreensão de todos estes requisitos, foram elaborados diagramas no padrão BPMN (Business Process Modeling Notation) [24], uma notação da metodologia de gerenciamento de processos de negócio. Trata-se de uma série de ícones para o desenho de processos, o que facilita o entendimento do usuário. A seguir são apresentados os Diagramas de Processos do sistema proposto. Figura 8 - Diagrama de Funções dos Atores do Sistema 29

30 No diagrama apresentado na Figura 8, cada ator tem suas funções específicas e, através de uma gerencia de login pode-se identificar qual o tipo de usuário que está acessando o sistema e disponibilizar as funções que lhe são designadas. Se o estado realizar login for bem sucedido, o usuário tem acesso às funções do sistema. Se o usuário for do tipo PRPPG ele terá acesso às opções de cadastro de Programa, nível, disciplina, área de concentração e linha de pesquisa. Caso seja do tipo Acadêmico terá acesso a consultar nota e frequência em disciplina, realizar plano de estudo, realizar matrícula e matricular-se em disciplina. Caso o usuário seja do tipo Coordenação, terá acesso a cadastro de cronograma, etapa, gerência de inscrições e disciplinas. Se o usuário for do tipo Professor, poderá lançar nota e frequência das disciplinas do Acadêmico. Se for do tipo Orientador, terá acesso a validação do plano de estudo do Acadêmico. E por último, caso o usuário seja do tipo Secretaria Acadêmica, poderá realizar a gerência de matrículas, acompanhar o estado do acadêmico no curso e emitir relatórios e declarações. Para realizar inscrição não é preciso fazer login no sistema e esta opção é realizada apenas pelo usuário Candidato. A seguir, são apresentados diagramas com a especificação das funções dos atores. O diagrama da Figura 9 ilustra a representação da gerência de cronograma e as etapas de cada cronograma que são gerenciadas pelo ator Coordenação. É possível realizar o cadastro, edição, exclusão e pesquisa de cronogramas e para cada cronograma pode-se adicionar etapas, onde cada etapa pode ser cadastrada, editada e excluída. 30

31 Figura 9 - Diagrama de Processo da Gerência de Cronograma e Etapa No diagrama da Figura 10, ilustra a representação da gerência de Programa, nível e disciplina pelo usuário PRPPG. É possível realizar o cadastro, edição, exclusão e pesquisa de programas e para cada Programa pode-se adicionar níveis (mestrado ou doutorado) e disciplinas, podendo também cadastrar, editar e excluir níveis e disciplinas. 31

32 Figura 10 - Diagrama de Processo da Gerência de Programa, Nível e Disciplina No diagrama da Figura 11, é ilustrada a representação da gerência de Área de Concentração e Linha de Pesquisa pelo usuário PRPPG. É possível realizar o cadastro, edição, exclusão e pesquisa de Área de Concentração e, para cada Área de Concentração, pode-se adicionar Linha de Pesquisa, com as opções de cadastrar, editar e excluir Linha de Pesquisa. 32

33 Figura 11 - Diagrama de Processo da Gerência de Áreas e Linha de Pesquisa O diagrama da Figura 12 ilustra a representação da gerência de oferta de disciplinas pelo usuário Coordenação. Seleciona-se um Programa, um nível pertencente ao Programa, um cronograma do nível e uma etapa do tipo matrícula em disciplina. Posteriormente, escolhe-se disciplinas para serem ofertadas e estipula-se o número de vagas. Também pode ser realizada a exclusão de uma oferta de disciplina. Figura 12 - Diagrama de Processo da Gerência de Oferta de Disciplina 33

34 O diagrama da Figura 13 ilustra a representação da gerência de inscrição regular pelo usuário Coordenação e Candidato. Seleciona-se um Programa, um nível pertencente a este, um cronograma do nível e uma etapa do tipo inscrição regular. Posteriormente, no caso do usuário Candidato, é preenchido o formulário com dados solicitados e realizada a inscrição. No caso do usuário Coordenação, seleciona-se um candidato e o classifica ou edita os seus dados cadastrais. Figura 13 - Diagrama de Processo da Gerência das Inscrições Regulares O diagrama da Figura 14 traz a representação da gerência de inscrição especial pelo usuário Coordenação e Candidato. Seleciona-se um Programa, um nível, um cronograma do nível e uma etapa do tipo inscrição especial. Posteriormente, no caso do usuário Candidato, preenche-se o formulário com dados solicitados e realiza a inscrição. No caso do usuário Coordenação, seleciona-se um candidato e o classifica ou edita seus dados cadastrais. 34

35 Figura 14 - Diagrama de Processo da Gerência das Inscrições Especiais No diagrama da Figura 15, a representação da matrícula em disciplina pelo usuário Acadêmico é apresentada. Seleciona-se um cronograma e o Acadêmico efetua matricula em uma disciplina. Também é possível fazer o cancelamento da matrícula. Figura 15 - Diagrama de Processo da Gerência Matrícula em Disciplina No diagrama da Figura 16, a representação do lançamento de notas e frequência pelo usuário Professor é exibida. Seleciona-se uma disciplina ofertada, após, um Acadêmico nela matriculado e faz-se o lançamento da nota e frequência. 35

36 Figura 16 - Diagrama de Processo do Lançamento de Notas e Frequência O próximo capítulo abarca uma descrição de como o sistema foi planejado e implementado, explicitando algumas decisões de projeto, além das tecnologias utilizadas para a implementação de parte dos requisitos documentados. Aborda também a descrição da proposta inicial de um módulo OLAP integrado ao sistema. 36

37 Capítulo 4 Estrutura do Sistema Com o aumento da complexidade das aplicações, torna-se relevante a separação entre os dados e a apresentação das aplicações, de forma que alterações feitas no layout não afetem a manipulação de dados, o que se torna possível dividindo a implementação em camadas. Estas camadas do sistema serão abordadas em tópicos para sua melhor divisão e compreensão. Também nesse capítulo, há a descrição do módulo OLAP integrado ao sistema. A Figura 17 ilustra as camadas do sistema. A primeira é a camada de dados, onde está a base de dados. Já a camada intermediária, a camada de aplicação, concentra-se as regras de negócio do sistema, fazendo a comunicação entre as solicitações da camada de apresentação e busca de informações na camada de dados. A terceira camada, de apresentação, comporta as interfaces gráficas do sistema, ou seja, o nível de interação com o usuário final com o sistema. Figura 17 - Camadas do Sistema A título de ilustração a Figura 18 apresenta um Diagrama de Classes (parcial) do sistema, demonstrando que o seu desenvolvimento foi estruturado em camadas, divididas em pacotes. 37

38 Figura 18 - Diagrama de Classe organizado em camadas e pacotes do sistema 38

39 No Diagrama de Casses da Figura 18 estão representados os pacotes, separando fisicamente os códigos-fonte de cada camada. Cada pacote comporta as suas respectivas classes. Este diagrama de classes ilustra um subconjunto de classes do projeto completo, pois neste há a representação de somente dois tipos de objetos, o objeto Programa e Cronograma, onde um Programa pode conter diversos Cronogramas por meio do relacionamento um para muitos representado no diagrama. O pacote Model, armazena todas as representações orientadas a objeto das tabelas do Modelo Relacional, em seguida, no pacote Dao, é armazenada toda a lógica de acesso a base de dados, como consultas de inserção, edição, exclusão e pesquisa de dados. As classes do pacote Dao, estendem a classe GenericDao, do pacote Sharedev, fazendo com que a classes do pacote Dao, contenham os métodos da classe GenercDao. O pacote Controller, diz quais métodos estão disponíveis para acesso da interface gráfica, que está representada através dos pacotes Tela de Cadastro e Tela de Pesquisa, onde cada classe destes pacotes estendem de classes do pacote Util, que são componentes de interface gráfica que podem ser reaproveitados através da extensão. A construção do software baseou-se nos casos de uso. Foram implementados os casos de uso de 1 a 37, de 73 a 90, 107 e 108. A seguir, é dada a descrição das camadas do sistema. 4.1 Camada de Dados A camada de dados é usada para definir e gerenciar o domínio da informação e notificar observadores sobre mudanças nos dados. Ele é uma representação detalhada da informação que a aplicação opera. Utilizou-se para o mapeamento do projeto uma estrutura de base de dados relacional, o MR (Modelo Relacional), que traz em sua modelagem a view, uma maneira alternativa de observação de dados de uma ou mais entidades, e que está sendo utilizada para acesso a informações de outras bases de dados como a tabela Pessoa Física que está localizada em outra base de dados, necessitando assim uma view da tabela Pessoa Física para acesso às informações da mesma. Com isso, consegue-se acesso às tabelas das bases de dados da Universidade, quando necessário. A Figura 19 exibe o MR representando a lógica relacional do SGBD, com suas tabelas e ligações entre elas, fazendo as regras de cardinalidade, que são tratadas pelo SGBD na 39

40 forma de chaves primárias e estrangeiras. As tabelas representadas como view estão destacadas em tom de cinza no diagrama. Este modelo relacional foi criado fisicamente no SQL Server, SGBD adotado pela Universidade. Camadas de mapeamento objeto-relacionais são alternativas bastante utilizadas quando da utilização de SGBDs Relacionais em aplicações orientadas a objetos. Como a camada de aplicação utiliza linguagem de programação orientada a objetos, optou-se por utilizar o framework hibernate [27] para o mapeamento das tabelas da base de dados para a camada de aplicação de forma a trabalhar com orientação a objetos na camada de aplicação e, também, com a separação da camada de dados com a de aplicação. 40

41 Figura 19 - Diagrama Relacional 41

42 4.2 Camada de Aplicação É na camada de aplicação que as regras de negócio são inseridas e tratadas. Esta camada se comunica com a camada de apresentação e de dados. Faz a comunicação entre uma solicitação da camada de apresentação, acessa a informação na camada de dado e retorna o objeto para a camada solicitante. Para esta comunicação utiliza-se o VRaptor [26], um framework que faz a comunicação entre a camada de aplicação e apresentação. Tarefas como salvar, remover, buscar e atualizar ou ainda, funcionalidades que costumam ser mais complexas como upload e download de arquivos, resultados em formatos diferentes (xml, json, xhtml, etc), são feitas através de funcionalidades do VRaptor, que encapsulam classes HttpServletRequest, Response, Session e toda a API do javax.servlet, facilitando a chamada de métodos e a interceptação dos mesmos. As classes com o rótulo Controller em seu nome contém a lógica de negócio do sistema. A Figura 20 traz um exemplo de uma classe na camada de aplicação utilizando o VRaptor. 42

43 Figura 20 - Modelo de Classe da Camada de Aplicação A Figura 20 mostra que o VRaptor faz várias associações para as URI (Uniform Resource Identifier) e, por padrão, a chamada /Programa/adiciona(parâmetro) irá invocar o método adiciona() da classe ProgramaController, passando por parâmetro no método o objeto Programa. Desta forma, VRaptor auxilia a comunicação entre as camadas do sistema, fazendo a interação entre elas. 4.3 Camada de Apresentação Esta camada é onde se implementa a visão do sistema, onde o usuário final poderá interagir com o software. Para apoiar este desenvolvimento utiliza-se o framework Ext JS 6, baseado em JavaScript com componentes para interfaces gráficas. Uma vantagem do Ext JS é 6 43

44 como está organizada sua estrutura, podendo facilmente estender um componente padrão para atender às necessidades e extensões. Na Figura 21 é ilustrado um exemplo de como são organizados os componentes do Ext JS. A estrutura funciona da seguinte forma: Panel estende Component e Tab Panel estende Panel e assim, consecutivamente. Desta forma, pode-se criar outros componentes e estender de qualquer outro Componente da biblioteca Ext JS. Figura 21 - Arquitetura dos Componentes Ext JS Ext JS conta com uma interface rica, trazendo para o usuário final requisitos nãofuncionais como a usabilidade. A Figura 22 exibe a página principal do sistema desenvolvido. Figura 22 - Página principal do sistema 44

45 Através da página principal do sistema, pode-se acessar o módulo OLAP (explicado a seguir), abrindo uma nova janela no browser do usuário. 4.4 Módulo OLAP O módulo OLAP iniciado tem por objetivo disponibilizar ao usuário final acesso as informações da base de dados para construir relatórios capazes de responder ou apoiar a suas questões gerenciais e proporcionando condições de análise para auxiliar a tomada de decisão. Traz a dinâmica de poder filtrar dados e dá a possibilidade da observação em múltiplas dimensões. No contexto do sistema em questão, a tomada de decisão está centrada na análise das disciplinas matriculadas pelos acadêmicos, viabilizando análise da situação do acadêmico perante a nota e frequência na disciplina, realizando filtros por Programas e níveis. Um exemplo de análise poderia ser a comparação do conceito do Programa em um determinado período com as notas em disciplinas de seus alunos no mesmo período. A base de dados comporta a modelagem star schema, onde terão seus dados carregados pela modelagem relacional do sistema através de ferramentas ETL, responsável pela carga inicial e pelas atualizações periódicas dos dados no data warehouse, sendo que a periodicidade das atualizações deverá considerar o volume de dados e de processamento envolvido. Esta modelagem se constitui basicamente de dois tipos de tabela, fato e dimensão, categorizando o esquema estrela. Como mencionado no Capítulo 2, no star schema a representação do modelo dimensional é em bancos de dados relacionais. Neste esquema existe uma tabela dominante no centro do esquema, a tabela fato. Esta é a única tabela com múltiplos relacionamentos para as outras tabelas. As outras tabelas possuem um único relacionamento para a tabela central, e são as tabelas que caracterizam as dimensões. A Figura 23 ilustra o star schema do sistema proposto. 45

46 Figura 23 - Star Schema do Sistema Proposto A Figura 23 apresenta a tabela fato PerfilAcademico com suas medidas MediaNotas e MediaFrequencia. Traz também, chaves estrangeiras, que são os relacionamentos entre as tabelas dimensões. As dimensões Acadêmico, Disciplina e Programa contêm os dados da base de dados relacional. Para a importação dos dados para esta estrutura, utilizou-se da ferramenta Kettle [25] pertencente ao pacote Pentaho, com a qual se pode realizar diversas regras em SQL para a busca de informações na base de dados relacional e a persistência dos dados no modelo star schema. Neste caso, as importações foram realizadas de uma base de dados relacional, necessitando somente o carregamento dos dados para o modelo estrela. Este é apenas um caso pequeno, mostrando como é possível realizar a montagem da base dos cubos e o carregamento de dados do Modelo Relacional para o star schema. Contudo futuramente o sistema poderá haver vários cubos (cenários), cada um representando um data mart. Para trabalhar com um modelo de dados customizado no Pentaho é necessário criar um arquivo de configuração do Cubo para o servidor de aplicação Mondrian, chamado Mondrian Cube Schema File, que conterá as definições do cubo OLAP. Este arquivo descreve as estruturas das dimensões, hierarquias e fato, e os mapeia com o modelo relacional. 46

47 O Mondrian Cube Schema é um arquivo XML, que pode ser criado manualmente. Porém, por esta tarefa ser demorada, recomenda-se a utilização de uma ferramenta para isto, como a Mondrian Schema Workbench, que permite criar e testar o mapeamento de um cubo visualmente. O motor do Mondrian é o responsável por processar consultas MDX baseandose no modelo do arquivo Mondrian Cube Schema gerado pelo Mondrian Schema Workbench. A comunicação entre as camadas do módulo OLAP se faz por meio de consultas MDX, onde o servidor Mondrian se encarrega de interpretá-las, carregar os dados da base star schema e encaminha-las para a camada de apresentação. O módulo OLAP é responsável por comunicar-se com a base de dados do data warehouse e disponibilizar ao usuário final a dinamicidade de manipulação dos dados histórico do sistema. Para isso, é necessário, metadados e ferramentas de acesso aos dados, possibilitando consultas ad hoc e relatórios específicos. Consultas ad hoc são consultas circunstanciais, não programadas, pertinentes a um determinado momento da análise. Para alcançar este objetivo utilizou-se a ferramenta JPalo, responsável pela comunicação com o servidor Mondrian do Pentaho e a interpretação das consultas multidimensionais MDX para apresentar na interface gráfica as dimensões e funcionalidade de manipulação das dimensões. A Figura 24 ilustra a interface do JPalo. Figura 24 - Interface JPalo para o Cubo 47

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE

TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE TÓPICOS AVANÇADOS EM ENGENHARIA DE SOFTWARE Engenharia de Computação Professor: Rosalvo Ferreira de Oliveira Neto OLPT x OLAP Roteiro OLTP Datawarehouse OLAP Operações OLAP Exemplo com Mondrian e Jpivot

Leia mais

Uma Ferramenta Web para BI focada no Gestor de Informação

Uma Ferramenta Web para BI focada no Gestor de Informação Uma Ferramenta Web para BI focada no Gestor de Informação Mikael de Souza Fernandes 1, Gustavo Zanini Kantorski 12 mikael@cpd.ufsm.br, gustavoz@cpd.ufsm.br 1 Curso de Sistemas de Informação, Universidade

Leia mais

Sistemas de Apoio à Decisão (SAD) - Senado

Sistemas de Apoio à Decisão (SAD) - Senado Sistemas de Apoio à Decisão (SAD) - Senado DW OLAP BI Ilka Kawashita Material preparado :Prof. Marcio Vitorino Sumário OLAP Data Warehouse (DW/ETL) Modelagem Multidimensional Data Mining BI - Business

Leia mais

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3.

Aplicação A. Aplicação B. Aplicação C. Aplicação D. Aplicação E. Aplicação F. Aplicação A REL 1 REL 2. Aplicação B REL 3. Sumário Data Warehouse Modelagem Multidimensional. Data Mining BI - Business Inteligence. 1 2 Introdução Aplicações do negócio: constituem as aplicações que dão suporte ao dia a dia do negócio da empresa,

Leia mais

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br

Data Warehousing. Leonardo da Silva Leandro. CIn.ufpe.br Data Warehousing Leonardo da Silva Leandro Agenda Conceito Elementos básicos de um DW Arquitetura do DW Top-Down Bottom-Up Distribuído Modelo de Dados Estrela Snowflake Aplicação Conceito Em português:

Leia mais

Chapter 3. Análise de Negócios e Visualização de Dados

Chapter 3. Análise de Negócios e Visualização de Dados Chapter 3 Análise de Negócios e Visualização de Dados Objetivos de Aprendizado Descrever a análise de negócios (BA) e sua importância par as organizações Listar e descrever brevemente os principais métodos

Leia mais

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos

Data Warehouses. Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Data Warehouses Alunos: Diego Antônio Cotta Silveira Filipe Augusto Rodrigues Nepomuceno Marcos Bastos Silva Roger Rezende Ribeiro Santos Conceitos Básicos Data Warehouse(DW) Banco de Dados voltado para

Leia mais

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.

SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4. SUMÁRIO 1. INTRODUÇÃO... 2 2. O QUE É DATA WAREHOUSE?... 2 3. O QUE DATA WAREHOUSE NÃO É... 4 4. IMPORTANTE SABER SOBRE DATA WAREHOUSE... 5 4.1 Armazenamento... 5 4.2 Modelagem... 6 4.3 Metadado... 6 4.4

Leia mais

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP.

DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. DESENVOLVIMENTO DE PLUG-INS KETTLE PARA GERAÇÃO DE MONDRIAN SCHEMA A PARTIR DE BASES RELACIONAIS, UTILIZANDO A METODOLOGIA AGILE ROLAP. Eduardo Cristovo de Freitas Aguiar (PIBIC/CNPq), André Luís Andrade

Leia mais

Banco de Dados - Senado

Banco de Dados - Senado Banco de Dados - Senado Exercícios OLAP - CESPE Material preparado: Prof. Marcio Vitorino OLAP Material preparado: Prof. Marcio Vitorino Soluções MOLAP promovem maior independência de fornecedores de SGBDs

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago

DATA WAREHOUSE. Rafael Ervin Hass Raphael Laércio Zago DATA WAREHOUSE Rafael Ervin Hass Raphael Laércio Zago Roteiro Introdução Aplicações Arquitetura Características Desenvolvimento Estudo de Caso Conclusão Introdução O conceito de "data warehousing" data

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

Business Intelligence e ferramentas de suporte

Business Intelligence e ferramentas de suporte O modelo apresentado na figura procura enfatizar dois aspectos: o primeiro é sobre os aplicativos que cobrem os sistemas que são executados baseados no conhecimento do negócio; sendo assim, o SCM faz o

Leia mais

Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar

Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar Uma Ferramenta WEB para apoio à Decisão em Ambiente Hospitalar Mikael de Souza Fernandes 1, Gustavo Zanini Kantorski 12 mikael@cpd.ufsm.br, gustavoz@cpd.ufsm.br 1 Curso de Sistemas de Informação, Universidade

Leia mais

Palavras-chave: On-line Analytical Processing, Data Warehouse, Web mining.

Palavras-chave: On-line Analytical Processing, Data Warehouse, Web mining. BUSINESS INTELLIGENCE COM DADOS EXTRAÍDOS DO FACEBOOK UTILIZANDO A SUÍTE PENTAHO Francy H. Silva de Almeida 1 ; Maycon Henrique Trindade 2 ; Everton Castelão Tetila 3 UFGD/FACET Caixa Postal 364, 79.804-970

Leia mais

OLAP: Características, Arquitetura e Ferramentas

OLAP: Características, Arquitetura e Ferramentas INSTITUTO VIANNA JÚNIOR FACULDADES INTEGRADAS VIANNA JÚNIOR OLAP: Características, Arquitetura e Ferramentas Erika Maria Teixeira Araújo 1 Mônica de Lourdes Souza Batista 2 Teresinha Moreira de Magalhães

Leia mais

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹

Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ Data Warehouse. Djenane Cristina Silveira dos Santos¹, Felipe Gomes do Prado¹, José Justino Neto¹, Márcia Taliene Alves de Paiva¹ ¹Ciência da Computação Universidade Federal de Itajubá (UNIFEI) MG Brasil

Leia mais

Módulo 4. Construindo uma solução OLAP

Módulo 4. Construindo uma solução OLAP Módulo 4. Construindo uma solução OLAP Objetivos Diferenciar as diversas formas de armazenamento Compreender o que é e como definir a porcentagem de agregação Conhecer a possibilidade da utilização de

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

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS

Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Processo Decisório, OLAP e Relatórios Corporativos OLAP E RELATÓRIOS CORPORATIVOS Sumário Conceitos/Autores chave... 3 1. Introdução... 5 2. OLAP... 6 3. Operações em OLAP... 8 4. Arquiteturas em OLAP...

Leia mais

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO

FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO @ribeirord FUNDAMENTOS DE SISTEMAS DE INFORMAÇÃO Rafael D. Ribeiro, M.Sc,PMP. rafaeldiasribeiro@gmail.com http://www.rafaeldiasribeiro.com.br Lembrando... Aula 4 1 Lembrando... Aula 4 Sistemas de apoio

Leia mais

Prova INSS RJ - 2007 cargo: Fiscal de Rendas

Prova INSS RJ - 2007 cargo: Fiscal de Rendas Prova INSS RJ - 2007 cargo: Fiscal de Rendas Material de Apoio de Informática - Prof(a) Ana Lucia 53. Uma rede de microcomputadores acessa os recursos da Internet e utiliza o endereço IP 138.159.0.0/16,

Leia mais

ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO

ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE ENGENHARIA DE SISTEMAS RACHEL TEREZA MENEGAZZO IMPLEMENTANDO UMA SOLUÇÃO OLAP UTILIZANDO SOFTWARE LIVRE CURITIBA PR 2009 RACHEL TEREZA MENEGAZZO IMPLEMENANDO

Leia mais

Planejamento Estratégico de TI. Prof.: Fernando Ascani

Planejamento Estratégico de TI. Prof.: Fernando Ascani Planejamento Estratégico de TI Prof.: Fernando Ascani Data Warehouse - Conceitos Hoje em dia uma organização precisa utilizar toda informação disponível para criar e manter vantagem competitiva. Sai na

Leia mais

DATA WAREHOUSE. Introdução

DATA WAREHOUSE. Introdução DATA WAREHOUSE Introdução O grande crescimento do ambiente de negócios, médias e grandes empresas armazenam também um alto volume de informações, onde que juntamente com a tecnologia da informação, a correta

Leia mais

Módulo 2. Definindo Soluções OLAP

Módulo 2. Definindo Soluções OLAP Módulo 2. Definindo Soluções OLAP Objetivos Ao finalizar este módulo o participante: Recordará os conceitos básicos de um sistema OLTP com seus exemplos. Compreenderá as características de um Data Warehouse

Leia mais

Data Warehouse Processos e Arquitetura

Data Warehouse Processos e Arquitetura Data Warehouse - definições: Coleção de dados orientada a assunto, integrada, não volátil e variável em relação ao tempo, que tem por objetivo dar apoio aos processos de tomada de decisão (Inmon, 1997)

Leia mais

PENTAHO. História e Apresentação

PENTAHO. História e Apresentação PÓS-GRADUAÇÃO LATO SENSU Curso: Banco de Dados Disciplina: Laboratório de Data Warehouse e Business Intelligence Professor: Fernando Zaidan Unidade 2 2012 Crédito dos Slides: Clever Junior 2 PENTAHO História

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

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

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso

5 Estudo de Caso. 5.1. Material selecionado para o estudo de caso 5 Estudo de Caso De modo a ilustrar a estruturação e representação de conteúdos educacionais segundo a proposta apresentada nesta tese, neste capítulo apresentamos um estudo de caso que apresenta, para

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Introdução a Data Warehousing e OLAP Introdução a Data Warehouse e Modelagem Dimensional Visão

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Uma aplicação de Data Warehouse para apoiar negócios

Uma aplicação de Data Warehouse para apoiar negócios Uma aplicação de Data Warehouse para apoiar negócios André Vinicius Gouvêa Monteiro Marcos Paulo Oliveira Pinto Rosa Maria E. Moreira da Costa Universidade do Estado do Rio de Janeiro - UERJ IME - Dept

Leia mais

Data Warehousing Visão Geral do Processo

Data Warehousing Visão Geral do Processo Data Warehousing Visão Geral do Processo Organizações continuamente coletam dados, informações e conhecimento em níveis cada vez maiores,, e os armazenam em sistemas informatizados O número de usuários

Leia mais

Data Warehouses Uma Introdução

Data Warehouses Uma Introdução Data Warehouses Uma Introdução Alex dos Santos Vieira, Renaldy Pereira Sousa, Ronaldo Ribeiro Goldschmidt 1. Motivação e Conceitos Básicos Com o advento da globalização, a competitividade entre as empresas

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

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

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados SISTEMA DE BANCO DE DADOS Banco e Modelagem de dados Sumário Conceitos/Autores chave... 3 1. Introdução... 4 2. Arquiteturas de um Sistema Gerenciador... 5 3. Componentes de um Sistema... 8 4. Vantagens

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

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional

OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional OLAP em âmbito hospitalar: Transformação de dados de enfermagem para análise multidimensional João Silva and José Saias m5672@alunos.uevora.pt, jsaias@di.uevora.pt Mestrado em Engenharia Informática, Universidade

Leia mais

Curso Data warehouse e Business Intelligence

Curso Data warehouse e Business Intelligence Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Analysis Services. Manual Básico

Analysis Services. Manual Básico Analysis Services Manual Básico Construindo um Banco de Dados OLAP... 2 Criando a origem de dados... 3 Definindo as dimensões... 5 Níveis de dimensão e membros... 8 Construindo o cubo... 11 Tabela de fatos...12

Leia mais

IMPLANTAÇÃO DO DW NA ANVISA

IMPLANTAÇÃO DO DW NA ANVISA IMPLANTAÇÃO DO DW NA ANVISA Bruno Nascimento de Ávila 1 Rodrigo Vitorino Moravia 2 Maria Renata Furtado 3 Viviane Rodrigues Silva 4 RESUMO A tecnologia de Business Intelligenge (BI) ou Inteligência de

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

Fundamentos da Análise Multidimensional

Fundamentos da Análise Multidimensional Universidade Técnica de Lisboa INSTITUTO SUPERIOR DE ECONOMIA E GESTÃO Informática e Sistemas de Informação Aplicados em Economia Fundamentos da Análise Multidimensional Fundamentos da Análise Multidimensional

Leia mais

Thiago Locatelli de OLIVEIRA, Thaynara de Assis Machado de JESUS; Fernando José BRAZ Bolsistas CNPq; Orientador IFC Campus Araquari

Thiago Locatelli de OLIVEIRA, Thaynara de Assis Machado de JESUS; Fernando José BRAZ Bolsistas CNPq; Orientador IFC Campus Araquari DESENVOLVIMENTO DE AMBIENTE PARA A GESTÃO DO CONHECIMENTO RELACIONADO AOS DADOS PRODUZIDOS PELO SISTEMA DE GERENCIAMENTO DE TRANSITO DA CIDADE DE JOINVILLE/SC PARTE I Thiago Locatelli de OLIVEIRA, Thaynara

Leia mais

DMS Documento de Modelagem de Sistema. Versão: 1.4

DMS Documento de Modelagem de Sistema. Versão: 1.4 DMS Documento de Modelagem de Sistema Versão: 1.4 VERANEIO Gibson Macedo Denis Carvalho Matheus Pedro Ingrid Cavalcanti Rafael Ribeiro Tabela de Revisões Versão Principais Autores da Versão Data de Término

Leia mais

Processo de Engenharia de Software II

Processo de Engenharia de Software II UNIOESTE Universidade Estadual do Oeste do Paraná 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 de Software

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

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

Banco de Dados I Ementa:

Banco de Dados I Ementa: Banco de Dados I Ementa: Banco de Dados Sistema Gerenciador de Banco de Dados Usuários de um Banco de Dados Etapas de Modelagem, Projeto e Implementação de BD O Administrador de Dados e o Administrador

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

ADMINISTRAÇÃO DOS RECURSOS DE DADOS

ADMINISTRAÇÃO DOS RECURSOS DE DADOS Capítulo 7 ADMINISTRAÇÃO DOS RECURSOS DE DADOS 7.1 2003 by Prentice Hall OBJETIVOS Por que as empresas sentem dificuldades para descobrir que tipo de informação precisam ter em seus sistemas de informação?

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

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado)

UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE CIÊNCIAS DA COMPUTAÇÃO (Bacharelado) SISTEMA INTERNO INTEGRADO PARA CONTROLE DE TAREFAS INTERNAS DE UMA EMPRESA DE DESENVOLVIMENTO

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence

Resumo dos principais conceitos. Resumo dos principais conceitos. Business Intelligence. Business Intelligence É um conjunto de conceitos e metodologias que, fazem uso de acontecimentos e sistemas e apoiam a tomada de decisões. Utilização de várias fontes de informação para se definir estratégias de competividade

Leia mais

IBM Cognos Business Intelligence Scorecarding

IBM Cognos Business Intelligence Scorecarding IBM Cognos Business Intelligence Scorecarding Unindo a estratégia às operações com sucesso Visão Geral O Scorecarding oferece uma abordagem comprovada para comunicar a estratégia de negócios por toda a

Leia mais

FACULDADE DE BALSAS CURSO DE SISTEMAS DE INFORMAÇÃO

FACULDADE DE BALSAS CURSO DE SISTEMAS DE INFORMAÇÃO FACULDADE DE BALSAS CURSO DE SISTEMAS DE INFORMAÇÃO CRIAÇÃO DE UM AMBIENTE DE EXPLORAÇÃO OLAP PARA ANALISAR DADOS DAS VENDAS DO GRUPO DE POSTOS DE COMBUSTÍVEIS PIONEIRO CAIRO DA SILVA BORGES BALSAS (MA)

Leia mais

SAD orientado a DADOS

SAD orientado a DADOS Universidade do Contestado Campus Concórdia Curso de Sistemas de Informação Prof.: Maico Petry SAD orientado a DADOS DISCIPLINA: Sistemas de Apoio a Decisão SAD orientado a dados Utilizam grandes repositórios

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

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

CENTRO UNIVERSITÁRIO FEEVALE EDMILSON J. W. FELBER

CENTRO UNIVERSITÁRIO FEEVALE EDMILSON J. W. FELBER CENTRO UNIVERSITÁRIO FEEVALE EDMILSON J. W. FELBER PROPOSTA DE UMA FERRAMENTA OLAP EM UM DATA MART COMERCIAL: UMA APLICAÇÃO PRÁTICA NA INDÚSTRIA CALÇADISTA Novo Hamburgo, novembro de 2005. EDMILSON J.

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

Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar

Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar Projeto de Data Warehousing sobre Informações em Saúde para dar Suporte a Análise de Faturamento Hospitalar Newton Shydeo Brandão Miyoshi Joaquim Cezar Felipe Grupo de Informática Biomédica Departamento

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

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

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

DELEGAÇÃO REGIONAL DO ALENTEJO CENTRO DE FORMAÇÃO PROFISSIONAL DE ÉVORA REFLEXÃO 4

DELEGAÇÃO REGIONAL DO ALENTEJO CENTRO DE FORMAÇÃO PROFISSIONAL DE ÉVORA REFLEXÃO 4 REFLEXÃO 4 Módulos 0776, 0780, 0781, 0786 e 0787 1/10 8-04-2013 Esta reflexão tem como objectivo partilhar e dar a conhecer o que aprendi nos módulos 0776 - Sistema de informação da empresa, 0780 - Aplicações

Leia mais

4 Aplicação da Sistemática

4 Aplicação da Sistemática 4 Aplicação da Sistemática Este capítulo descreve a aplicação da sistemática definida no Capítulo 3 utilizando dados reais de uma estatística pública e aplicando tecnologias avançadas fazendo o uso de

Leia mais

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE NoSQL Banco de Dados Não Relacional ALUNO: Heitor Oliveira Silva PROFESSOR ORIENTADOR:

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

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

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse

Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Sistemas de Informação Aplicados a AgroIndústria Utilizando DataWarehouse/DataWebhouse Prof. Dr. Oscar Dalfovo Universidade Regional de Blumenau - FURB, Blumenau, Brasil dalfovo@furb.br Prof. Dr. Juarez

Leia mais

Diferenças entre Sistemas Gerenciadores de Banco de Dados para GIS - SGBDs

Diferenças entre Sistemas Gerenciadores de Banco de Dados para GIS - SGBDs Diferenças entre Sistemas Gerenciadores de Banco de Dados para GIS - SGBDs O objetivo deste documento é fazer uma revisão bibliográfica para elucidar as principais diferenças entre os SGBDs, apontando

Leia mais

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence

Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence. Business Intelligence Juntamente com o desenvolvimento desses aplicativos surgiram os problemas: & Data Warehouse July Any Rizzo Oswaldo Filho Década de 70: alguns produtos de BI Intensa e exaustiva programação Informação em

Leia mais

e-business A IBM definiu e-business como: GLOSSÁRIO

e-business A IBM definiu e-business como: GLOSSÁRIO Através do estudo dos sistemas do tipo ERP, foi possível verificar a natureza integradora, abrangente e operacional desta modalidade de sistema. Contudo, faz-se necessário compreender que estas soluções

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

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

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I CONCEITOS BÁSICOS 1. Conceitos básicos de BD, SBD e SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

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

TERMO DE REFERÊNCIA TÍTULO: Termo de Referência para contratação de ferramenta case de AD. GECOQ Gerência de Controle e Qualidade 1/9

TERMO DE REFERÊNCIA TÍTULO: Termo de Referência para contratação de ferramenta case de AD. GECOQ Gerência de Controle e Qualidade 1/9 TÍTULO: ASSUNTO: GESTOR: TERMO DE REFERÊNCIA Termo de Referência para contratação de ferramenta case de AD DITEC/GECOQ Gerência de Controle e Qualidade ELABORAÇÃO: PERÍODO: GECOQ Gerência de Controle e

Leia mais

Quem estiver interessado favor mandar currículo para sabrina.rodrigues@neogrid.com. As vagas são as seguintes: *Analista de BI (2 vagas)*

Quem estiver interessado favor mandar currículo para sabrina.rodrigues@neogrid.com. As vagas são as seguintes: *Analista de BI (2 vagas)* Quem estiver interessado favor mandar currículo para sabrina.rodrigues@neogrid.com. As vagas são as seguintes: *Analista de BI (2 vagas)* Buscamos candidatos com interesse e experiência na área de desenvolvimento,

Leia mais

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura

Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Curso Data warehouse e Business Intelligence Fundamentos, Metodologia e Arquitetura Apresentação Os projetos de Data Warehouse e Business Intelligence são dos mais interessantes e complexos de desenvolver

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

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

Contrata Consultor na modalidade Produto

Contrata Consultor na modalidade Produto Contrata Consultor na modalidade Produto PROJETO 914BRA/1123 FNDE -EDITAL Nº 01/2009 1. Perfil: Consultor ESPECIALISTA EM PLANO DE METAS ANALISTA PROGRAMADOR DELPHI - Código 1 - CGETI. 2. Nº de vagas:

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

Documento de Visão do Projeto

Documento de Visão do Projeto Documento de Visão do Projeto 1. Objetivo O propósito deste documento é coletar, analisar e definir as necessidades de alto-nível e características do projeto de software do Módulo Editor de Estruturas

Leia mais

Arquitetura de Banco de Dados

Arquitetura de Banco de Dados Arquitetura de Banco de Dados Daniela Barreiro Claro MAT A60 DCC/IM/UFBA Arquitetura de Banco de dados Final de 1972, ANSI/X3/SPARC estabeleceram o relatório final do STUDY GROUP Objetivos do Study Group

Leia mais