Aula 01 - Planeamento de Sistemas de Informação

2,027 views
1,827 views

Published on

Primeira aula no mestrado de Informação Empresarial da ESEIG, na disciplina de Planeamento de Sistemas de Informação

Published in: Technology
3 Comments
2 Likes
Statistics
Notes
  • Caro Pedro, Isto é o resultado da revisão de várias apresentações anteriores, criadas quer por mim quer por outros docentes. Posso dizer-lhe que grande parte é do célebre Somerville, Ian (2010). Software Engineering. 9 ed, Addison Wesley, e um pouco de Lopes, Filomena; Morais, Maria e Carvalho, Armando (2009). Desenvolvimento de Sistemas de Informac ̧ ̃ao. 2 ed, FCA. Espero que ajude.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Agradeço a partilha.
    Sou candidato a Phd na área da visualização da informação. É possível partilhar a bibliografia.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • material muito bom ...parabéns!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,027
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
83
Comments
3
Likes
2
Embeds 0
No embeds

No notes for slide

Aula 01 - Planeamento de Sistemas de Informação

  1. 1. Sistemas de Informa¸˜o ca Alberto Sim˜es o alberto.simoes@eu.ipp.ptPlaneamento de Sistemas de Informa¸˜o ca Mestrado em Informa¸˜o Empresarial ca 2012/2013 Alberto Sim˜es o Sistemas de Informa¸˜o ca 1/52
  2. 2. Parte IInforma¸˜o e Sistemas de Informa¸˜o ca ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 2/52
  3. 3. Informa¸˜o ca O que ´ a informa¸˜o? e ca O que a distingue de dados? E em que diferem do conhecimento? Conhecimento e sabedoria s˜o coisas diferentes? a Alberto Sim˜es o Sistemas de Informa¸˜o ca 3/52
  4. 4. Informa¸˜o caDados Conhecimento Factos num estado bruto que pode Combina¸˜o de instintos, ideias, ca ser moldado para criar informa¸˜o. ca regras, e procedimentos que guiam as ac¸˜es e decis˜es dos gestores. co o Consistem em n´meros, palavras, u s´ ımbolos relacionados com os ´ E a aplica¸˜o da informa¸˜o. ca ca eventos e processos de neg´cio. o Pode ser usado para responder aInforma¸˜o ca “como”. Obt´m-se pela sele¸˜o, e ca Sabedoria sumariza¸˜o e apresenta¸˜o de ca ca Processo extrapolativo, n˜o a dados de uma forma que seja util. ´ determin´ ıstico e probabil´ ıstico. Resultam de se atribuir um Processo de distinguir o correto do significado ou sentido aos dados. errado. Pode ser usada responder a Pode ser usada para responder a “quem” “o quˆ” “onde” e “quando” , e, ; “porquˆ” e. Alberto Sim˜es o Sistemas de Informa¸˜o ca 4/52
  5. 5. Informa¸˜o ca Sabedoria Discernimento Conhecimento Significado Informação Contexto Dados Alberto Sim˜es o Sistemas de Informa¸˜o ca 5/52
  6. 6. Informa¸˜o ca Informa¸˜o ´ o resultado do processamento, manipula¸˜o ca e ca e organiza¸˜o de dados, de tal forma que represente uma ca modifica¸˜o (quantitativa ou qualitativa) no ca conhecimento do sistema (pessoa, animal ou m´quina) a que a recebe. Serra, J. Paulo. Manual de Teoria da Comunica¸˜o ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 6/52
  7. 7. Sistema de Informa¸˜o ca O que ´, ent˜o, um Sistema de Informa¸˜o? e a ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 7/52
  8. 8. Sistema de Informa¸˜o ca Sistema tecnol´gico que manipula, armazena e dissemina o s´ ımbolos (representa¸˜es) que tˆm, ou s˜o supostos ter, co e a relevˆncia e impacto no comportamento humano a organizado socialmente Hirschheim, 1996 Alberto Sim˜es o Sistemas de Informa¸˜o ca 8/52
  9. 9. Sistema de Informa¸˜o ca ´ E o meio que providencia os meios de armazenamento, gera¸˜o e distribui¸˜o de informa¸˜o com o objectivo de ca ca ca suportar as fun¸˜es de opera¸˜o e gest˜o de uma co ca a organiza¸˜o ca Layzell & Loucoupolus (1987) Alberto Sim˜es o Sistemas de Informa¸˜o ca 9/52
  10. 10. Sistema de Informa¸˜o ca ´ E um sistema que recolhe, processa, armazena e distribui informa¸˜o relevante para a organiza¸˜o [. . . ], de modo a ca ca que a informa¸˜o seja acess´ e util para aqueles que ca ıvel ´ dela necessitam, incluindo gestores, funcion´rios, clientes, a [. . . ]. Buckingham (1987) Alberto Sim˜es o Sistemas de Informa¸˜o ca 10/52
  11. 11. Sistema de Informa¸˜o ca Meio Ambiente Organização Entrada Processamento Saída Experiência Alberto Sim˜es o Sistemas de Informa¸˜o ca 11/52
  12. 12. Sistema de Informa¸˜o ca Exemplo: Reservas num Hotel Computador Base de Dados Reservas Sistema Computador Relatórios Computacional Computador Entrada Processamento Saída Alberto Sim˜es o Sistemas de Informa¸˜o ca 12/52
  13. 13. Sistema de Informa¸˜o caCaracter´ ısticas Objetivo: orientar a tomada de decis˜es. o Componentes: dados, m´dulos de processamento de dados, o canais de comunica¸˜o. ca Estrutura: forma como os diferentes m´dulos de o processamento de dados est˜o ligados entre si. a Comportamento: conjunto de procedimentos necess´rios para a obter, processar e difundir os dados. Ciclo de Vida: altera¸˜es ao SI ocorrem de acordo com as co mudan¸as na organiza¸˜o (ou no ambiente). c ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 13/52
  14. 14. Sistemas de Informa¸˜o caTaxonomia Sistema de Processamento de Transa¸˜es co Recolhe e mant´m informa¸˜o sobre transa¸˜es e controla pequenas e ca co decis˜es que fazem parte das transa¸˜es. o co Sistema de Informa¸˜o de Gest˜o ca a Converte informa¸˜o sobre transa¸˜es em informa¸˜o para a gest˜o ca co ca a da organiza¸˜o. ca Sistema de Apoio ` Decis˜o a a Ajuda os utilizadores na tomada de decis˜es n˜o estrutur´veis, o a a fornecendo-lhes informa¸˜o, modelos e ferramentas para analisar a ca informa¸˜o. ca Sistema Pericial Suporta os profissionais do desenho, diagn´stico e avalia¸˜o de o ca situa¸˜es complexas que requerem conhecimento especializado em co ´reas bem definidas. a Sistema de Automa¸˜o de Escrit´rio ca o Mant´m as tarefas de comunica¸˜o e processamento de informa¸˜o. e ca ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 14/52
  15. 15. Parte IIEngenharia de Software Alberto Sim˜es o Sistemas de Informa¸˜o ca 15/52
  16. 16. Software O software ´ um elemento l´gico e n˜o f´ e o a ısico; O software ´ projetado e desenvolvido, mas n˜o ´ e a e manufaturado; O software n˜o se desgasta: a n˜o necessita de substitui¸˜o per se; a ca mas deteriora-se devido ` mudan¸a; a c a manuten¸˜o ´ mais complexa do que no HW; (por vezes ´ ca e e for¸ada pela manuten¸˜o do HW) c ca no software raramente existe a possibilidade de substituir pe¸as c deterioradas; A maior parte do software continua a ser feito ` medida, e n˜o a a produzido a partir de componentes j´ existentes; a mas a industria de software est´ a mover-se para o uso de a componentes reutiliz´veis (Component Based Assembly); a Alberto Sim˜es o Sistemas de Informa¸˜o ca 16/52
  17. 17. Caracter´ ısticas Desej´veis no Software a Flexibilidade F´cil evolu¸˜o face aos requisitos ou altera¸˜es do modelo de a ca co neg´cio; o Fiabilidade Os problemas devem ser minimizados para n˜o por em causa a o funcionamento das organiza¸˜es; co Funcionalidade Implementa¸˜o das necessidades das organiza¸˜es; ca co Desempenho N´ adequado de desempenho (respostas na altura certa); ıvel Usabilidade Interface amig´vel, intuitiva e ergon´mica. a o Alberto Sim˜es o Sistemas de Informa¸˜o ca 17/52
  18. 18. Problemas no Desenvolvimento de Software O software ´ cada vez mais complexo e usado por um n´mero e u cada vez maior de pessoas; As falhas de software provocam preju´ ızos incalcul´veis; a quanto mais tarde surge um erro mais caro ´ corrigi-lo e Grande parte dos projectos de software falham: Funcionalidades desej´veis n˜o implementadas; a a Custos mais elevados que o estipulado; Entrega muito al´m do prazo previsto; e Falta de recursos especializados. A qualidade do software nem sempre ´ a adequada; e O software (existente) ´ muito dif´ de manter; e ıcil Alberto Sim˜es o Sistemas de Informa¸˜o ca 18/52
  19. 19. Engenharia de Software A Engenharia de software ´ uma ´rea do conhecimento e a da Engenharia Inform´tica e das Ciˆncias da a e Computa¸˜o, voltada para a especifica¸˜o, ca ca desenvolvimento, teste e manuten¸˜o de sistemas de ca software aplicando tecnologias e pr´ticas de gest˜o de a a projetos e outras disciplinas. Adaptado da Wikipedia (2011) Alberto Sim˜es o Sistemas de Informa¸˜o ca 19/52
  20. 20. Engenharia de Software “Engenharia de Software ´ a cria¸˜o e a utiliza¸˜o de e ca ca s´lidos princ´ o ıpios de engenharia a fim de obter software de maneira econ´mica, que seja fi´vel e que trabalhe o a eficientemente em m´quinas reais” a Friedrich Ludwig Bauer Adaptado da Wikipedia (2011) Alberto Sim˜es o Sistemas de Informa¸˜o ca 20/52
  21. 21. Princ´ ıpios na Engenharia de Software Rigor e Formalidade: maior objetividade e redu¸˜o de focos de ambiguidade; ca Separa¸˜o dos assuntos: ca v´rias perspetivas do sistema; a Modularidade: divis˜o por m´dulos para maior reutiliza¸˜o e compreens˜o; a o ca a Abstra¸˜o: ca imprescind´ para compreender e analisar problemas ıvel complexos; Antecipa¸˜o da mudan¸a: ca c maior capacidade de evolu¸˜o, logo mais tempo de vida; ca Generaliza¸˜o: ca garantia de maior flexibilidade e reutiliza¸˜o; ca Desenvolvimento Incremental: maior rapidez na dete¸˜o de erros; ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 21/52
  22. 22. Parte IIIModelos de Desenvolvimento de Software Alberto Sim˜es o Sistemas de Informa¸˜o ca 22/52
  23. 23. Modelos de Desenvolvimento de Software Modelos de Desenvolvimento de Software definem sequˆncia de processos para o desenvolvimento de e software; definem modelo de intera¸˜o entre estes processos; ca tipicamente compostos pelas etapas: Planeamento An´lise a Desenho Implementa¸˜o ca Verifica¸˜o ca Manuten¸˜o ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 23/52
  24. 24. Modelos de Desenvolvimento de Software Planeamento Or¸amenta¸˜o, defini¸˜o da equipa, c ca ca planeamento temporal pelas etapas seguintes; An´lise Recolha e defini¸˜o dos requisitos do sistema, a ca restri¸˜es, requisitos de hardware, etc; co Desenho Planeamento do sistema, defini¸˜o das estruturas de ca dados, defini¸˜o do fluxo de dados dentro do sistema; ca Implementa¸˜o Codifica¸˜o do sistema desenhado numa ou ca ca mais linguagens de programa¸˜o; ca Verifica¸˜o Testes do sistema com os utilizadores, e em ca situa¸˜es pseudo-reais. Verifica¸˜o de consistˆncia de dados e co ca e das opera¸˜es; co Manuten¸˜o Instala¸˜o do sistema na organiza¸˜o, forma¸˜o ca ca ca ca de utilizadores. Manuten¸˜o do sistema ao longo do tempo, ca corrigindo erros, adicionando pequenas funcionalidades ou simplesmente garantindo o seu bom funcionamento. Alberto Sim˜es o Sistemas de Informa¸˜o ca 24/52
  25. 25. Modelos Lineares e Incrementais Modelo Sequencial Linear (Cascata cl´ssico) a Modelo Cascata Modificado Modelo baseado em Prototipagem Modelo Incremental (Cascata Incremental) Modelo em Espiral Alberto Sim˜es o Sistemas de Informa¸˜o ca 25/52
  26. 26. Modelo Sequencial Linear Planeamento Análise Desenho Implementação Verificação Sistema Manutenção Alberto Sim˜es o Sistemas de Informa¸˜o ca 26/52
  27. 27. Modelo Sequencial LinearOrigem Desvantagens Modelo proposto por Winston ´ E impens´vel que se consigam a Royce em 1970 e o mais usado definir corretamente os at´ meados de 1980; e requisitos no in´ do projeto; ıcio ´ imposs´ realizar altera¸˜es E ıvel coVantagens ao longo do seu curso; Torna o desenvolvimento O sistema s´ existir´ no final do o a estruturado (estrutura simples, projeto; linear) e disciplinado; Se durante uma fase se Eficiente quando os requisitos encontra um problema, n˜o ´ a e s˜o claros e bem entendidos; a poss´ tˆ-lo em conta; ıvel e F´cil previsibilidade de custos e a Qualquer atraso numa das fases prazos, permitindo o leva a um atraso geral de todo planeamento do projeto. o projeto. Modelo demasiado r´ ıgido. Alberto Sim˜es o Sistemas de Informa¸˜o ca 27/52
  28. 28. Modelo Cascata Modificado Planeamento Análise Desenho Implementação Verificação Sistema Manutenção Alberto Sim˜es o Sistemas de Informa¸˜o ca 28/52
  29. 29. Modelo Cascata ModificadoOrigem Vantagens Surgiu na sequˆncia dos problemas e Permite agilizar o desenvolvimento identificados no modelo em de partes do sistema mais simples; cascata tradicional; ´ E poss´ retroceder e resolver ıvel Principal diferen¸a ´ a c e problemas de fases anteriores; possibilidade de sobrepor as etapas do modelo, e poder retroceder para Devido ` continuidade entre fases, a uma etapa anterior; a documenta¸˜o pode ser ca substancialmente reduzida;Desvantagens Permite uma abordagem mais Sistema s´ dispon´ no final do o ıvel relaxada dos procedimentos projeto; formais; Atividades paralelas sujeitas a Resolve praticamente todas as falhas de comunica¸˜o; ca desvantagens do modelo em A equipa pode ser tentada a cascata linear. avan¸ar e recuar nas fases, c conduzindo a atrasos; Alberto Sim˜es o Sistemas de Informa¸˜o ca 29/52
  30. 30. Modelo Incremental Planeamento Análise Análise Desenho Implementação Análise Verificação Versão do Desenho Sistema Implementação Verificação Análise Versão do Desenho Sistema Implementação Verificação Versão do Sistema Manutenção Alberto Sim˜es o Sistemas de Informa¸˜o ca 30/52
  31. 31. Modelo IncrementalOrigem Vantagens Tentativa de tornar o modelo O cliente recebe Feedback a tradicional num modelo cada incremento; incremental; Disponibilidade de partes N˜o ´ mais que a repeti¸˜o do a e ca prontas do sistema mais cedo; modelo tradicional, adicionando Facilidade nos testes, uma vez requisitos a cada itera¸˜o; ca que se testa cada incremento;Desvantagens Menor custo e menos tempo Dif´ or¸amenta¸˜o do projeto; ıcil c ca para a entrega da primeira Nem todo o sistema pode ser vers˜o; a dividido por etapas; Riscos associados aos Se os requisitos n˜o est˜o bem a a incrementos s˜o menores; a definidos, alguns incrementos podem levar ` sua a reimplementa¸˜o. ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 31/52
  32. 32. Modelo Baseado em Prototipagem Planeamento Análise Desenho Implementação Protótipo Implementação Validação Validação Sistema Alberto Sim˜es o Sistemas de Informa¸˜o ca 32/52
  33. 33. Modelo Baseado em PrototipagemOrigem Vantagens Uma reorganiza¸˜o do modelo ca Valida requisitos rapidamente; iterativo; Atenua riscos numa fase avan¸ada c Em vez de se basear em vers˜es o de desenvolvimento; do sistema, baseia-se em Forma efetiva de desenvolver prot´tipos; o interfaces com o utilizador;Desvantagens Permite demonstrar ` a O prot´tipo nem sempre pode o administra¸˜o a utilidade e ca ser aproveitado no praticabilidade do sistema; desenvolvimento do sistema Prot´tipo pode ser usado para o final; treinar utilizadores mesmo antes Esta reimplementa¸˜o pode ca do sistema estar dispon´ıvel; levar a um aumento dos custos; Muitas vezes partes dos prot´tipos o podem ser reutilizadas no desenvolvimento do sistema final. Alberto Sim˜es o Sistemas de Informa¸˜o ca 33/52
  34. 34. Modelo em Espiral 1.Determine 2. Identify and objectives resolve risks Requirements Operational plan Prototype 1 Prototype 2 prototype Concept of Concept of operation requirements Detailed Requirements Draft design Development Verification Code plan & Validation Integration Test plan Verification & Validation Test 4. Plan the next iteration Implementation 3. Development Release and Test Alberto Sim˜es o Sistemas de Informa¸˜o ca 34/52
  35. 35. Modelo em EspiralOrigem Desvantagens Definido por Barry Boehm em Complexidade do modelo; 1986; Dificuldade em seguir de forma Abordagem cascata intercalada estrita; com prot´tipos; o A an´lise de risco global do aVantagens projeto exige treino, aptid˜es o Evolu¸˜o do software e dos ca pr´prias e um esfor¸o o c requisitos ao longo do tempo; consider´vel; a V´rias itera¸˜es com o cliente a co Apenas adequado a grandes diminuem riscos de m´ an´lise; a a projetos; Mant´m uma abordagem e sistem´tica por etapas, a incorporando o modelo de ciclo de vida cl´ssico num quadro a iterativo; Alberto Sim˜es o Sistemas de Informa¸˜o ca 35/52
  36. 36. Parte IVArquiteturas de Software Alberto Sim˜es o Sistemas de Informa¸˜o ca 36/52
  37. 37. Arquitetura de Software A arquitetura de software de um sistema ´ um conjunto e de estruturas necess´rias para refletir sobre o sistema, a que incorpora elementos de software, rela¸˜es entre eles, co e respetivas propriedades. Existe um conjunto de padr˜es, ou arquiteturas modelo, o que orientam o desenvolvimento de sistemas de acordo com a sua fun¸˜o e requisitos. ca Alberto Sim˜es o Sistemas de Informa¸˜o ca 37/52
  38. 38. Arquitetura de SoftwareSistemas Embebidos Alberto Sim˜es o Sistemas de Informa¸˜o ca 38/52
  39. 39. Arquitetura de SoftwareSistemas Embebidos ´ E um sistema computacional desenhado para fazer um n´mero u limitado de fun¸˜es; co Habitualmente tˆm restri¸˜es temporais (real-time); e co ´ embebido como parte de um sistema completo, que E habitualmente inclui partes mecˆnicas; a Os sistemas embebidos controlam aparelhos usados todos os dias: micro-ondas, frigor´ ıficos, monitores, autom´veis, GPS, etc. o Depois de instalado o sistema embebido pode n˜o ser pass´ a ıvel de ser substitu´ ıdo; (mas muitas vezes parte do seu software por ser atualizado) Alberto Sim˜es o Sistemas de Informa¸˜o ca 39/52
  40. 40. Arquitetura de SoftwareSistemas Embebidos Sistema Real-Time ´ E um sistema de software cujo funcionamento correto depende dos resultados produzidos e do instante em que s˜o a produzidos. Os sistemas podem ser considerados soft-real-time, se o sistema se degradar quando os resultados n˜o s˜o produzidos a a nos requisitos temporais definidos; Ou sistemas hard-real-time, se o sistema falhar completamente quando os resultados n˜o s˜o produzidos nos a a requisitos temporais definidos; Alberto Sim˜es o Sistemas de Informa¸˜o ca 40/52
  41. 41. Arquitetura de SoftwareSistemas Monol´ ıticos Alberto Sim˜es o Sistemas de Informa¸˜o ca 41/52
  42. 42. Arquitetura de SoftwareSistemas Monol´ ıticos Aplica¸˜o unica, em que a interface e o acesso aos dados est˜o ca ´ a combinados num unico programa, numa unica plataforma; ´ ´ Aplica¸˜o auto-contida, e independente de outras aplica¸˜es ca co computacionais; A filosofia ´ que a aplica¸˜o ´ respons´vel por tudo, n˜o e ca e a a dependendo de quaisquer resultados de outras aplica¸˜es ou co bases de dados; Esta era a grande filosofia dos anos 70/80; Muitas aplica¸˜es banc´rias usadas atualmente ainda s˜o co a a resultado de um sistema monol´ıtico (em que se abriram algumas funcionalidades de interoperabilidade); Alberto Sim˜es o Sistemas de Informa¸˜o ca 42/52
  43. 43. Arquitetura de SoftwareSistemas Cliente–Servidor Alberto Sim˜es o Sistemas de Informa¸˜o ca 43/52
  44. 44. Arquitetura de SoftwareSistemas Cliente–Servidor Estrutura de aplica¸˜es distribu´ co ıdas, dividindo as tarefas entre os fornecedores do servi¸o (habitualmente designados por c servidores) e os requisitantes do servi¸o (habitualmente c designados por clientes). Habitualmente os clientes e servidores funcionam em hardware separado, e comunicam atrav´s de uma infraestrutura de rede. e (no entanto, ´ poss´ ter servidor e clientes a funcionar no e ıvel mesmo hardware) A m´quina de um servidor executa um ou mais programas a servidores que partilham os seus recursos com os clientes; Um cliente n˜o partilha nenhum dos seus recursos, mas envia a pedidos de conte´do ou funcionalidades do servidor; u Ou seja, a comunica¸˜o ´ sempre iniciada pelos clientes; ca e Alberto Sim˜es o Sistemas de Informa¸˜o ca 44/52
  45. 45. Arquitetura de SoftwareSistemas Cliente–Servidor Habitualmente cada cliente usa uma aplica¸˜o espec´ ca ıfica para aceder a servi¸o em causa; c A implementa¸˜o de um sistema baseado numa arquitetura ca cliente–servidor obriga (habitualmente) ao desenvolvimento de duas aplica¸˜es (servi¸o, e cliente); co c A maioria dos servi¸os na Internet usam esta arquitectura: c Servidores de e-mail (SMTP, POP3, IMAP), servidores de p´ginas (HTTP), servidores de ficheiros (FTP) entre outros; a Alberto Sim˜es o Sistemas de Informa¸˜o ca 45/52
  46. 46. Arquitetura de SoftwareSistemas Peer-to-peer Alberto Sim˜es o Sistemas de Informa¸˜o ca 46/52
  47. 47. Arquitetura de SoftwareSistemas Peer-to-peer Particiona tarefas ou cargas entre colegas/parceiros; Cada um destes parceiros tem privil´gios equivalentes; e S˜o participantes equipotentes na aplica¸˜o; a ca Diz-se que constituem uma rede peer-to-peer de nodos; Cada nodo partilha parte dos seus recursos, seja poder computacional, espa¸o em disco ou largura de banda, com os c restantes participantes; Alberto Sim˜es o Sistemas de Informa¸˜o ca 47/52
  48. 48. Arquitetura de SoftwareSistemas Peer-to-peer N˜o existe (nem h´ necessidade) de um nodo central que a a coordene esta partilha (que ´ contratada nodo a nodo); e Cada nodo ´, ao mesmo tempo, consumidor e produtor de e recursos (o que contrasta com o modelo cliente–servidor onde apenas os servidores produzem, e os clientes consomem); S˜o usadas essencialmente em aplica¸˜es de partilha de a co ficheiros, como Napster ou Torrent (embora este ultimo seja ´ h´ ıbrido com a arquitetura cliente–servidor). Algumas aplica¸˜es de comunica¸˜o, como o Skype, tamb´m co ca e usam este tipo de abordagem. Alberto Sim˜es o Sistemas de Informa¸˜o ca 48/52
  49. 49. Arquitetura de SoftwareSistemas Distribu´ ıdos Alberto Sim˜es o Sistemas de Informa¸˜o ca 49/52
  50. 50. Arquitetura de SoftwareSistemas Distribu´ ıdos Modelo gen´rico onde modelos P2P e C/S se inserem; e Uma rede em que sistemas de base de dados possam sincronizar de modo P2P ou C/S; Um conjunto de servidores que s˜o clientes dos sistemas de a base de dados, e que podem funcionar entre si em modo P2P, para distribuir cargas; Este n´cleo funciona como um servidor para atender um u n´mero grande de clientes; u Abordagem para grandes sistemas de computa¸˜o, com ca muitos clientes, e necessidade de distribui¸˜o de cargas; ca Principal problema ´ como proceder ` replica¸˜o das bases de e a ca dados paralelas; Alberto Sim˜es o Sistemas de Informa¸˜o ca 50/52
  51. 51. Arquitetura de SoftwareSistemas baseados em Barramento BUS de Comunicação Alberto Sim˜es o Sistemas de Informa¸˜o ca 51/52
  52. 52. Arquitetura de SoftwareSistemas baseados em Barramento Outra arquitetura distribu´ foca o modelo de comunica¸˜o; ıda, ca A comunica¸˜o ´ feita de todos para todos; ca e No entanto n˜o ´ baseada em Peer-to-Peer: a e cada cliente envia um pedido para um barramento ou quadro preto; cada servidor capaz de satisfazer esse pedido, recolhe o pedido do barramento, e volta a colocar a resposta no barramento; o cliente monitoriza o barramento e espera resposta; Esta abordagem permite facilmente aumentar o n´mero de u servidores de forma simples; ´ E poss´ introduzir n´ ıvel ıveis de indire¸˜o: um servidor pode ser ca cliente de outro servi¸o! c Alberto Sim˜es o Sistemas de Informa¸˜o ca 52/52

×