Este documento fornece um resumo sobre sistemas de informação e modelos de desenvolvimento de software. Discute o que é informação, sistemas de informação e suas características. Também explica os principais modelos de desenvolvimento de software e como eles definem processos e interações para o desenvolvimento de software.

1. Sistemas de Informa¸˜o
ca
Alberto Sim˜es
o
alberto.simoes@eu.ipp.pt
Planeamento 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. Parte I
Informa¸˜o e Sistemas de Informa¸˜o
ca ca
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 2/52

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. Informa¸˜o
ca
Dados 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 a
Informa¸˜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. Informa¸˜o
ca
Sabedoria
Discernimento
Conhecimento
Significado
Informação
Contexto
Dados
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 5/52

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. 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. 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. 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. 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. 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. 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. Sistema de Informa¸˜o
ca
Caracter´
ı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. Sistemas de Informa¸˜o
ca
Taxonomia
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. Parte II
Engenharia de Software
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 15/52

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. 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. 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. 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. 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. 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. Parte III
Modelos de Desenvolvimento de Software
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 22/52

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. 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. 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. 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. Modelo Sequencial Linear
Origem 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 co
Vantagens 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. 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. Modelo Cascata Modificado
Origem 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. 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. Modelo Incremental
Origem 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. 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. Modelo Baseado em Prototipagem
Origem 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. 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. Modelo em Espiral
Origem 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
a
Vantagens 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. Parte IV
Arquiteturas de Software
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 36/52

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. Arquitetura de Software
Sistemas Embebidos
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 38/52

39. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas Monol´
ıticos
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 41/52

42. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas Cliente–Servidor
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 43/52

44. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas Peer-to-peer
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 46/52

47. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas Distribu´
ıdos
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 49/52

50. Arquitetura de Software
Sistemas 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. Arquitetura de Software
Sistemas baseados em Barramento
BUS de Comunicação
Alberto Sim˜es
o Sistemas de Informa¸˜o
ca 51/52

52. Arquitetura de Software
Sistemas 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