Introducao a Arquitetura de Software

419 visualizações

Publicada em

Introducao a Arquitetura de Software

Publicada em: Engenharia
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
419
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
19
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Introducao a Arquitetura de Software

  1. 1. 1   Arquitetura  de  So-ware   Prof.  Adailton  Magalhães  Lima   2014.4  
  2. 2. 2   Agenda   Ø  Introdução   Ø  Arquitetura  &  Projeto  de  SoAware   Ø  Padrões  de  Projeto  
  3. 3. 3  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Em  Arquitetura  
  4. 4. 4  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Em  Arquitetura  
  5. 5. 5  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Em  Arquitetura  
  6. 6. 6   Em  So-ware   Ø  Dê  um  exemplo  de  soAware  “pequeno”;   Ø  Dê  um  exemplo  de  soAware  “grande”;   Ø  Qual  o  limite  de  um  soAware?   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  7. 7. 7   Arquitetura  de  So-ware   Introdução  e  Visão  Geral  
  8. 8. 8   Introdução   Ø  Expressões   que   indicam   a   adoção   de   um   modelo  arquitetural:   §  Sistemas  de  3  Camadas...   §  Uso  do  Padrão  de  Projeto  X...   §  ...Padrão  Fachada...   §  Uso   da   Arquitetura   MVC   (Modelo-­‐Visão-­‐ Controlador)   §  Projeto  na  Nuvem...   §  ....  
  9. 9. 9   Arquitetura:  o  que  aprender  da   construção  civil?  
  10. 10. 10   Arquitetura:  o  que  aprender  da   construção  civil?  
  11. 11. 11   Arquitetura:  o  que  aprender  da   construção  civil?  
  12. 12. 12   Arquitetura  de  So-ware   Amostra   Enactment GenericDataSource ContractManagement DiscoverDataLocation SystemInformationManagement DataChannel MessagesChannel DiscoveryChannel DataExchangeFormat NotificationInterface Jxta Channels IMPL (Socket, RMI, WebServices, ....) ARQUITETURA EM CAMADAS DA EXECUCAO DISTRIBUIDA NO SISTEMA P2Process O nivel de abstracao cresce de baixo para cima. No nivel inferior encontram-se os componentes que utilizam diretamente a API JXTA. No nivel superior esta a interface de execucao de modelos de processos do sistema. OBS: Dentro de cada pacote há uma descrição breve da funcionalidade de cada camada e componente. A B C D E
  13. 13. 13   Arquitetura  de  So-ware   Amostra  
  14. 14. 14   Arquitetura  de  So-ware   Amostra   under definition defined valid finished manager started contract defini... manager finished contract definition / generate contract validation... contract defined and isValid()==... not valid contract defined and isValid()==f... supplier defines that all activitities are concl... isValid()==false, becaus e condition has changed to f... isValid()==true, because condition has changed to ... supplier defines that all activitities are concl...
  15. 15. 15   O  que  é  Arquitetura  de  So-ware?   Ø  A  arquitetura  de  soAware  de  um  programa  ou   sistema  computacional  é:   §  a  estrutura  ou  estruturas  do  sistema  que   §  abrange  os  componentes  de  soAware,   §  as   propriedades   externamente   visíveis   destes   componentes     §  e  as  relações  entre  eles   Bass et al apud Pressman
  16. 16. 16   O  que  é  Arquitetura  de  So-ware?   Ø  Define-­‐se   Arquitetura   de   SoAware   como   a   organização   fundamental   de  um  sistema  na  forma  de  componentes,  seus  relacionamentos  com   o  ambiente,  e  os  princípios  que  conduzem  seu  design  e  evolução.  Um   projeto   arquitetural   envolve   a   descrição   formal   dos   elementos   dos   quais  um  sistema  é  construído,  das  interações  entre  estes  elementos,   dos  padrões  que  guiam  sua  composição,  e  das  restrições  sobre  esses   padrões.       Ø  A   descrição   arquitetural   envolve   um   conjunto   de   produtos   que   documentam  a  arquitetura.  Para  o  melhor  entendimento  do  sistema   inteiro,   ou   parte   dele,   é   necessário   que   esta   descrição   seja   representada   segundo   diferentes   perspechvas.   Cada   perspechva   possui   o   objehvo   de   representar   um   conjunto   de   interesses   parhculares   a   uma   das   partes   do   sistema.   Assim,   a   parhr   da   combinação   de   várias   perspechvas   o   sistema   inteiro   pode   ser   representado  em  maiores  detalhes.   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  17. 17. 17   O  que  é  Arquitetura  de  So-ware?   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  18. 18. 18   Por  que  Arquitetura  de  So-ware?   Ø  A   arquitetura   não   é   um   so-ware   operacional   (executável).   Porém,   permite   a   um   Engenheiro   de   SoAware:   §  Analisar  a  adequação  de  um  projeto  no  atendimento  dos   requisitos  estabelecidos;   §  Considerar   alternaKvas   arquiteturais   em   um   estágio   em   que  as  mudanças  do  projeto  ainda  são  fáceis  e  baratas;   §  Reduzir   os   riscos   associados   com   a   construção   de   soAware;  
  19. 19. 19   Por  que  Arquitetura  de  So-ware?   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  20. 20. 20   Por  que  Arquitetura  de  So-ware?   Ø  Facilitador  da  comunicação  entre  os  envolvidos  com   um  sistema;   Ø  Destaca  decisões  iniciais  de  projeto  que  vão  ter  um   impacto  profundo  em  todo  o  trabalho  de  se  segue;   Ø  Modelo   relahvamente   pequeno,   intelectualmente   inteligível  de  como  o  sistema  é  estruturado  e  como   seus  componentes  trabalham  em  conjunto;   Engenharia  de  SoAwre  II  
  21. 21. 21   Como  começar?   Especi" ficação! Protótipo! Projeto! modelagem! Engenharia  de  SoAware  II  
  22. 22. 22   Princípios  de  Projeto  (1)   1.  O  projeto  não  pode  ser  “bitolado”   §  Um  bom  projehsta  deve  considerar  abordagens  alternaKvas,  julgando  cada  uma  com  base   nos  requisitos  do  projeto         2.  O  projeto  deve  ser  relacionável  ao  modelo  de  análise   §  Como   um   único   elemento   do   projeto   pode   estar   relacionado   com   vários   requisitos,   é   necessários  ter  recursos  para  estabelecer  como  os  requisitos  são  saKsfeitos  pelo  projeto   3.  O  projeto  não  deve  reinventar  a  roda   §  Sistemas  são  construídos  usando  um  conjunto  de  padrões  de  projeto,  muitos  dos  quais  estão   descritos  amplamente  na  literatura.  Os  padrões  de  componentes  COTS  devem  ser  escolhidos   como  alternahva  à  reinvenção  (reuso  de  conhecimento)   4.  O   projeto   deve   “minimizar   a   distância   intelectual”   entre   o   so-ware   e   o   problema,  tal  como  existe  no  mundo  real   §  O  soAware,  sempre  que  possível,  deve  imitar  a  estrutura  do  domínio  do  problema   5.  O  projeto  deve  exibir  uniformidade  e  integração   §  Um  projeto  é  uniforme  se  parece  que  uma  única  pessoa  desenvolveu  a  coisa  toda.  Regras  de   esKlo  e  formato  devem  ser  definidas  para  uma  equipe  de  projeto  antes  que  o  trabalho  inicie.   §  Um   projeto   é   integrado   se   houver   cuidado   na   definição   de   interfaces   entre   os   seus   componentes  
  23. 23. 23   Princípios  de  Projeto  (2)   6.    O  projeto  deve  ser  estruturado  para  acomodar  modificação   7.     O   projeto   deve   ser   estruturado   para   degradar   suavemente,   mesmo   quando   dados,   eventos   ou   condições   de   operações   aberrantes   são   encontradas   8.    Projeto  não  é  codificação.  Codificação  não  é  projeto   §  Mesmo   quando   os   mais   detalhados   projetos   procedimentais   são   criados   para  os  componentes  de  programa,  o  nível  de  abstração  de  projeto  é  maior   que  o  do  código-­‐fonte;   9.  O  projeto  deve  ser  avaliado  quanto  à  qualidade,  à  medida  que  é  criado,   não  depois  do  fato   §  Uma   variedade   de   conceitos   e   medidas   de   projeto   está   disponível   para   auxiliar  o  projehsta  na  avaliação  de  qualidade;   10.  O  projeto  deve  ser  revisto  para  minimizar  erros  conceituais  (semânKcos)   §  A  equipe  de  projeto  deve  garanhr  que  os  principais  elementos  conceituais   (omissões,  ambigüidade  e  inconsistência)  tenham  sido  cuidados  antes  de   se  preocupar  com  a  sintaxe  do  modelo;  
  24. 24. 24   Princípios  de  Projeto  (3)   Ø  11.   Deve   considerar   de   maneira   detalhada   o   atendimento  aos  requisitos  não-­‐funcionais   §  Segurança   §  Escala   §  Tempo  de  resposta   §  Plataforma  operacional   §  Disponibilidade:  24  x  7   §  ...  
  25. 25. 25   Níveis  de  abstração  de  um  problema   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  26. 26. 26   Exemplo:  Evolução  da  Arquitetura  de   uma  Nave  Espacial   Caso  Millenium  Falcon   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  27. 27. 27   Idade  do  Arquiteto:  3   Nível  de  Experiência:  nenhuma   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  
  28. 28. 28  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Idade  do  Arquiteto:  13   Nível  de  Experiência:  estudante  entediado  
  29. 29. 29  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Idade  do  Arquiteto:  19   Nível  de  Experiência:  calouro  em  design  
  30. 30. 30  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Idade  do  Arquiteto:  23   Nível  de  Experiência:  trainee  de  design  na  Lucas  Arts  
  31. 31. 31  Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)   Idade  do  Arquiteto:  29   Nível  de  Experiência:  Designer  Gráfico  na  Lucas  Arts  
  32. 32. 32   Perguntas   Ø  Qual  o  próximo  nível  de  abstração?   Ø  Que   itens   não   foram   considerados   na   abstração  adotada?   Ø  A  nave  é  um  “so-ware  operacional”  ?   Arquitetura  de  SoAware  (baseado  nos  slides  do  profr  Rodrigo  Quites)  

×