Orientador: Antônio Cláudio Gómez de Sousa Projeto (graduação) UFRJ/POLI/Departamento de Eletrônica e de Computação COPPE, 2013.

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

Download "Orientador: Antônio Cláudio Gómez de Sousa Projeto (graduação) UFRJ/POLI/Departamento de Eletrônica e de Computação COPPE, 2013."

Transcrição

1

2 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Escola Politécnica Departamento de Eletrônica e de Computação Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária. Rio de Janeiro RJ CEP Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento. É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência bibliográfica completa. Os conceitos expressos neste trabalho são de responsabilidade do autor e do orientador. 1

3 Magalhães, Pedro da Silveira Framework de ETL (Extração-Transformação-Carga) utilizando processamento em paralelo por técnica de pipeline / Pedro da Silveira Magalhães Rio de Janeiro: UFRJ/POLI- COPPE, XI, 42 p.: il.; 29,7 cm. Orientador: Antônio Cláudio Gómez de Sousa Projeto (graduação) UFRJ/POLI/Departamento de Eletrônica e de Computação COPPE, Referências Bibliográficas: p [Extração]. 2. [Transformação]. 3. [Carga]. 4. [ETL]. I. de Souza, Antônio Cláudio Gómez. II. Universidade Federal do Rio de Janeiro, Poli/COPPE. III. Título. 2

4 DEDICATÓRIA graduação. Dedico este trabalho a minha família que esteve presente em toda minha 3

5 AGRADECIMENTO Agradeço ao professor Antônio Cláudio Gomez por ter me orientado durante o Projeto de Graduação. Agradeço também a empresa Stone Age por ter me dado a liberdade de muitas vezes abdicar do trabalho colocando sempre a formação do profissional a frente. 4

6 RESUMO Projeto de Graduação apresentado à Escola Politécnica/COPPE/UFRJ como parte dos requisitos necessários para a obtenção do grau de Engenheiro de Computação e Informação. FRAMEWORK DE ETL (EXTRAÇÃO-TRANSFORMAÇÃO-CARGA) UTILIZANDO PROCESSAMENTO PARALELO POR TÉCNICA DE PIPELINE. Pedro da Silveira Magalhães Março/2013 Orientador: Antônio Cláudio Gómez de Sousa Curso: Engenharia de Computação e Informação Um ciclo de ETL (extract, transform e load), refere-se a um processo no domínio de banco de dados muito utilizado em sistemas de Data Warehouse. Esse ciclo envolve três etapas distintas: a extração de dados de fontes, transformação dos dados e a carga no sistema alvo. Um ciclo ETL pode ser consideravelmente complexo e problemas podem ocorrer quando esses processos são modelados de maneira incorreta. Na maioria das vezes os dados advindos do sistema transacional são de baixa qualidade, apresentando problemas como: domínio de dados mal definidos, erros de digitação, heterogeneidade das fontes de dados envolvidas, etc. Para lidar com esses desafios e complexidade, as empresas estão cada vez mais investindo em ferramentas de ETL, ao invés de criar seus processos a partir do zero. Ao utilizar um ferramental de apoio, as chances de sucesso aumentam, pois permitem auto documentação, visualização do fluxo de dados, reutilização de componentes, design estruturado e padronizado, desempenho e consequentemente maior produtividade e qualidade. O objetivo do projeto é criar um framework capaz de apoiar o processo de construção/execução de um ciclo ETL entregando os benefícios anteriormente citados. 5

7 Palavras-Chave: Extração, Transformação, Carga, Data Warehouse, ETL 6

8 ABSTRACT Undergraduate Project presented to POLI/COPPE/UFRJ as a partial fulfillment of requirements for the degree of Computer and Information Engineer. ETL Framework using parallel processing by pipeline technique. Pedro da Silveira Magalhães March/2013 Advisor: Antônio Cláudio Gómez de Sousa Course: Computer and Information Engineering ETL cycle (extraction, transform and load), refers to a process in the context of database systems widely used in the Data Warehouse. This cycle involves three distinct steps: data sources extraction, data transformation and load on the target system. ETL cycle can be considerably complex and problems may occur when these processes are modeled incorrectly. Most often the data from the transactional system are of low quality, presenting problems as: the data poorly defined, typing errors, heterogeneity of data sources involved, etc.. To deal with these challenges and complexity, companies are increasingly investing in ETL tools instead of creating their processes from scratch. When using supporting tools, the chances of success increase because they allow self documentation, visualization of data flow, component reuse, structured and standardized design, better performance, higher productivity and quality. The project goal is to create a framework able to support the process of building / running ETL cycle delivering the benefits mentioned above. Keywords: extract, transform, Data Warehouse, ETL. 7

9 SIGLAS ETL: Extract, Transform, Load XML: extensible Markup Language IDE: Integrated Development Enviroment CSV: Comma Separate Value HTML: HyperText Markup Language ODS: Operational Data Store MDM: Master Data Management XSD: XML Schema Definition 8

10 Sumário Sumário... 9 Capítulo 1: Introdução Contextualização Motivação Objetivo Metodologia Estrutura do documento Capítulo 2: Ciclo ETL Introdução Extract (Extração) Transform (Transformação) Load (Carga) Exemplo prático Duas Abordagens Capítulo 3: Extreme DataStream Introdução Fluxo de Dados Metadados Layout Nós de Processamento Arestas Capítulo 4: Implementação Visão geral Padrões de Projeto Diagrama de Classes O problema Produtor-Consumidor Criando Novos Nós de Processamento Capítulo 5: Exemplo de Uso Paralelismo Introdução O Problema Hardware Utilizado Grafos Utilizados Resultados Conclusões Capítulo 6: Conclusões e Lições Aprendidas...47 Referências

11 Capítulo 1: Introdução 1.1. Contextualização Falar que a análise de dados é de suma importância para as empresas é um eufemismo. De fato, nenhum negócio pode sobreviver sem analisar os dados disponíveis. Podemos mostrar situações como: analisar a aceitação de um suco de frutas baseando-se em dados de vendas históricos, verificar sazonalidade de vendas de determinado produto, prever fraudes em cartões de crédito baseando-se no comportamento passado do cliente, encontrar correlações entre eventos (Ex.: temporada de furacões e venda de produtos não perecíveis). Todas essas situações são indicativos suficientes para concluir que a análise de dados está à frente de qualquer negócio. Assim, esta pode ser definida como o processo de inspecionar, higienizar, transformar e modelar os dados com o objetivo de retirar informação, conclusões e ajudar no processo decisório de uma empresa Motivação Atualmente os dados estão presentes em vários meios digitais como bases de dados de transações, posts do Facebook, Twitter, redes de sensores, logs de transações, mensagens de texto, e etc. Tendo em vista que os dados já estão presentes e na maioria das vezes digitalizados, o grande desafio se dá na disponibilização/processamento/armazenamento desse dado para o usuário final, seja ele outro sistema ou um indivíduo. Essa informação apresenta três tipos de caraterísticas: possuem grandes volumes, da ordem de bilhões de registros, possuem velocidades diferentes (eventos ocorrendo em diferentes janelas de tempo, como taxa de amostragem de um sensor, compras em sites da internet e posts de redes sociais.) e possuem com grande variedade de fontes de dados. Esses 3Vs (volume, variedade e velocidade) descrevem, segundo Gartner, que é a consultoria líder em pesquisa de tecnologia da informação no mundo, o conceito de Big Data. 10

12 1.3. Objetivo Dado o cenário anteriormente explicitado, temos a convicção que a análise de dados pode ser uma área bem complexa. Ela possui diversas facetas, técnicas, apoiados por diversos nomes, em diferentes negócios. A mineração de dados pode ser entendida como a técnica que foca na modelagem e descoberta de conhecimento para realizar predições. A parte de Inteligência de Negócios cobre a análise de dados utilizando informações do negócio, utilizando consultas agregadas e respondendo a perguntas descritivas do tipo On-line Analytical Processing (OLAP). Por exemplo, quantas escovas de dente foram vendidas entre abril e maio no estado do RJ. A análise preditiva foca na aplicação de modelos para realizar previsões. Por exemplo, baseado em um histórico de transações bancárias, qual a probabilidade de uma determinada transação ser fraudulenta ou não. Todas as análises acima citadas partem do pressuposto de que já foi realizado um prévio tratamento nos dados. Que estes já foram higienizados, estruturados, padronizados e transformados. A esse ciclo damos o nome de Extract, Transform and Load (ETL). O ciclo de ETL envolve a extração dos dados de diversas fontes, a transformação do dado (padronização, higienização, junção de diversas fontes, etc) e a carga no sistema alvo, normalmente um banco de dados. O ciclo de ETL pode envolver uma considerável complexidade, e grandes problemas operacionais podem ocorrer caso seja mal modelado. Por ser um processo de natureza complexa, o ciclo ETL é normalmente apoiado por ferramentas de mercado. Essas ferramentas trazem algumas vantagens em relação ao processo normal, onde o desenvolvedor cria aplicações para realizar a extração/transformação/carga dos dados. São elas: auto documentação (permitem a visualização do fluxo de dados graficamente), reutilização de componentes, design estruturado e padronizado, melhor desempenho (paralelismo) e consequente aumento de produtividade e qualidade do processo. Assim, o objetivo deste projeto é criar um framework capaz de apoiar o processo de construção/execução de um ciclo ETL oferecendo os benefícios anteriormente citados. Esse framework possibilitará a paralelização de processos e utilizará a técnica de pipeline para prover ganhos de desempenho sobre a metodologia tradicional. 11

13 1.4. Metodologia Para o desenvolvimento do nosso projeto adotamos o modelo de desenvolvimento de software sequencial, conhecido como modelo em cascata. Escolhemos esse modelo, pois partimos de requisitos e fases bem definidas, pois já existem ferramentas parecidas como a que vamos construir. Assim nosso projeto ficou constituído em cinco fases: Levantamento de requisitos, Projeto do Sistema, Construção, Integração. Durante a construção realizamos testes unitários e de integração em componentes críticos do sistema. Ao final, foram realizamos testes de validação para verificar aderência com os requisitos. Como se trata de um framework que deve ser extensível, tentamos criar nossas classes bem desacopladas e com alto grau de coesão. Para isso, fizemos usos de alguns padrões de projeto como: Fábrica Abstrata (Abstract Factory) e Singleton. Por ser extensível, considerá-lo-emos como um framework caixa-cinza, ou seja, já possui componentes e funcionalidades prontas, porém é permitido a partir da extensão e inserção de novas classes, a criação de novos componentes e funcionalidades. Mostraremos como estendê-lo na seção Criando Novos Nós de Processamento Utilizamos a linguagem Object Pascal, que é uma extensão da linguagem Pascal com suporte a Orientação a Objeto, para o desenvolvimento do nosso framework. A IDE utilizada foi a Borland Delphi Enterprise Estrutura do documento Esse projeto de final de graduação está dividido em seis capítulos: - Introdução: começamos o capítulo contextualizando e mostrando ao leitor em que área da Engenharia de Computação estamos abordando. Em seguida, descreveremos qual a motivação do projeto e os objetivos que queremos alcançar. Descreveremos as ferramentas e o modelo de ciclo de vida que iremos utilizar. - Ciclo ETL: nesse capítulo situaremos o leito no que se refere a um ciclo ETL. 12

14 Descreveremos cada uma das etapas do ciclo (Extração/Transformação/Carga) e daremos alguns exemplos. Ao final mostraremos duas abordagens de criação de um ciclo ETL e listaremos suas vantagens e desvantagens. - Extreme DataStream: descreveremos para o leitor o principal componente do framework. Definiremos alguns conceitos pertinentes as projeto como fluxo de dados, metadados, nós de processamento e arestas. Mostraremos como definir esses conceitos em nossa abstração de grafo utilizando uma estrutura XML. - Implementação: mostraremos nesse capítulo artefatos como diagramas de classe, diagrama de sequência. No nível de código fonte mostraremos quais padrões de projeto utilizamos. Definiremos o problema de produtor-consumidor e como ele se adequa em nossa necessidade. Por fim, mostraremos como é possível estender o framework para a criação de novos nós de processamento. - Exemplo de Uso Paralelismo: partiremos para um caso de uso onde mostraremos a capacidade de paralelizar um determinado ciclo ETL, descreveremos o problema e o hardware utilizado. Mostraremos quatro versões de grafos e analisaremos a execução dos mesmo, mostrando os resultado e as conclusões. - Conclusões e Lições Aprendidas: nesse capítulo faremos um apanhado geral sobre o projeto. O que aprendemos, quais pontos altos e baixos, erros e acertos durante o projeto e das ferramentas escolhidas. 13

15 Capítulo 2: Ciclo ETL 2.1. Introdução Um ciclo de ETL (Extract, Transform e Load), refere-se a um processo no domínio de banco de dados muito utilizado para realizar carga em sistemas de Data Warehouse, Operational Data Store (ODS) e Datamarts. Também é vastamente utilizado na área de integração de dados, migração de dados e Master Data Management (MDM). Este ciclo envolve três etapas distintas: extração, transformação e carga Extract (Extração) A primeira parte de um ciclo ETL envolve extrair dados de sistemas fontes. Esses sistemas podem ser bem heterogêneas, com dados em diversos formatos, e devem ser consolidados para realizar a carga no Data Warehouse. Alguns formatos comuns de dados incluem: banco de dados relacionais e arquivos planos, como arquivo CSV, XML, HTML e etc. Outra maneira de realizar o processo de ETL é a utilizando dados online, ou seja, conforme os dados vão chegando através de um fluxo de dados, são tratados, transformados e carregados no sistema alvo. Uma etapa intrínseca à extração se refere a tratar somente dados em formatos esperados e descartar dados de fontes desconhecidos. Ou seja, os dados advindos dos sistemas fonte devem estar em um padrão ou estrutura previamente conhecidos Transform (Transformação) Nessa fase é aplicadas uma série de regras e funções sobre os dados vindos da etapa de extração para transformá-los em entradas para o processo de carga. Alguns processos desta fase são: 1. Ordenação de um arquivo por uma determinada chave. 2. Selecionar somente algumas informações. Por exemplo, se o arquivo fonte tiver três tipos de informações (nome, idade e nacionalidade) e queremos utilizar somente nome e 14

16 idade. 3. Padronização: como os arquivos podem vir de diversas fontes, podemos ter atributos que representam a mesma informação, mas com dados diferentes. Exemplo: Em um arquivo podemos ter masculino igual à 1 e feminino igual 2 e em outro Masculino igual a M e Feminino igual a F. 4. Derivação de um novo cálculo. Por exemplo, valor_venda = quantidade*preco_unitario. 5. Junção de múltiplas fontes de dados por chaves de junção. Podemos também efetuar duplicação de registros. Podemos agregar registros para formar um dado estatístico. Por exemplo, sumarizar múltiplas linhas de um arquivo de transações para ter o total de vendas por loja, total de vendas por região, etc. 6. Transpor o arquivo original, isto é, linhas viram colunas e colunas viram linhas. 7. Dividir um arquivo CSV em arquivos separados, um para cada coluna 8. Validar e buscar dados em tabelas ou arquivos de referência. 9. Aplicar qualquer tipo de validação simples ou complexa no dado. Por exemplo, validar se um determinado campo apresenta uma data válida. Caso haja alguma exceção poderá haver rejeição parcial ou completa Load (Carga) A fase de carga é o momento em que os dados advindos da etapa anterior são carregados no sistema alvo, que normalmente é um Data Warehouse. Essas cargas, em sua maioria, são realizadas periodicamente (diariamente, semanalmente ou mensalmente). Isso ocorre, porque o DW é usualmente utilizado para guardar informações históricas. Conforme os dados são carregados no sistema, o banco de dados é responsável por tratar as condições de integridade dos dados que estão sendo inseridos, como por exemplo, realizar uma validação de data, disparar uma trigger para atualizar outra tabela, tratar a unicidade de um dado Exemplo prático Duas Abordagens O ciclo de ETL pode envolver uma grande complexidade e problemas podem ocorrer caso este seja mal modelado. Descreveremos sucintamente um exemplo de ciclo ETL e mostraremos duas abordagens para sua construção. Em seguida, mostraremos 15

17 suas vantagens e desvantagens. Figura 1 - Representação de um ciclo ETL, utilizando um grafo. Acima apresentamos um ciclo ETL, descrito como um grafo. Clientes.txt e Itens.txt: arquivos de entrada do ciclo ETL. Leitor de arquivos: realizar leitura dos arquivos de entrada. Consulta Receita: processo responsável por realizar uma consulta à Receita Federal, utilizando CPF como chave e trazendo o nome da pessoa. Cálculo da Nota Fiscal: A partir dos itens, o processo calcula a nota fiscal. Ordenação: realiza a ordenação dos arquivos, um pela chave fkcliente e outra pela chave pkcliente. Junção: realiza a junção dos arquivos vindos das arestas nove e onze, utilizando as chaves fkcliente e pkcliente. Escritor de Arquivos: realizar a escrita do arquivo final em disco. Arquivo de Saída: arquivo final do processo. Abordagem Monolítica: Nessa abordagem todo o ciclo ETL é criado a partir do zero, e todas as transformações dos dados são realizadas através um único programa, seja ele um executável ou um script. Imagine o ciclo completo ETL descrito acima sendo executado apenas por uma aplicação. Teríamos um total acoplamento, uma baixa coesão e sem possibilidade de reutilização dos componentes (dependendo da modelagem essa reutilização pode ser dá em nível de código fonte apenas). Toda manutenção/evolução seria feita em apenas um componente, o que acarretaria possíveis novos erros de difícil rastreabilidade. 16

18 Abordagem um módulo por nó de processamento: Nessa abordagem temos um executável/script por nó de processamento, onde um nó X possui como entrada o arquivo A1 e uma saída A2. A saída do nó X será a entrada para o nó Y. Assim o ciclo segue, onde a saída de um nó de processamento é entrada para outro. Nessa abordagem, todos os nós de processamento devem possuir uma maneira de ler/escrever no disco já que esta é à maneira de comunicação entre eles. Para a descrição das vantagens e desvantagens entre as duas abordagens chamaremos a monolítica, de abordagem A, e a outra de abordagem B. Na abordagem A temos a vantagem em relação a B de realizarmos menos E/S no disco. Isso acarreta um ganho de desempenho por não utilizar um dos recursos mais lentos do computador, que é o acesso ao disco físico. Em contrapartida, na abordagem B podemos paralelizar o ciclo ETL, ou seja, utilizar melhor os recursos de CPU em detrimento do E/S. Em um ciclo ETL do tipo CPU bound, onde o maior tempo é gasto utilizando a CPU, o ciclo B tende a possuir um melhor desempenho em relação ao A, pois realiza um melhor uso dos recursos conseguindo paralelizar as tarefas. No exemplo acima, utilizando a abordagem B, poderíamos executar os nós de processamento Leitor de Arquivos, Cálculo da Nota Fiscal e Ordenação por fkcliente concorrentemente com Leitor de Arquivos, Consulta a Receita, Valida Node e Ordenação por pkcliente. Na abordagem A temos baixíssima reutilização apenas em nível de código fonte. Na abordagem B, os nós de processamento são módulos separados e podemos intercambiá-los para criar novos ciclos ETL. Apresentaremos nas próximas seções nossa abordagem para a criação do ciclo ETL, e tentaremos unir o melhor das duas abordagens anteriormente citadas, ou seja, um ganho de produtividade por reutilização de nós de processamento sem perda de desempenho. 17

19 Capítulo 3: Extreme DataStream Introdução Ferramentas de ETL são construídas para poupar esforço (tempo e dinheiro) eliminando, quase em sua totalidade, a escrita de código. Dentre algumas vantagens podemos citar: auto documentação (permitem a visualização do fluxo de dados graficamente), reutilização de componentes, design estruturado e padronizado, melhor desempenho (paralelismo). Nessas ferramentas podemos modelar o ciclo ETL utilizando a abstração de um grafo, onde as arestas representam os dados fluindo de um processo para o outro, e os vértices representam os nós de processamento. Podemos utilizar como exemplo a figura já citada na seção anterior. O objetivo do framework Extreme DataStream é permitir a execução de um fluxo ETL, além de prover uma biblioteca onde novos nós podem ser incorporados ao sistema de maneira simples. Não será desenvolvido nenhum tipo de interface gráfica para a criação do fluxo ETL. Utilizaremos um arquivo XML para a descrição do fluxo em si. Quando falarmos de nós, vértices ou blocos, estaremos nos referindo a nós de processamento, ou seja, estruturas que realizam efetivamente o processo dos dados. Quanto falarmos em arestas, estaremos no referindo ao o fluxo de dados flui através dos nós de processamento, como os nós de processamento são interligados. Conforme visto, nas duas abordagens anteriores, temos vantagens e desvantagens. Abaixo citamos as resumidamente: Abordagem Monolítica (Abordagem A) - Vantagens: Menor quantidade de E/S no disco rígido em relação à abordagem B, acarretando melhor desempenho. - Desvantagens: Baixa reutilização, apenas em nível de código fonte. Abordagem um módulo por nó de processamento (Abordagem B) - Vantagens: Alta reutilização em nível de componentes. Possibilidade de paralelizar o processo. - Desvantagens: Baixo desempenho, pois os nós se comunicam através de 18

20 arquivos, ou seja, o arquivo gerado por um nó é entrada para o próximo nó. Em nosso framework, tentaremos unir o melhor das duas abordagens, ou seja, um alto desempenho com possibilidade de paralelismo, sem a necessidade de criação de arquivos intermediários entre os processos e reutilização em nível de componentes. Para não haver necessidade da criação de arquivos intermediários, utilizaremos a memória RAM da máquina, ou seja, cada nó de processamento será uma unidade autônoma provendo/consumindo dados de um buffer. Em alguns nós poderá haver a necessidade de criação de arquivos temporários, como por exemplo, uma ordenação de um arquivo que não cabe fisicamente na memória. Fica claramente evidenciado que temos um problema clássico de produtor-consumidor, que será abordado nas próximas seções. Resolvendo esse problema, estaremos retirando a única desvantagem da abordagem B, e permanecendo com todas as suas vantagens. Claro que, neste momento, não estamos levando em consideração o tempo gasto na sincronização entre os processos/threads. O desenvolvedor do ciclo ETL deverá descrever seu grafo utilizando um arquivo XML, em um formato específico, que será descrito na próxima seção. Não é intuito desse Projeto de Graduação, criar uma ferramenta de apoio para a criação desse grafo Fluxo de Dados Para descrever nosso grafo do ciclo ETL utilizaremos um documento em formato XML. Para garantirmos que esse documento esteja corretamente formatado, a ferramenta utilizará um XML Schema. Um arquivo que contenha as definições da linguagem XML Schema é chamado de XML Schema Definition (XSD), o qual descreve a estrutura de um documento XML. Essa linguagem foi amplamente utilizada no desenvolvimento da nota fiscal eletrônica brasileira. Abaixo demonstramos o conteúdo do XSD. Explicaremos em detalhes cada uma das seções desse documento nas próximas seções. <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="etlmanager" type="etl_manager_type"></xs:element> 19

21 <xs:complextype name="etl_manager_type"> <xs:sequence> <xs:element name="metadatas" type="metadata_list"/> <xs:element name="phases" type="phase_list"/> </xs:sequence> </xs:complextype> <xs:complextype name="metadata_list"> <xs:sequence> <xs:element name="metadata" type="metadata_type" minoccurs="1" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="metadata_type"> <xs:sequence> <xs:element name="field" type="field_type" minoccurs="1" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="memory" type="xs:integer" use="required"/> </xs:complextype> <xs:complextype name="field_type"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="field_enum" use="required"/> <xs:attribute name="size" type="xs:integer" use="required"/> <xs:attribute name="initialpos" type="xs:integer" use="required"/> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:simpletype name="field_enum"> <xs:restriction base="xs:string"> <xs:enumeration value="string"/> <xs:enumeration value="integer"/> <xs:enumeration value="byte"/> <xs:enumeration value="longint"/> 20

22 </xs:restriction> </xs:simpletype> <xs:complextype name="phase_list"> <xs:sequence> <xs:element name="phase" type="phase_type" minoccurs="1" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="phase_type"> <xs:sequence> <xs:element name="edges" type="edge_list"/> <xs:element name="processes" type="process_list"/> </xs:sequence> <xs:attribute name="id" type="xs:integer" use="required"/> </xs:complextype> <xs:complextype name="edge_list"> <xs:sequence> <xs:element name="edge" type="edge_type" minoccurs="1" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="process_list"> <xs:sequence> <xs:element name="process" type="process_type" minoccurs="1" maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="process_type"> <xs:sequence> <xs:any maxoccurs="unbounded" processcontents="skip"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="type" type="xs:string" use="required"/> </xs:complextype> <xs:complextype name="edge_type"> 21

23 <xs:attribute name="fromprocess" type="xs:string" use="required"/> <xs:attribute name="fromport" type="xs:integer" use="required"/> <xs:attribute name="toprocess" type="xs:string" use="required"/> <xs:attribute name="toport" type="xs:integer" use="required"/> <xs:attribute name="metadata" type="xs:string" use="required"/> </xs:complextype> </xs:schema> Metadados Layout Metadados são dados sobre outros dados. No nosso contexto, os metadados farão a descrição dos dados que trafegam entre as arestas do nosso ciclo ETL. Esses metadados serão sempre formatados como registros de tamanho fixo. Em um registro de tamanho fixo, um campo sempre começa e termina no mesmo lugar em todos os registros. Por exemplo: Pedro da Silveira Magalhaes RJ Jose Carlos da Silva SP Renata Souza MG Luis Felipe BA O conjunto de dados acima representa um arquivo onde seus registros possuem tamanho fixo. Nome Posição Inicial = 1 Posição Final = 30 Renda Posição Inicial = 30 Posição Final= 36 CEP Posição Inicial = 36 Posição Final = 44 UF Posição Inicial = 44 Posição Final = 46 Para o caso citado acima, o registro possui um tamanho de 46 bytes. Não são necessários delimitadores, pois todos os campos possuem tamanho fixo. Abaixo, descrevemos o XSD para a sessão de declaração de metadados: <xs:complextype name="metadata_type"> <xs:sequence> 22

24 <xs:element name="field" type="field_type" minoccurs="1" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="memory" type="xs:integer" use="required"/> </xs:complextype> <xs:complextype name="field_type"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="type" type="field_enum" use="required"/> <xs:attribute name="size" type="xs:integer" use="required"/> <xs:attribute name="initialpos" type="xs:integer" use="required"/> </xs:extension> </xs:simplecontent> </xs:complextype> <xs:simpletype name="field_enum"> <xs:restriction base="xs:string"> <xs:enumeration value="string"/> <xs:enumeration value="integer"/> <xs:enumeration value="byte"/> <xs:enumeration value="longint"/> </xs:restriction> </xs:simpletype> Na seção metadata devemos definir um ID único para nosso metadado. Quando um dado flui de um nó para outro, esta informação deverá ser armazenada na aresta que interliga esses dois nós. O dado permanece na aresta, alocado na memória RAM do computador, e o tamanho do buffer de alocação é configurado através da tag memory. Em outros termos, a tag memory define o tamanho máximo da fila no problema produtor-consumidor. Destacamos uma seção apenas para descrever o processo de produtor-consumidor. Na seção field descrevemos informações sobre o campo do registro de 23

25 tamanho fixo. Para isso temos os seguintes atributos: - type: representa um tipo enumerado que define o tipo de dado no campo. Pode ser string, integer, byte ou um longint. Apesar de termos listados todos esses tipos de campos, somente está implementado na solução o campo do tipo string. - initialpos: define onde o campo começa dentro do registro de tamanho fixo. - size: define o tamanho do campo. Destacamos abaixo um exemplo de um metadado definido: <metadata id="metadata0" memory="40000"> <field type="string" size="2" initialpos="0">valor</field> <field type="string" size="2" initialpos="2">crlf</field> </metadata> Nós de Processamento São as estruturas que efetivamente realizam o trabalho sobre os dados. O intuito do projeto não é prover os mais variados tipos de transformações sobre os dados, e sim uma maneira simples para o desenvolvedor criar os seus próprios nós de processamento. A criação de nós bem coesos e flexíveis garante ao desenvolvedor do fluxo de ETL uma maior reutilização dos blocos já criados. Alguns exemplos de nós de processamento são: - nó capaz de realizar a ordenação de um arquivo a partir de uma chave. - nó capaz de retirar a duplicidade de registros, utilizando a escolha de uma chave única. - nó capaz de realizar a junção de dois fluxos de dados utilizando uma chave de junção. - nó capaz de filtrar os registros de um fluxo de dados utilizando uma expressão lógica / matemática. Os nós de processamento possuem como entrada fluxos de dados. Esses fluxos de dados pode se originar de qualquer recurso do sistema, seja um disco físico, a própria memória RAM ou uma interface de rede, bastando para isso criar nós específicos. Abaixo descrevemos o XSD somente da seção de criação de nós de processamento. <xs:complextype name="process_list"> <xs:sequence> <xs:element name="process" type="process_type" minoccurs="1" 24

26 maxoccurs="unbounded" /> </xs:sequence> </xs:complextype> <xs:complextype name="process_type"> <xs:sequence> <xs:any maxoccurs="unbounded" processcontents="skip"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="type" type="xs:string" use="required"/> </xs:complextype> Na seção process definimos um nó de processamento que fará parte do nosso ciclo ETL. Esses nós devem conter sempre o atributo id e o atributo type. O id define unicamente um processo dentro do ciclo, enquanto o type define o tipo do processo. Para executar nossos exemplos criamos apenas três tipos de processos, que são eles FileReader, FileWriter e Factorial. - FileReader Nó responsável pela leitura de um arquivo texto de tamanho fixo. Exemplo: <process id="filereader0" type="filereader"> <recordsize>4</recordsize> <filepath>d:\projetos\factorial.txt</filepath> </process> O tamanho do registro do arquivo é indicado pela tag recordsize. O caminho do arquivo é indicado pela tag filepath. Esse leitor possui a capacidade de ler partes segmentadas do arquivo de entrada, dependendo da quantidade de arestas de saída ligadas a ele. Considere o trecho de ciclo ETL abaixo, onde o FileReader aparece lendo como entrada o arquivo Numeros.txt e ligado a três processos que são responsáveis por realizar um cálculo de score. 25

27 Figura 2 - Exemplo de Utilização do FileReader para realizar paralelismo Assim o nó FileReader se comportará da seguinte maneira: ele entregará blocos de registros aos nós conectados a ele, utilizando uma política de round-robin. Dessa maneira, conseguiremos paralelizar o cálculo do score, onde cada um dos nós CalculaScore executará sua tarefa em um processador. Mais a frente mostraremos um exemplo prático e os resultados obtidos com esse paralelismo. - FileWritter Nó responsável pela escrita dos dados em disco. Análogo ao FileReader, esse escritor de arquivos possui a capacidade de receber N fluxos de dados, ou seja, podemos conectar quantas arestas quisermos em um nó do tipo FileWriter. Cada uma dessas arestas será conectada a uma porta diferente. Assim o FileWriter lerá cada fluxo de dados utilizando um política de round-roubin e escrevendo o resultado em arquivo físico, diretamente no disco rígido. Exemplo: <process id="filewriter0" type="filewriter"> <filepath>d:\factorial_out.txt</filepath> </process> O caminho do arquivo de saída, o qual será efetivamente gravado em disco, é indicado pela tag filepath. - Factorial Nó responsável pelo cálculo do fatorial de um número. Esse nó, por ser muito específico, provavelmente não apresenta nenhuma utilização prática. Ele foi apenas criado para demostrar a capacidade da ferramenta de realizar tarefas em paralelo. Exemplo: 26

28 <process id="factorial1" type="factorial"> <factorialfield>valor</factorialfield> </process> A tag factorialfield indica qual campo deverá ser calculado o fatorial Arestas Quando ligamos um nó de processamento a outro, criamos uma aresta. Os dados que trafegam de um nó pra outro ficam temporariamente armazenados na aresta, em um buffer na memória RAM da máquina. Abaixo descrevemos o XSD somente da seção de criação de nós de processamento. <xs:complextype name="edge_type"> <xs:atribute name="fromprocess" type="xs:string" use="required"/> <xs:attribute name="fromport" type="xs:integer" use="required"/> <xs:attribute name="toprocess" type="xs:string" use="required"/> <xs:attribute name="toport" type="xs:integer" use="required"/> <xs:attribute name="metadata" type="xs:string" use="required"/> </xs:complextype> A tag fromprocess e fromport indica de qual nó/porta parte a aresta. A tag toprocess e toport indica em qual nó/porta a aresta chega. Assim para definir uma aresta, ou seja, de onde ela parte até onde ela chega, devemos defini-la com duas tuplas: (fromprocess, fromport) e (toprocess e toport). A tag metadata indica o formato dos dados que trafegam na aresta. Abaixo segue um exemplo de definição de duas arestas. <edges> <edge fromprocess="filereader0" fromport="0" toprocess="factorial1" toport="0" metadata="metadata0"/> <edge fromprocess="factorial1" fromport="0" toprocess="filewriter0" toport="0" metadata="metadata1"/> </edges> 27

29 Capítulo 4: Implementação Visão geral Para modelar nosso framework partimos dos conceitos chaves como: porta, processo, aresta e fases. Modelamos seus relacionamos através de um modelo conceitual que em seguida deu entrada no nosso diagrama de classes. Utilizamos o diagrama de sequência apenas para descrever o problema de Produtor-Consumidor. Utilizando o diagrama de classes, fica claro como deve ser feita a extensão do código para a criação de novos componentes. Na seção Criando Novos Nós de Processamento será mostrado como estender o framework para a criação de novos componentes Padrões de Projeto Descreve uma solução geral que pode ser utilizada para um problema recorrente no desenvolvimento de software orientado a objetos. Assim os padrões de projeto definem relações e interações entre as classes/objetos em um nível de abstração mais alto. Os padrões de projeto têm como objetivo facilitar as reutilizações de soluções e estabelecer um vocabulário comum facilitando documentação e o entendimento do código gerado. Em nossa implementação utilizamos dois padrões de projeto: * Factory (Fábrica) Objetivo - Criar um objeto sem expor a lógica de instanciação ao cliente - Criação de um novo objeto através de uma interface comum Utilização - Cliente necessita de um produto, mas ao invés de criá-lo diretamente, ele pede à fábrica por um novo produto, provendo a informação sobre o tipo de objeto que ele precisa. 28

30 - A fábrica instancia um novo produto concreto e retorna ao cliente o objeto recentemente criado. - O cliente utiliza o objeto como um produto abstrato sem se preocupar com sua implementação concreta. Vantagem - Conseguir adicionar um novo produto sem alterar a interface de criação, alterando apenas a fábrica. Existem certas implementações de fábrica que permite a inclusão de novos tipos concretos sem alterar a fábrica. * Singleton Às vezes é importante termos apenas uma instância da classe. Usualmente singletons são utilizadas para centralizar o gerenciamento de recursos internos ou externos provendo um ponto global de acesso. Objetivo - Garantir que apenas uma instância da classe será criada - Prover um ponto de acesso global ao objeto Figura 3 - Modelo de classes do padrão Singleton Utilização O padrão Singleton define a operação getinstance, a qual expõe uma única instância a ser acessada pelos clientes. O método getinstance é responsável por criar uma única instância da classe caso ela ainda não tenha sido criado e retorná-la Diagrama de Classes 29

31 Figura 4 - Diagrama de Classes (Visão de Processos) A classe TProcessFactory, juntamente com a classe abstrata TProcess, representa a implementação do padrão de projeto Fábrica. Esta Fábrica (TProcessFactory) é responsável pela criação dos nós de processamento do sistema. Cada nó de processamento é executado em threads separadas, por isso a classe TProcess é filha da classe Thread. Para criação de um novo nó devemos passar a sua descrição representada pela classe TProcessDescription. Cada processo possui uma lista de portas de saídas e entradas, representadas respectivamente, pelas classes TInputCollection e TOutputCollection. Estas duas classes utilizam outra Fábrica (TPortFactory) que é responsável pela criação da porta de comunicação. 30

32 Figura 5 - Diagrama de Classes (Visão Comunicação entre Processos) A classe TPortFactory juntamente com a classe TPortDescription implementa novamente o padrão Fábrica. Essa fábrica é responsável pela criação tanto de portas de saída (classe abstrata TOutput) como portas de entrada (classe abstrata TInput). 31

33 As classes TFixedRecordOutput e TFixedRecordInput representam as portas de saída e entrada respectivamente, que tratam os registros de tamanho fixo. Essas duas classes utilizam a classe TDataPacket (sua dependência se dá pela classe TPort que é pai das classes TInput e TOutput e possuí um atributo do tipo TDataPacket) que abstrai um ResultSet (um conjunto de registros). Esta classe é onde os dados são armazenados para posterior escrita deles no buffer de transferência. Figura 6 - Diagrama de Classes (Visão Comunicação entre Processos - Classes Abstratas) A classe TEdge abstrai a aresta que liga duas portas de nós de processamento. Nessa classe se encontra o buffer responsável pelo armazenamento do TDataPacket. O método Write da classe TOutput escreve dados para a classe TDataPacket. Assim que o buffer do TDatapacket está cheio, ele é escrito no TBuffer, utilizando o método Write. A parte de leitura é análoga. Na seção Diagrama de Sequência descreveremos essa interação. 32

34 Figura 7 - Diagrama de Classes (Visão Metadados) A estrutura de classes acima é responsável pela leitura do XML que define o grafo. Temos como classe raiz, a classe TETLGraphXML que é implementada utilizando o padrão de projeto Singleton. Tomamos essa decisão por precisar de um ponto único de acesso à abstração do grafo. 33

35 Figura 8 - Diagrama de Classes (Visão Controlador do Grafo) A classe TGraphManager é interface para gerenciamento da execução do grafo. Ao criarmos a TPhase, criaremos todos os processes dessa fase. Para isso, utilizei novamente o padrão de projeto fábrica, representado pelas classes TProcessFactory e TProcess. A classe TPhase possui o método Launch(), que quando chamado executa a fase do grafo. Cada processo e fase é executado em threads separada. Além destas threads, temos a classe TWacthDogThread que verifica de tempos em tempos o estado de execução dos processos O problema Produtor-Consumidor O problema de produtor-consumidor é um exemplo clássico de sincronização. Ele estabelece os processos concorrentes que compartilham uma área de escrita/leitura. 34

36 O produtor é responsável por gerar os dados que serão disponibilizados na área de leitura/escrita. Concorrentemente, o consumidor estará lendo e removendo os dados dessa área. O problema é ter certeza que o produtor não tentará adicionar dados na área de leitura/escrita quando estiver cheia,e que o consumidor não tentará remover dados quando a área estiver vazia. Assim, quando temos a área de escrita/leitura cheia o produtor deve esperar até que haja espaço. O mesmo ocorre para o consumidor que deve esperar até que exista alguma informação na área para ser consumida. Assim que o produtor coloca dados na área de leitura/escrita ele avisa o consumidor, para ele iniciar o processamento. Quando o consumidor retira dados da área ele avisa ao produtor. Essa solução é atingida através de uma comunicação entre processos, que pode ser implementada utilizando recursos do sistema operacional como semáforos e mutexes. Abaixo mostramos uma solução retirada do Wikipédia, que é a mesma que utilizaremos ao abordar o problema em nosso projeto. Ela utiliza o recurso de semáforos para realizar a sincronização entre processos. semaphore fillcount = 0; // itens produzidos semaphore emptycount = BUFFER_SIZE; // espaço remanescente procedure producer() { while (true) { item = produceitem(); down(emptycount); putitemintobuffer(item); up(fillcount); } } procedure consumer() { while (true) { down(fillcount); item = removeitemfrombuffer(); up(emptycount); consumeitem(item); } } No contexto de nossa aplicação nos deparamos com o problema de produtor 35

37 consumidor no momento de trafegar os dados entres os nós de processamento. Para ilustramos o problema do produtor-consumidor no contexto de nossa aplicação utilizamos o diagrama de sequências abaixo: Figura 9 - Diagrama de sequência mostrando o problema do Produtor-Consumidor A classe TOutput é responsável pela escrita dos dados, utilizando a chamada ao método Write da classe TEdge. A classe TEdge escreve no buffer, realizando a tratativa do problema produtor-consumidor. Ela verifica se possui espaço no buffer pelo o semáforo EmptyCount. Caso haja espaço, ela realiza a escrita e notifica o outro semáforo FillCount que os dados podem ser consumidos. Caso não haja ela dorme e espera o outro processo acordá-la. 36

38 A classe TInput é responsável pela leitura dos dados, utilizando a chamada ao método Read da classe TEdge. Ela verifica se possui algum dados no buffer, verificando o semáforo FillCount. Caso haja dados para serem consumidos, ela realiza a leitura do dado. Caso não haja, ela dorme e espera o outro processo acordá-la. Abaixo colocamos dois trechos de código, um do método Write e outro do método Read da classe TEdge, em linguagem pascal. procedure TEdge.Write(Content: PAnsiChar; Size: integer); begin //espera ter uma unidade disponivel no semaforo WaitForSingleObject(EmptyCount, INFINITE); //move informações para o buffer ponteiro por pt Move(Size, pt^, SizeOf(Integer)); pt := pt + SizeOf(Integer); Move(Content^, pt^, Size); pt := FBuffer; //incrementa o semaforo com uma unidade ReleaseSemaphore(FillCount, 1, nil); end; function TEdge.Read(var Content: PAnsiChar; var Size: integer): boolean; begin EOF := true; WaitForSingleObject(FillCount, INFINITE); //lê o tamanho dos dados do buffer Move(pt^, Size, SizeOf(Integer)); pt := pt + SizeOf(Integer); if (Size <> -1) then begin Move(pt^, FContent^, Size); Content := FContent; EOF := false; end; //reseta ponteiro pt := FBuffer; ReleaseSemaphore(EmptyCount, 1, nil); end; 37

39 1.19. Criando Novos Nós de Processamento Um dos objetivos do framework é a possibilidade de estendê-lo e criar novos componentes (novos nós de processamento). Para isso montamos nossa estrutura de classes de modo que esta tarefa fosse bem simples, bastando para isso realizar a extensão de classes do framework. Para a criação de novos nós de processamento devemos estender a classe TProcess e inserir um novo tipo de nó na fábrica TProcessFactory. As informações sobre o nó, ou seja, os metadados do nó estão disponíveis através da propriedade FXMLNode herdada da classe TProcess. Para acessar as portas de entrada e saída utilizamos as propriedades FInputCollection do tipo TInputCollection e FOutputCollection do tipo TOutputCollection, que são herdadas da classe TProcess. Abaixo colocamos trechos de código mostrando a inclusão do nó Fatorial type TFactorial = class(tprocess)... public procedure Run(); override; procedure TFactorial.Run;... begin while (InputPort.Read(Value)) do //le dados da porta de entrada begin move(value^, FNumberStr[1], 2); //valor a ser calculado FactorialStr := IntToStr(GetFatorial(StrToInt(FNumberStr)));... OutStr := FOutNumber + #13#10; OutPutPort.Write(Pansichar(OutStr)); //valor fatorial end InputPort.Close(); //fecha porta de entrada OutPutPort.Close(); //fecha a porta de saída end; type TProcessFactory = class... 38

40 class function TProcessFactory.GetProcess(ProcessDesc: TProcessDescription): TProcess; begin... if (ProcessDesc.ProcessType = 'Factorial') then begin Result := TFactorial.Create(ProcessDesc.PhaseID, ProcessDesc.ProcessID); Exit; end; end; 39

41 Capítulo 5: Exemplo de Uso Paralelismo Introdução O objeto desta seção é demonstrar a utilização do framework para a execução de um processo ETL. Para demonstrar a capacidade de realizar paralelismo utilizaremos quatro tipos de grafo. Todos os grafos possuem a mesma saída, porém utilizam níveis de paralelismo diferentes. Mostraremos o ganho em paralelizar o ciclo ETL através desses exemplos O Problema O problema que trataremos é bastante simples e capaz de ser paralelizado. Ele consiste em calcular o fatorial de uma lista de números. Para aumentar a utilização de CPU, ao invés de calcular apenas uma vez o fatorial do número, realizaremos esse procedimento 10 vezes. - Entrada do problema (lista de números): Um arquivo texto, com números inteiros, variando de 1 a 10, separador por CR+LF. Esse arquivo possui um total de bytes, ou seja, * 4 bytes (2 bytes representando os números e mais 2 bytes de CR+LF). - Saída Um arquivo texto, com números inteiros, variando de 1 a , separados por CF+LF. Esse arquivo possui um total de bytes, ou seja * 9 bytes (7 bytes representando o resultado do fatorial e mais 2 bytes de CR+LF) Hardware Utilizado O objetivo do exemplo de uso é demonstrar o paralelismo e o ganho de desempenho no ciclo ETL. Nosso ciclo possui a característica de ser CPU Bound. Dado isso necessitamos descrever o processador e sua quantidade de núcleos. O processador utilizado será o Core i3 da família de processadores Intel, destinado a Desktops x Ele possui o recurso de Hyper-Threading que lhe 40

42 possibilita simular a existência de um maior número de núcleos, fazendo com que o seu desempenho aumente. Mais especificamente este processador possuí dois núcleos de processamento físico e dois virtuais, ou seja, ele possuí dois núcleos de processamento físico e simula mais dois. A tecnologia Hyper-Threading é uma tecnologia usada em processadores que realizam a simulação de mais dois núcleos. Essa técnica é utilizada para oferecer uma maior eficiência na utilização de recursos do processador. Segundo a Intel, o uso dessa tecnologia oferece um aumento de desempenho de até 30%. Abaixo mostramos uma imagem da janela do Gerenciador de Tarefas do Windows, demonstrando a presença de quatro núcleos de processamento: Figura 10 - Gerenciador de Tarefas do Windows. Como podemos ver o computador utilizado possui quatro processadores Grafos Utilizados Executaremos quatro grafos em nosso exemplo. O primeiro deles possuirá 41

43 apenas um nó de cálculo de fatorial, o segundo dois, e assim sucessivamente. Para exemplificar o grafo segue abaixo uma figura do grafo com um nó de processamento e outro com quatro nós de processamento. Figura 11 - Representação do grafo com apenas um nó de cálculo de fatorial <edges> <edge fromprocess="filereader0" fromport="0" toprocess="factorial1" toport="0" metadata="metadata0"/> <edge fromprocess="factorial1" fromport="0" toprocess="filewriter0" toport="0" metadata="metadata1"/> </edges> Acima apresentamos a listagem de arestas do grafo com um nó de processamento de fatorial. Figura 12 - Representação do grafo com quatro nós de cálculo de fatorial 42

44 <edges> <edge fromprocess="filereader0" fromport="0" toprocess="factorial1" toport="0" metadata="metadata0"/> <edge fromprocess="filereader0" fromport="1" toprocess="factorial2" toport="0" metadata="metadata0"/> <edge fromprocess="filereader0" fromport="2" toprocess="factorial3" toport="0" metadata="metadata0"/> <edge fromprocess="filereader0" fromport="3" toprocess="factorial4" toport="0" metadata="metadata0"/> <edge fromprocess="factorial1" fromport="0" toprocess="filewriter0" toport="0" metadata="metadata1"/> <edge fromprocess="factorial2" fromport="0" toprocess="filewriter0" toport="1" metadata="metadata1"/> <edge fromprocess="factorial3" fromport="0" toprocess="filewriter0" toport="2" metadata="metadata1"/> <edge fromprocess="factorial4" fromport="0" toprocess="filewriter0" toport="3" metadata="metadata1"/> </edges> Acima apresentamos um XML de exemplo com um grafo com quatro nós de processamento do cálculo do fatorial Resultados Realizamos a medição da execução dos grafos utilizando o aplicativo do Windows Monitor de Desempenho (perfmon.exe). - Execução do Grafo com um nó de Fatorial Consumo de CPU médio: 25,13% Tempo total: milissegundos Figura 13 - Uso de CPU x Tempo um processador 43

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

Módulo 4: Processos. Conceito de Processo. Diagrama de Estados de Processos. Estados de Processo

Módulo 4: Processos. Conceito de Processo. Diagrama de Estados de Processos. Estados de Processo Módulo 4: Processos Conceito de Processo Conceito de Processo Escalonamento de Processos Operações com Processos Processos Cooperativos Comunicação entre Processos Um sistema operacional executa uma variedade

Leia mais

Ambientes Visuais. Ambientes Visuais

Ambientes Visuais. Ambientes Visuais Ambientes Visuais Inicialmente, apenas especialistas utilizavam os computadores, sendo que os primeiros desenvolvidos ocupavam grandes áreas e tinham um poder de processamento reduzido. Porém, a contínua

Leia mais

Software e Serviços MANUAL DE HOMOLOGAÇÃO WEB SERVICE X SISTEMA DE AUTOMAÇÃO COMERCIAL

Software e Serviços MANUAL DE HOMOLOGAÇÃO WEB SERVICE X SISTEMA DE AUTOMAÇÃO COMERCIAL MANUAL DE HOMOLOGAÇÃO WEB SERVICE X SISTEMA DE AUTOMAÇÃO COMERCIAL CONSIDERAÇÕES INICIAIS Este manual tem como objetivo propiciar a integração do SISTEMA DE AUTOMAÇÃO COMERCIAL junto as ADMINISTRADORAS

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

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

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

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

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos:

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos: Estruturas de Sistemas Operacionais Podemos analisar um sistema operacional sob diversos aspectos: Os serviços que o sistema operacional oferece. A interface que o sistema operacional torna disponível

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso

No artigo anterior explicamos. Desenvolvimento de Software Dirigido por Caso de Uso. Parte II: Especificando Caso de Uso Desenvolvimento de Software Dirigido por Caso de Uso Parte II: Especificando Caso de Uso Vinicius Lourenço de Sousa viniciuslsousa@gmail.com Atua no ramo de desenvolvimento de software há mais de 10 anos,

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Esp. Marcos Morais de Sousa marcosmoraisdesousa@gmail.com Sistemas de informação Disciplina: Introdução a SI Noções de sistemas de informação Turma: 01º semestre Prof. Esp. Marcos Morais

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

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

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente

10. Defina Sistemas Distribuídos: Um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente 1. Quais os componentes de um sistema cliente-servidor? Clientes e servidores 2. Na visão do hardware, defina o que é cliente e o que é servidor: Clientes. Qualquer computador conectado ao sistema via

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

Roteiro para Transmissão Ambiente de Testes da Guias Online

Roteiro para Transmissão Ambiente de Testes da Guias Online Roteiro para Transmissão Ambiente de Testes da Guias Online (GRH) Acessar o sistema pelo site: http://www.sdas.org.br/ Acessar o sistema com o Usuário: 9999 e Senha: PMG52 Será disponibilizado o ambiente

Leia mais

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico Banco de Dados // 1 Banco de Dados // 2 Conceitos BásicosB Engenharia da Computação UNIVASF BANCO DE DADOS Aula 1 Introdução a Banco de Dados Campo representação informatizada de um dado real / menor unidade

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Processos e Threads Gustavo Reis gustavo.reis@ifsudestemg.edu.br - O que são Processos? Uma abstração de um programa em execução. Mantêm a capacidade de operações (pseudo)concorrentes,

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

XML: uma introdução prática X100. Helder da Rocha (helder@argonavis.com.br)

XML: uma introdução prática X100. Helder da Rocha (helder@argonavis.com.br) XML: uma introdução prática X100 Helder da Rocha (helder@argonavis.com.br) Atualizado em Jan 2003 O que é um Esquema XML? Documentos que aderem à especificação (válidos) O esquema representa uma classe

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

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

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

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

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

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

COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA

COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA 73 COMPARAÇÃO ENTRE OS FRAMEWORKS DE DESENVOLVIMENTO DE SOFTWARE ENTITY FRAMEWORK E NHIBERNATE : ESTUDO DE CASO EM UM SISTEMA Daniel José Angotti Analista de Negócio, Repom S/A djangotti@gmail.com Carlos

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

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) XML Origens. HTML Problemas

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) XML Origens. HTML Problemas Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) (extensible( Markup Language ) Origens (extensible Markup Language linguagem de marcação extensível) Criada em 1996 pelo W3C (World

Leia mais

Comparativo de desempenho do Pervasive PSQL v11

Comparativo de desempenho do Pervasive PSQL v11 Comparativo de desempenho do Pervasive PSQL v11 Um artigo Pervasive PSQL Setembro de 2010 Conteúdo Resumo executivo... 3 O impacto das novas arquiteturas de hardware nos aplicativos... 3 O projeto do Pervasive

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Processos I: Threads, virtualização e comunicação via protocolos Prof. MSc. Hugo Souza Nesta primeira parte sobre os Processos Distribuídos iremos abordar: Processos e a comunicação

Leia mais

Nível 3 Sistema Operacional

Nível 3 Sistema Operacional Nível 3 Sistema Operacional Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Tecnologia de Análise e Desenvolvimento de Sistemas Organização de Computadores Prof. André Luiz 1 Nível

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

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSOS MACHADO/MAIA: CAPÍTULO 07, PÁGINA 101 Prof. Pedro Luís Antonelli Anhanguera Educacional sistemas multiprogramáveis Os sistemas multiprogramáveis

Leia mais

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL

Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Empresa de Informática e Informação do Município de Belo Horizonte S/A PRODABEL Diretoria de Sistema - DS Superintendência de Arquitetura de Sistemas - SAS Gerência de Arquitetura de Informação - GAAS

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

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Unidade 1 Introdução Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José Pereira Contexto

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

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

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

Introdução à Ciência da Computação

Introdução à Ciência da Computação Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Introdução à Ciência da Computação Aula 05 Rogério Eduardo Garcia (rogerio@fct.unesp.br)

Leia mais

ARQUIVOS. Os arquivos criados em meios magnéticos poderão ser acessados para leitura e escrita na forma seqüencial, direta ou indexada.

ARQUIVOS. Os arquivos criados em meios magnéticos poderão ser acessados para leitura e escrita na forma seqüencial, direta ou indexada. Texto retirado e adaptado da apostila A Linguagem Pascal, disponível no site http://www.portaldaprogramacao.com (autor: desconhecido) ARQUIVOS Anteriormente, foi estudado o conceito de tabelas em memória

Leia mais

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse

Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse. Fases para um Projeto de Data Warehouse Definição escopo do projeto (departamental, empresarial) Grau de redundância dos dados(ods, data staging) Tipo de usuário alvo (executivos, unidades) Definição do ambiente (relatórios e consultas préestruturadas

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional

TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional O conteúdo deste documento tem por objetivo apresentar uma visão geral

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do

Leia mais

Tércio Oliveira de Almeida. TCC - Nexus - RAS

Tércio Oliveira de Almeida. TCC - Nexus - RAS Tércio Oliveira de Almeida TCC - Nexus - RAS Porto Alegre 12 de novembro de 2009 Tércio Oliveira de Almeida TCC - Nexus - RAS Trabalho de Graduação Orientador: Prof. Dr. Marcelo Soares Pimenta UNIVERSIDADE

Leia mais

Sistemas Operacionais Entrada / Saída. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br)

Sistemas Operacionais Entrada / Saída. Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Sistemas Operacionais Entrada / Saída Carlos Ferraz (cagf@cin.ufpe.br) Jorge Cavalcanti Fonsêca (jcbf@cin.ufpe.br) Tópicos Princípios do hardware de E/S Princípios do software de E/S Camadas do software

Leia mais

FERRAMENTAS NECESSÁRIAS PARA O DESENVOLVIMENTO EM C#

FERRAMENTAS NECESSÁRIAS PARA O DESENVOLVIMENTO EM C# FERRAMENTAS NECESSÁRIAS PARA O DESENVOLVIMENTO EM C# Camila Sanches Navarro 1,2, Willian Magalhães 2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil sanchesnavarro@gmail.com wmagalhaes@unipar.br

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

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

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Especificação Técnica

Especificação Técnica Especificação Técnica Última atualização em 31 de março de 2010 Plataformas Suportadas Agente: Windows XP e superiores. Customização de pacotes de instalação (endereços de rede e dados de autenticação).

Leia mais

Histórico de Revisões

Histórico de Revisões 1 Histórico de Revisões Data Versão Responsável Histórico 16/03/2012 1.0 Robson M. Matos Elaboração da documentação técnica 24/10/2014 2.0 Robson M. Matos Atualização da documentação técnica 2 Histórico

Leia mais

Funções de um SO. Gerência de processos Gerência de memória Gerência de Arquivos Gerência de I/O Sistema de Proteção

Funções de um SO. Gerência de processos Gerência de memória Gerência de Arquivos Gerência de I/O Sistema de Proteção Sistemas de Arquivos Funções de um SO Gerência de processos Gerência de memória Gerência de Arquivos Gerência de I/O Sistema de Proteção 2 Sistemas Operacionais Necessidade de Armazenamento Grandes quantidades

Leia mais

UNIP UNIVERSIDADE PAULISTA INSTITUTO DE CIÊNCIAS EXATAS E TECNOLOGIA (ICET) CURSO DE CIÊNCIAS DA COMPUTAÇÃO. O Paradigma da Orientação a Objeto

UNIP UNIVERSIDADE PAULISTA INSTITUTO DE CIÊNCIAS EXATAS E TECNOLOGIA (ICET) CURSO DE CIÊNCIAS DA COMPUTAÇÃO. O Paradigma da Orientação a Objeto UNIP UNIVERSIDADE PAULISTA INSTITUTO DE CIÊNCIAS EXATAS E TECNOLOGIA (ICET) CURSO DE CIÊNCIAS DA COMPUTAÇÃO O Paradigma da Orientação a Objeto Apresentada em Cumprimento Parcial dos Requerimentos para

Leia mais

SISTEMAS OPERACIONAIS

SISTEMAS OPERACIONAIS SISTEMAS OPERACIONAIS Processos e Threads Andreza Leite andreza.leite@univasf.edu.br Plano de Aula 2 Gerenciamento de Processos Threads Aplicações com múltiplas Threads Concorrência e Compartilhamento

Leia mais

Estrutura, Processos e Threads

Estrutura, Processos e Threads Estrutura, Processos e Threads Prof. Edwar Saliba Júnior Março de 2007 1 Sistema computacional A p l i c a t i v o s U t i l i t á r i o s N ú c l e o d o S i s t e m a O p e r a c i o n a l H a r d w

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

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

Capítulo 2 Processos e Threads Prof. Fernando Freitas

Capítulo 2 Processos e Threads Prof. Fernando Freitas slide 1 Capítulo 2 Processos e Threads Prof. Fernando Freitas Material adaptado de: TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 3ª edição. Disponível em: http://www.prenhall.com/tanenbaum_br slide

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

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

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

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

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

6 - Gerência de Dispositivos

6 - Gerência de Dispositivos 1 6 - Gerência de Dispositivos 6.1 Introdução A gerência de dispositivos de entrada/saída é uma das principais e mais complexas funções do sistema operacional. Sua implementação é estruturada através de

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Evolução Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Sumário Introdução Componentes de um sistema computacional Conceituação Características desejáveis Organização

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

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

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE SOFTWARE VARIAÁ VEL Antes de iniciarmos os comandos referentes a Banco de Dados, precisamos de uma breve descrição técnica sobre Variáveis que serão uma constante em programação seja qual for sua forma de leitura.

Leia mais

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

Programação Concorrente Processos e Threads

Programação Concorrente Processos e Threads Programação Concorrente Processos e Threads Prof. Eduardo Alchieri Processos O conceito mais central em qualquer sistema operacional é o processo Uma abstração de um programa em execução Um programa por

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

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

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos Módulo 4: Processos Conceito de Processo Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos 4.1 Conceito de Processo Um Sistema Operacional executa uma

Leia mais

Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto

Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto Introdução Processo cooperativo é aquele que pode afetar outros processos em execução no sistema Ou ser por eles afetado Processos

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

Millennium ECO 2.0 (beta)

Millennium ECO 2.0 (beta) MILLENNIUM NETWORK Millennium ECO 2.0 (beta) Documentação Técnica (draft) 10/2013 Este documento contém as instruções para a utilização da biblioteca Millenium_Eco que se presta à comunicação de aplicativos

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 DE ARQUIVOS DISTRIBUÍDOS

SISTEMA DE ARQUIVOS DISTRIBUÍDOS SISTEMA DE ARQUIVOS DISTRIBUÍDOS Sistemas Distribuídos 331 Arquivo: objeto que existe após criação, é imune a falhas temporárias e é persistente até que seja destruído Propósito de arquivos: armazenamento

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

SISTEMAS OPERACIONAIS 2007

SISTEMAS OPERACIONAIS 2007 SISTEMAS OPERACIONAIS 2007 VISÃO GERAL Sumário Conceito Máquina de Níveis Conceituação de SO Componentes do SO Visões do SO Conceito de Sistemas O que se espera de um sistema de computação? Execução de

Leia mais

Ficha Técnica Xenos Developer Studio

Ficha Técnica Xenos Developer Studio Xenos Developer Studio Ficha Técnica Xenos Developer Studio Xenos Developer Studio Soluções de Enterprise Output Management que reduz custos associados à impressão tradicional, ao mesmo tempo em que facilita

Leia mais

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases Engenharia de Software Modelagem de Requisitos com Casos de Uso 1 Objetivos Descrever em detalhe a técnica de Modelagem com Use Cases 2 1 Use Case É uma forma específica de uso do sistema através da execução

Leia mais

Considerando-se a especificação de requisitos de um software, é INCORRETO afirmar que esse documento

Considerando-se a especificação de requisitos de um software, é INCORRETO afirmar que esse documento QUESTÕES DE TI QUESTÃO 16 Considerando-se o número de pontos de função para a estimativa do tamanho de um software, é INCORRETO afirmar que, na contagem de pontos, leva-se em consideração A) as compilações

Leia mais

Visão do Usuário da DSM

Visão do Usuário da DSM Memória Compartilhada Distribuída Visão Geral Implementação Produtos 1 Memória Compartilhada Distribuída Mecanismos tradicionais de comunicação via RPC/RMI ou mensagens deixam explícitas as interações

Leia mais

Justificativa do uso da Linguagem XML no Projeto RIVED

Justificativa do uso da Linguagem XML no Projeto RIVED Justificativa do uso da Linguagem XML no Projeto RIVED Índice Introdução... 1 Sobre a linguagem XML... 2 O que é XML (extensible Markup Language)?... 2 Características da Linguagem...3 Sobre o seu uso...

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

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD)

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD) Pós-graduação em Ciência da Computação CCM-202 Sistemas de Banco de Dados Introdução Profa. Maria Camila Nardini Barioni camila.barioni@ufabc.edu.br Bloco B - sala 937 2 quadrimestre de 2011 Motivação

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados.

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Histórico Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Sistemas Integrados: racionalização de processos, manutenção dos

Leia mais