Monossílabas pelo messenger

Hoje pela manhã:

Ele: Oi.

Eu: ei.

Ele: seu pai* tá aí né?

Eu: aham.

Ele: Tá.

Eu: ok.

Ele: Off.

As pessoas mais improváveis aparecem nas horas mais impróprias.....

* meu 'chefe', pelo menssenger, é conhecido como pai.

Como os progrmas mudam com a idade ou minha falta de amadurecimento para festas

Para esse fim-de-semana, o programa foi um chá de panela.
Como? Vocês juntaram a galera para ir a um chá de panela? - Diriam os mais antenados.
Sim, juntamos os pares, compramos utensílios de cozinhas e montamos uma mini-excursão para um chá de panela. E, enganam-se os que, como eu, não conseguiam enxergar onde entraria a diversão nessa história. Foi ótimo, conheci umas brincadeiras que não quero passar por elas, nunca... Nunca mesmo! A apesar, dos pesares acabei me divertindo. Mas esse não é o foco deste post. Tentem me acompanhar:

Depois da festinha, do fim da excursão, eis que encontro uma prima minha, que também está na casa dos vinte e alguma, e o assunto surge: Como nossas festas evoluem e regridem de acordo com a nossa faixa etária. Quando éramos crianças, íamos a festas de aniversários, festas de escolinha, coisas mais leves, a intenção era correr muito e brincar com todos. Depois, quando viramos aborrecentes, as festinhas tem um outro intuito: conhecer pessoas do sexo oposto, exibir aquela roupa legal, achar um namorado (a), beijar muito... enfim, coisas médias, mais preocupações. A próxima fase, a dos adultos, seriam mais calmas, com músicas melhores, comidas mais saborosas e comportamento mais ...hum.. como vamos dizer... mais 'racional'.


'Pois é... Agora, nossas festas vão variando entre batizados, casamentos e seus derivados', ia dizendo minha prima. E eu, meio que sem saber em que rumo continuar, achei mais fácil, reclamar da minha falta de expectativas com esse novo ambiente e da falta que ainda sinto das baladinhas teens: primeiro, porque você não era fuzilada ao entrar desacompanhada; segundo, as pessoas de lá não reviravam sua vida pra saber como anda seu trabalho, sua vida social e, principalmente, sua vida amorosa; terceiro, não existia censura para os garotos presentes: eram todos disponíveis, agora, todos são comprometidos e estão presente só porque a namorada/noiva/esposa exige sua presença para dar uma pequena satisfação aos presentes, afinal, não querem ser fuziladas na entrada.

Quando terminei meu desabafo aborrecente, tomei consciência de que não estou totalmente pronta pra mergulhar nas festas do mundo adulto. Preciso de mais tempo para conseguir arrumar uma bóia salva vidas, e mais aulas de natação. Quem sabe, daqui a uns anos, já estarei melhor no esporte mergulho em mares abertos, e poderei ir a estas festinhas como quem vai a padaria buscar pão. E aí, poderei parar de tentar conversar as outras pessoas dos 'vinte e alguma coisa' a burlar essas festas também. Porque minha prima já aderiu a minha posição: por enquanto, só vamos as baladas teens.

Ah, de onde tirei a idéia de que ir à padaria comprar pão é simples? Aguardem os próximos posts e descubram...

Existe sim vida após o feriado....

Depois de uma semana confusa, sem horários definidos na faculdade, matando e assistindo palestras, montando relatórios e tentando aprender interfaces gráficas para Pascal, a garota alcançou o feriado.
Meio da semana: quinta-feira, o último do ano: tinha que fazer algo! Era sua última chance de derramar no sangue gotas generosas de adrenalina. Tentou convencer um certo par de olhos azuis a, como antes dessa vida 'uni', fazer uns programas pessoais e imensuráveis. O par de olhos já tinha compromisso: levantar ferro em uma competição... Mas essa agora, Meu Deus?
Era justamente a frase que passou naquela cabeça ansiosa por anestesias. Que fosse outro tipo de programa, então.
Voltou ao telefone, fulano, sicrano, amiga, colega, turma da faculdade... Ninguém! Todos com 'n' coisas a fazer. Restou-lhe apenas a opção de sua própria companhia. Munida de algumas notas, encontrou uma bela garrafa na lojinha da esquina, outra parada na locadora e já possuía mais uma diversão.
Taças, efeitos especiais, luzes, frio... Combinação bombástica, que alterou completamente os sentidos da garota. Nem se lembra como conseguiu acertar o horário do alarme para hoje. Só acordou sentindo todos os efeitos do evento anterior.
Banho gelado, ônibus vazio, trânsito livre, consegui chegar rapidamente a empresa. Teve que aprender a controlar o ar-condicionado e a iniciar o servidor. Não planejava isso, não acretida, até agora, em como tudo em seu dia esteja funcionando perfeitamente. Já chegara ao início da tarde e conseguiu cumprir tudo que traçou. E ainda por cima está animada para aula.
Noite adentro, aguarda ansiosa o resultado das avaliações de álgebra linear, e lá no fundo sente, que todo dará certo, porque, afinal, a vida depois do feriado, toca um jazz harmonioso...

P2 - Modelos de Processo de Software

O processo de Software

---

A utilização de um processo de software têm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software.

Para poder melhor compreender o assunto é necessário definir o que é um processo de software.

Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1] trás a seguinte definição:

"[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software".

Jalote[7] conclui que um processo de software é :

"é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo. Obviamente , um processo que não aumenta a produção (não suporta projetos de software grandes) ou não pode produzir software com boa qualidade não é um processo adequado."

A partir destas definições podemos considerar que de forma geral um processo de software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um produto de software. Na definição de um processo de software devem ser consideradas as seguintes informações: atividades a serem realizadas, recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado [3].

Sucintamente podemos definir o processo de software (defini-lo(o processo) como um conjunto de atividades uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir um certo objetivo.

Humphrey[4] define as seguintes razões para a definição de um processo padrão:

• Redução dos problemas relacionados a treinamento, revisões e suporte à ferramentas;

• ?As experiências adquiridas nos projetos são incorporadas ao processo padrão e contribuem para melhorias em todos os processos definidos;

• ?Economia de tempo e esforço na definição de novos processos adequados a projetos.

Fases de um processo de Software

Para Schwartz[5] as principais fases de um processo de software são :

1. Especificação de Requisitos: tradução da necessidade ou requisito operacional para uma descrição da funcionalidade a ser executada.
2. Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema.
3. Programação (Codificação): produção do código que controla o sistema e realiza a computação e lógica envolvida.
4. Verificação e Integração (Verificação): verificação da satisfação dos requisitos iniciais pelo produto produzido.

   Ao contrário do que possa parecer não existe uma sequência obrigatória de fases, sendo que diversos autores apontam a natureza não-simultânea das fases como uma realidade na aplicação de processos de software, e também defendem que o processo de software é muito mais iterativo e cíclico do que a idéia de fases simples pode sugerir.[6]
   

   Atividades do Processo de Software

   Em cada fase de um processo de software definido são executadas as atividades básicas para que sejam atingidos os objetivos propostos. Segundo Pressman[2] estas atividades constituem um conjunto mínimo para se obter um produto de software.

   Realizando uma combinação de classificações dadas por Schwartz[5] , Pressman[2] e Sommerville[1] podemos identificar as seguintes atividades[6]:

1. Especificação
   1. Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extra-software.
   2. Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento.
   3. Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.
2. Projeto
   1. Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.
   2. Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.
   3. Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.
3. Implementação
   1. Codificação: a implementação em si do sistema em uma linguagem de computador.
4. Validação
   1. Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.
   2. Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.
5. Manutenção e Evolução
   1. Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.

Desta forma as atividades relacionadas a um processo de software estão diretamente vinculadas com a produção do software como produto final . Afim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software.

Modelos de Processo de Desenvolvimento de Software

Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às situações a analisar, porque só na altura em que enfrentamos o problema é que podemos escolher o modelo.

Nos modelos de processo de software é dado uma atenção especial à representação abstrata dos elementos do processo e sua dinâmica, não estabelecendo métodos de desenvolvimento, pois este trabalha num nível mais alto de abstração do que os modelos de ciclo de vida.WWW[7]

A seguir descrevemos os principais modelos :

O modelo Cascata

Modelo idealizado por Royce em 1970 , também conhecido como abordagem ‘top-down’ , tem como principal característica a sequência de atividades onde cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase. Sofreu diversas ajustes e aprimoramentos sendo muito utilizado nos dias atuais.

Descrição Visual do Modelo

A ideia principal do modelo é que as diferentes etapas de desenvolvimento seguem uma sequência, ou seja,

a saída da primeira etapa "fluí" para a segunda etapa e a saída da segunda etapa "fluí" para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.

O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata, designado por modelo em cascata

revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que

entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.[8]

As desvantagens deste modelo são :

• Dificuldade em acomodar mudanças depois que o processo está a ser executado;

• Partição inflexível do projeto em estágios distintos;

• Dificuldade em responder a mudanças dos requisitos;

• É mais apropriado quando os requisitos são bem compreendidos;

• Os projetos reais raramente se adaptam ao modelo linear e sequencial;

• É difícil capturar os requisitos de uma só vez;

• Cliente tem de pacientemente esperar o resultado final;

• Os programadores são frequentemente atrasados sem necessidade;

• Alto custo de correção das especificações quando nas fases de Teste e Implantação.

Modelo Espiral

Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando um versão de um software executável.

O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses paradigmas.

Entretanto a integração não se dá através da simples incorporação de características dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de

avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos.

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de

objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco.Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.

Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral, que podem ser:

- comunicação com o cliente;
- planejamento;
- análise de risco;
- engenharia;
- construção e liberação;
- avaliação do cliente.

O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável.

Vantagens deste modelo

• modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.

• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.

Desvantagens

• Pode ser difícil convencer grandes clientes ( particularmente em situações de contrato) de que a abordagem evolutiva é controlável.

• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.

• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.

• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Modelo de do processo de desenvolvimento iterativo e incremental

Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.

O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais.Por isso, é mais prático dividir o trabalho em partes menores ou iterações.Cada iteração resultará num incremento.

Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.

O princípio subjacente ao processo incremental e iterativo é que a equipa envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.

Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar a viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de desenho e implementação.Numa segunda geração,

deve-se concluir a análise, fazer uma parte significativa do desenho e um pouco mais de implementação.

Numa terceira iteração, deve-se concluir o desenho, fazer-se parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principal consequência da aproximação iterativa é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de produtos finais.

A cada iteração são realizadas as seguintes tarefas:

- Análise (refinamento de requisitos, refinamento do modelo conceitual)

- Projeto (refinamento do projeto arquitetural, projeto de baixo nível)

- Implementação (codificação e testes)

-Transição para produto (documentação, instalação, ...)

Vantagens do processo incremental e iterativo

- Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar;

- Redução dos riscos envolvendo custos a um único incremento.Se a equipa que desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração,

não o valor de um produto inteiro;

- Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento;

- Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidos de alterações futuras;

- Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha de comunicação daí resultante;

Modelo de Prototipagem

O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações do modelo cascata. De acordo com Jalote[6] a idéia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos. Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os requisitos do sistema.

A sequência de eventos deste modelo esta exibido na figura abaixo:

O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos. Depois do protótipo estar pronto o cliente o utiliza e baseado na sua avaliação do cliente é fornecido ao as impressões do que precisa ser alterado, o que esta faltando e o que não é preciso. O protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos. [9]

Segundo Pressman e Jalote este modelo pode trazer os seguintes benefícios:

• O modelo é interessante para alguns sistemas de grande porte nos quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos
• È possível obter uma verão do que será o sistema com um pequeno investimento inicial
• A experiência de produzir o protótipo pode reduzir o custo das fases posteriores
• A construção do protótipo pode demonstrar a viabilidade do sistema.

Questões a serem consideradas quanto a utilização do modelo:

• A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no projeto
• Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de prototipação
• Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente será o mesmo do sistema final
• Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções etc)
• Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final

Conclusão

Não existe um processo correto ou incorreto , como não existe um modelo de desenvolvimento que seja a panacéia universal para o problema do desenvolvimento de software.

Dependendo de sua aplicação , ambiente e objetivo , a utilização de um processo ou modelo específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado e usar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo de desenvolvimento.

Referências:

[1] SOMMERVILLE, I. Software engineering. 5th. ed. Addison-Wesley, 1995.

[2] PRESSMAN, R. S. , Software engineering: A practitioner's approach. 4th. ed. McGraw-Hill, 1997. p. 22-53.

[3] Falbo, Ricardo A., Integração de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro, Brasil, 1998.

[4] Humphrey, Watts S., Managing the Software Process. Addison-Wesley Publishing,Company, Massachussets, 1990.

[5] SCHWARTZ, J. I. ,Construction of software. In: Practical Strategies for Developing Large Systems. Menlo Park: Addison-Wesley, 1st. ed., 1975.

[6] Christian Reis . , Caracterização de um Modelo de Processo para Projetos de Software Livre .teste de mestrado.Instituto de Ciências Matemática e Computação. São Carlos, São Paulo Abril de 2001

WWW[7] http://www.administradores.com.br/colunas_membro.jsp?idColuna=233&idColunista=555 - Glaucia Gabriel Sass - O Processo de Desenvolvimento Baseado em Componentes: O impulso das novas tecnologias , acessado em 19 de agosto de 2005.

---

sobre palestras e tempo livre

É fácil imaginar que não conseguiriam exercer controle supremo sobre o comparecimento dos alunos na palestra. Só esta que vos escreve é que imaginou que teria que comparecer e ouvir atentamente... Ela até assistiu uma parte da bendita. Mas depois, como todos os outros alunos, sentou-se no laboratório e deu prosseguimento a suas atividades acadêmicas com vencimento para semana seguinte.
Se está se sentindo culpada? Sim, ela está! Só, que consegue guardar esse sentimento lá na caixinha: "culpa para se sentir nos momentos de ócio", e já que essa palavra não existe mais no seu dicionário, acredita que poderá dormir em paz.

P1 - Data Warehouse

O Que é Data Warehouse

Escrito por Carlos Alberto Sowek

Buscando dar uma melhor visão sobre uma proposta de arquitetura de um Data Warehouse para a Celepar, bem como para os clientes da Celepar, sentimos a necessidade de elaborar alguns documentos para estabelecer um entendimento comum sobre alguns termos utilizados, e que as vezes não são bem compreendidos ou são usados de forma incorreta. Neste sentido elaboramos este documento que é uma tradução do tópico técnico divulgado pela Prism Solutions, Inc , volume 1 n. 1 escrito por W. H. Inmon "What is a Data Warehouse".

Data Warehouse é o centro da arquitetura dos sistemas de informações dos anos 90. Data Warehouse suporta processamento informatizado provendo uma plataforma sólida e integrada, com dados históricos dos quais se faz análises. Data Warehouse provê as facilidades para integração em um mundo de sistemas de aplicações não integrados. Data Warehouse organiza e armazena os dados necessários para processamento informatizado e analítico sobre perspectivas históricas ao longo do tempo.

Então o que é um Data Warehouse ?

Por Willian H. Inmon

"Data Warehouse é um banco de dados orientado por assunto, integrado, não volátil e histórico, criado para suportar o processo de tomada de decisão."

Fig. 1: O que é um Data Warehouse?

O dado entra no Data Warehouse vindo de um ambiente operacional em quase todos os casos. O Data Warehouse é sempre um armazenamento de dados transformados, separados fisicamente do ambiente operacional e da fonte do dado da aplicação.

Esta definição de um Data Warehouse (por W. H. Inmon) merece uma completa explanação, porque existem alguns detalhes importantes e sutilezas básicas nas características de um Warehouse.

• Orientado por Assunto

A primeira característica de um Data Warehouse é que ele está orientado ao redor do principal assunto da organização. O percurso do dado, orientado ao assunto está em contraste com a mais clássica das aplicações orientadas por processos/funcões ao redor dos quais os sistemas operacionais mais antigos estão organizados. Figura 2 mostra o contraste entre os dois tipos de orientações.

Figura 2: O Data Warehouse tem uma forte orientação por assunto

O mundo operacional está desenhado ao redor de aplicações e funções de uma instituição financeira assim como: empréstimo, crédito, cartão bancário. O mundo do Data Warehouse está organizado ao redor do principal assunto assim como cliente, vendas, produtos e atividades. O alinhamento ao redor das áreas de assunto afetam o desenho e implementação do dado criado no Data Warehouse. A área de assunto mais influente é a parte mais importante da estrutura chave.

O mundo das aplicações está preocupado com o desenho de processos e de banco de dados. O mundo do Data Warehouse está focado exclusivamente na modelagem de dados e desenho do banco de dados. Desenho de processos (como é na forma clássica) não é parte de um ambiente de Data Warehouse.

As diferenças entre aplicações orientadas por processos/funções e as orientadas por assunto mostra as diferenças no conteúdo dos dados e no nível de detalhes dos mesmos. No Data Warehouse são excluídos os dados que não devem ser usados no processo de DSS( Sistemas de Suporte a Decisão), enquanto no ambiente operacional as aplicações contêm dados para satisfazer imediatamente as requisições funcionais/processamento que podem ou não ser usadas para análise de DSS.

Outra importante maneira na qual os dados operacionais das aplicações diferem dos dados para Data Warehouse está no relacionamento dos dados. Dados operacionais mantêm relacionamentos entre duas ou mais tabelas baseadas nas regras de negócio que estão em efeito. Dados do Data Warehouse usam um espectro de tempo e os relacionamentos criados no Data Warehouse são muitos. Muitas regras de negócio são representadas no Data Warehouse entre duas ou mais tabelas.

• Integrado

Facilmente o mais importante aspecto do ambiente de Data Warehouse é que dados criados dentro de um ambiente de Data Warehouse são integrados. SEMPRE. COM NENHUMA EXCEÇÃO. A melhor essência do ambiente de warehouse é que dados contidos dentro dos limites do warehouse estão integrados. A integração mostra-se em muitas diferentes maneiras: na convenção consistente de nomes, na forma consistente das variáveis, na estrutura consistente de códigos, nos atributos físicos consistente dos dados, e assim por diante.

Contrastes e diferenças ao construir integração dentro do Data Warehouse com a falta de integração criada no ambiente das aplicações, são totais assim como mostrado pela figura 3

Fig. 3: Como dado orientado para aplicações é movido para Data Warehouse

A habilidade coletiva de muitos arquitetos de aplicações em criar aplicações inconsistentes é legendário. Figura 3 mostra algumas das muitas diferenças importantes na maneira como as aplicações são desenhadas.

Codificação - desenvolvedores de aplicações têm preferido codificar o campo SEXO de diferentes maneiras. Um desenvolvedor representa SEXO com um "M" e um "F". Outro desenvolvedor de aplicação representa SEXO com um "1" e um "0". Outro desenvolvedor de aplicação representa SEXO com um "x" e um "y". E ainda outro desenvolvedor de aplicação representa SEXO com "masculino" e "feminino". "M" e "F" são provalvelmente bons para algumas representações. Entretanto quando SEXO é carregado para o Data Warehouse de uma aplicação onde tem sido representado em outro formato que não "M" e "F", o dado deve ser convertido para o formato do Data Warehouse.

Forma dos atributos - desenvolvedores de aplicações têm preferido ao longo dos anos usar uma variedade de medidas. Um desenvolvedor armazena dados em centímetros. Outro desenvolvedor armazena em polegadas. Outro desenvolvedor de aplicação armazena dados em milhões de pés cúbicos por segundo. E outro desenvolvedor armazena informações em termos de jardas. Quando a informação chega no Data Warehouse é necessário ser mensurada de algum modo.

Figura 4

Como mostra a figura 3, o uso da integração afeta sempre alguns aspectos do desenho, as características físicas do dado, o dilema de ter mais de uma fonte do dado, o uso de padrões de nomes inconsistentes, formatos de dados inconsistentes, e assim por diante.

Enquanto o analista de DSS olha o Data Warehouse, o foco do analista deve ser no uso do dado que está no Data Warehouse, melhor que surpreender-se sobre a credibilidade ou consistência do dado.

• Histórico

Todo dado no Data Warehouse é exato em algum momento do tempo. A característica básica do dado em warehouse é ter muitas fontes de dados diferentes no ambiente operacional. No ambiente operacional o dado é exato no momento do acesso. Em outras palavras, no ambiente operacional quando você acessa uma unidade do dado, você espera que isto deva refletir os valores corretos no momento do acesso.

Por causa do dado em Data Warehouse ser exato em algum momento do tempo (isto é, não "correto no momento"), dado criado no warehouse é dito ser "histórico". Figura 4 mostra os valores históricos do dado no warehouse.

Os valores históricos dos dados no Data Warehouse são mostrados em várias maneiras. O modo mais simples é que o dado no Data Warehouse representa os dados sobre um horizonte de tempo distante - de 5 até 10 anos. O horizonte de tempo representado pelo ambiente operacional é muito curto - do valor corrente do dia até o sexto ou nono dia.

O segundo modo que "histórico" é mostrado no Data Warehouse é na estrutura chave. Sempre na estrutura chave do Data Warehouse existe - explicitamente ou implicitamente - um elemento de tempo, assim como dia, semana, meses, etc. O elemento de tempo está quase sempre no final da chave concatenada criada no Data Warehouse. Em certas ocasiões, o elemento de tempo deverá existir implicitamente, assim como no caso onde um arquivo todo é duplicado no final do mês.

A terceira maneira que "histórico" aparece no Data Warehouse, uma vez o registro estando correto, não pode ser atualizado. Dado no Data Warehouse e, para todos os propósitos práticos, é uma série longa de snapshots. Naturalmente se os snapshots do dado têm sido feitos incorretamente, eles não são alterados uma vez feitos. Em alguns casos isto pode ser sempre ilegal podendo os snapshots no Data Warehouse serem alterados. Dados operacionais, iniciam pontualmente no momento do acesso, podendo ser atualizados quando surgir a necessidade.

• Não Volátil

A quarta característica definida para um Data Warehouse é que ele é não volátil. Figura 5 ilustra este aspecto no Data Warehouse.

Figura 5

Na figura 5 abaixo, mostra que atualizações - inclusão exclusão, e alteração - são feitas regularmente no ambiente operacional de um registro básico. Mas a manipulação de dados básicos que ocorre no Data Warehouse é mais simples. Tem somente duas espécies de operações que ocorre no Data Warehouse - a carga inicial do dado, e o acesso ao dado. Esta não é uma atualização do dado (no sentido geral de atualização) no Data Warehouse como parte normal do processamento.

Estas são mais algumas das diferenças básicas entre processamento operacional e processamento do Data Warehouse. Para o nível de desenho, existe a necessidade de ter cautela nas atualizações anormais, o que não é um fato importante no Data Warehouse, atualizações neste dado não são feitas. Existem meios para que no nível físico do desenho, permissões possam ser feitas para otimizar o acesso ao dado, particularmente em procedimentos com o uso de normalização e desnormalização física. Outras conseqüências da simplicidade das operações do Data Warehouse estão na tecnologia básica usada para rodar no ambiente de Data Warehouse. Como suporte para atualização de registro por registro em modo on-line requer uma tecnologia com uma fundamentação muito complexa em baixo da simplicidade de uso. A tecnologia que suporte backup, recovery, transação com integridade do dado, a detecção e correção de deadlock é muito complexa. Isto não é necessário para processamento de Data Warehouse.

As características de um Data Warehouse - desenho orientado ao assunto, integração dos dados com o Data Warehouse, histórico, e simplicidade de gerenciamento dos dados - todos conduzem para um ambiente que é MUITO, MUITO diferente do ambiente operacional básico.

A fonte para aproximar todos os dados do Data Warehouse é o ambiente operacional. Isto é uma tentação para pensar que isto é mais uma redundância do dado entre os dois ambientes. De fato, na primeira impressão muitas pessoas acham que é uma grande redundância de dados entre o ambiente operacional e o ambiente de Data Warehouse. Mas este entendimento superficial é a necessidade de demonstrar o que está ocorrendo no Data Warehouse. Em fato, este é um MÍNIMO de redundância do dado entre o ambiente operacional e o ambiente de Data Warehouse.

Considere o seguinte:

• dado é filtrado quando passa do ambiente operacional para o ambiente de Data Warehouse. Muitos dados nunca saem do ambiente operacional. Somente o dado que é necessário para o processamento do DSS é encontrado no ambiente warehouse;
  
• o histórico do dado é muito diferente de um ambiente para outro. Dado no ambiente operacional é muito recente. Dado no warehouse é muito antigo. Só na perspectiva de histórico recente, é muito pequeno o overlap entre o ambiente operacional e o ambiente de Data Warehouse;
  
• o Data Warehouse contém dados sumarizados que nunca são encontrado no ambiente operacional;
  
• dados sofrem uma fundamental transformação ao passar para o Data Warehouse. Figura 3 mostra que muitos dados são alterados significativamente após serem selecionados e movidos para o Data Warehouse. Dito de outra maneira, muitos dados são fisicamente e radicalmente alterados quando movidos para o warehouse. Estes dados não são os mesmos que residem no ambiente operacional do ponto de vista de integração.

Para clarear esses fatores, redundância de dados entre os dois ambientes é uma ocorrência rara, resultando em menos que 1% de redundância entre os dois ambientes.

Fonte:http://www.pr.gov.br/batebyte/edicoes/1997/bb62/warehouse.htm

Jornada Acadêmica

Essa semana, na facul, temos uma tal de 'jornada acadêmica': palestras, mini-cursos, lanches....
Dizem que serve para os adquirirem conhecimentos, visão de mercado, vejam possibilidades de atuação na área, dentre outras coisas.
Já eu, baseada nos meus conhecimentos universitários, desconfio que seja só uma forma de relaxar os alunos estressasdos.
O melhor dessa semana, é que as palestras valem pontinhos. E pegando carona nessa paletras, farei uma semana de posts computacionais.
Espero que alguém aproveite!

Semestre e Estresse

O que acontece com os alunos de uma turma perto do fim do semestre?
As pessoas estão tão concentradas em não perder notas que não pensam em mais nada. Fora os nervos de todos, ficam a flor da pele. Ninguém se incomoda com os sentimentos alheios, gritos, discussões acalouradas com professores, trabalhos... provas... Tudo gira ao redor daquele prédizinho que se denomina academia.
E o que fazer com as pessoas que acompanham a nossa vida? Estou a procura de soluções!

Tinha uma hora para resolver uma dúzia de problemas e ainda proveitar um pouqinho da atenção do garoto de olhos azuis. Não sabia por onde começar, tudo parecia muito urgente. Mas ficava difícil se concentrar em algo fora daqueles olhos: como um guia, eles a levaram a um restaurante, escolheram um prato e quase comeram por ela.
Pensando na pilha de coisas a serem levadas para o banco, dessa vez não se permitiu ser guiada: segurou nas mãos do garoto e o arrastou pelo caminho afora...
Fila! Espera! Desespero! Afagos...
Apesar dos pesares, o esperar se fazia agradável: em boa companhia, até fila no banco é bom!

Da série: Perguntas que adoraria obter as resposas...

Quando ficarei livre do escalonamento de matrizes???

Esperar ou não-esperar? Eis a questão!

A garota encontra-se em uma fase confusa: anota todos os equívos, ou seria descuidados?, cometidos pelos remetentes de e-mails enviados à ela. Já possui uma lista extensa com coisas do tipo: "tô escrevndo rapidinho, depois te ligo", "Hoje, num vai dar... talves semana que vêm", "Oi" - ao invés de um "Oi meu amor", "Á noite te mando um e-mail", "Mando o trabalho pra você hoje sem falta", e outras coisas do gênero.
E esta lista, gerou a coleção de expectativas, um grande buraco preenchido pera incerteza da espera. Afinal, ela sempre aguarda o retono, a ligação, o e-mail, a explicação, o "Oi meu amor"...
Verifica incansavelmente a caixa de mensagens, não consegue largar de lado. Logo ela, a garota que se orgulhava de não ficar sentada a espera dos outros; a pessoa que acha que é melhor plantar flores do que esperar um buquê se rosas. Logo ela...
Então, resguardada de sue nobre passado, agora, ela olha para o canto direito da tela e se pergunta:
"Esperar ou não-esperar? Eis a questão!"

Pausa para o trabalho

A DevMedia, grupo especializado em revistas sobre tecnologia, lançou uma nova revista na área, a Engenharia de software magazine, que como diz o nome, é especializada na área de engenharia de software, e tem o objetivo de levar ao mercado brasileiro de desenvolvimento de software conceitos e práticas associadas ao uso da engenharia de software. Por enquanto a publicação é gratuita e eu já baixei a minha...

Corram lá: www.devmedia.com.br/esmag/

Um Beijo Roubado

Esse foi o filme que fez meu feriado valer a pena! História diferente, uma outra visão de cinema. Adorei entrar em contado com uma nova 'cultura' cinematográfica, vê um filme através de janelas embaçadas e adquirir a expectativa de que nem sempre estmos prontos para um novo amor.
Fora a vontade de juntar tudo e sair passeando por aí... Mesmo que seja com o coração partido nas mãos. Quem sabe na volta, terei uma torta me esprando no café de um homem lindo como o Jude.

Se assistirem, me digam o que acharam...