Engenharia do Software I<br />Manuel Menezes de Sequeira<br />DCTI, ISCTE-IUL<br />Manuel.Sequeira@iscte.pt, D6.02<br />As...
Na aula anterior<br />Gestão de projectos<br />Actividades de gestão<br />Planeamento de projectos<br />Calendarização de ...
Desenho arquitectónico<br />2009/2010<br />3<br />Engenharia do Software I<br />
Sumário<br />Desenho arquitectónico<br />Decisões no desenho arquitectónico<br />Organização de sistemas<br />Estilos de d...
Objectivos<br />Apresentar desenho arquitectónico e discutir sua importância<br />Explicar decisões tomadas no desenho arq...
Arquitectura de software<br />Desenho arquitectónico é o processo de desenho que<br />Identifica subsistemas formando o si...
Desenho arquitectónico<br />Fase inicial do processo de desenho do sistema<br />Representa ligação entre processos de espe...
Vantagens da arquitectura explícita<br />2009/2010<br />Engenharia do Software I<br />8<br />
Características da arquitectura e do sistema<br />2009/2010<br />Engenharia do Software I<br />9<br /><ul><li>Security: se...
Safety: segurança face a falhas e acontecimentos físicos.</li></li></ul><li>Conflitos arquitectónicos<br />Componentes com...
Estruturação do sistema<br />Foco na decomposição do sistema em subsistemas interagentes<br />Desenho arquitectónico norma...
Exemplo: Sistema de controlo de robot de embalamento<br />2009/2010<br />12<br />Engenharia do Software I<br />Sistema de ...
Diagramas de caixas e linhas<br />Muito abstractos, não mostram natureza de relações entre componentes nem propriedades ob...
Decisões no desenho arquitectónico<br />Desenho arquitectónico é processo criativo<br />Processo varia com tipo do sistema...
Decisões no desenho arquitectónico<br />Há arquitectura aplicacional genérica usável?<br />Como distribuir sistema?<br />Q...
Reutilização de arquitecturas<br />Sistemas do mesmo domínio têm muitas vezes arquitecturas semelhantes reflectindo concei...
Estilos arquitectónicos<br />Modelo arquitectónico de sistema pode conformar-se a modelo ou estilo arquitectónico genérico...
Modelos arquitectónicos<br />Documentam desenho arquitectónico<br />Modelo estrutural estático mostrando principais compon...
Organização de sistemas<br />Reflecte estratégia básica usada para estruturar sistema<br />Três estilos organizacionais mu...
Modelo de repositório<br />Subsistemas têm de trocar dados<br />Duas formas possíveis<br />Dados em repositório ou base de...
Exemplo: Arquitectura de conjunto de ferramentas CASE<br />2009/2010<br />21<br />Engenharia do Software I<br />Editor de ...
Vantagens do modelo de repositório<br />Eficiente partilhar grandes quantidades de dados<br />Subsistemas não se preocupam...
Desvantagens do modelo de repositório<br />Subsistemas têm de acordar modelo de repositório de dados (compromisso)<br />Ev...
Modelo cliente-servidor<br />Modelo distribuído de sistema mostrando como dados e processamento se distribuem por conjunto...
Exemplo: Mediateca<br />2009/2010<br />25<br />Engenharia do Software I<br />Cliente 1<br />Cliente 1<br />Cliente 1<br />...
Vantagens do modelocliente-servidor<br />Distribuição de dados óbvia<br />Utilização eficaz de sistemas em rede<br />Pode ...
Desvantagens do modelocliente-servidor<br />Subsistemas com diferentes organizações de dados, sem modelo partilhado de dad...
Arquitectura Orientada por Serviços (SOA)<br />Arquitectura distribuída genérica baseada no paradigma pedido/resposta<br /...
Princípios arquitecturais da SOA<br />Encapsulamento<br />Ligação fraca (loosecoupling)<br />Contratualidade<br />Abstracç...
Modelo de máquina abstracta (em camadas)<br />Subsistemas ligados através de interfaces<br />Organiza sistema em camadas (...
Exemplo: Sistema de controlo de versões<br />2009/2010<br />31<br />Engenharia do Software I<br />Gestão de configurações<...
Estilos de decomposição modular<br />Decomposição de subsistemas em módulos<br />Sem distinção rígida entre organização do...
Subsistemas e módulos<br />2009/2010<br />Engenharia do Software I<br />33<br />
Decomposição modular<br />Nível estrutural em que subsistemas se decompõem em módulos<br />Dois modelos abordados<br />Mod...
Modelos de objectos<br />Estruturam sistema em conjunto de objectos fracamente ligados com interfaces bem definidas<br />D...
Exemplo: Sistema de processamento de facturas<br />2009/2010<br />36<br />Engenharia do Software I<br />Payment<br />- inv...
Vantagens do modelo de objectos<br />Objectos fracamente ligados, implementação pode mudar sem afectar outros objectos<br ...
Fluxo de dados orientado por funções<br />Transformações funcionais transformam entradas em saídas<br />Também conhecido p...
Exemplo: Sistema de processamento de facturas<br />2009/2010<br />39<br />Engenharia do Software I<br />Emitir recibos<br ...
Vantagens do modelo de fluxo de dados<br />Suporta reutilização de transformações<br />Organização intuitiva para comunica...
Estilos de controlo<br />Focam-se no fluxo de controlo entre subsistemas<br />Distintos do modelo de decomposição do siste...
Estilos de controlo<br />2009/2010<br />Engenharia do Software I<br />42<br />
Controlo centralizado<br />Subsistema de controlo com responsabilidade por gerir execução de outros subsistemas<br />2009/...
Controlo centralizado<br />2009/2010<br />Engenharia do Software I<br />44<br />
Modelo invocação-retorno<br />2009/2010<br />45<br />Engenharia do Software I<br />Programa principal<br />Rotina 1<br />R...
Controlo de sistema em tempo real<br />2009/2010<br />46<br />Engenharia do Software I<br />Processos sensores<br />Proces...
Sistemas guiados por eventos<br />Guiados por eventos gerados externamente<br />Instante de ocorrência dos eventos fora do...
Modelos de sistemas guiados por eventos<br />2009/2010<br />Engenharia do Software I<br />48<br />
Modelo de difusão<br />Eficaz para integrar subsistemas em diferentes computadores de uma rede<br />Subsistemas registam i...
Difusão selectiva<br />2009/2010<br />50<br />Engenharia do Software I<br />Subsistema 1<br />Subsistema 4<br />Subsistema...
Sistemas guiados por interrupções<br />Usados em sistemas de tempo real onde é essencial responder rápido a eventos<br />U...
Controlo guiado por interrupções<br />2009/2010<br />52<br />Engenharia do Software I<br />Interrupções<br />Vector de int...
Arquitecturas de referência<br />Modelos arquitectónicos podem ser específicos de um dado domínio de aplicação<br />Tipos ...
Tipos de modelo específico de domínio<br />2009/2010<br />Engenharia do Software I<br />54<br />Capítulo 13<br />
Arquitecturas de referência<br />Modelos de referência derivados do estudo do domínio de aplicação e não de sistemas exist...
Modelo de referência OSI<br />2009/2010<br />56<br />Engenharia do Software I<br />Aplicação<br />7<br />Aplicação<br />Ap...
Modelo de referência CASE<br />2009/2010<br />Engenharia do Software I<br />57<br />
Modelo de referência CASE da ECMA<br />2009/2010<br />58<br />Engenharia do Software I<br />Organização de normalização de...
A reter<br />Arquitectura de software é enquadramento fundamental para estruturar sistemas<br />Decisões arquitectónicas d...
A reter<br />Modelos organizacionais de sistemas<br />De repositório<br />Cliente-servidor<br />De máquinas abstractas<br ...
Upcoming SlideShare
Loading in …5
×

Eng.ª do Software - 7. Desenho arquitectónico

2,436 views

Published on

Desenho arquitectónico. Unidade de Engenharia do Software I para o curso de METI no ISCTE-IUL no 2.º semestre do ano lectivo de 2009/2010.

Published in: Education

Eng.ª do Software - 7. Desenho arquitectónico

  1. 1. Engenharia do Software I<br />Manuel Menezes de Sequeira<br />DCTI, ISCTE-IUL<br />Manuel.Sequeira@iscte.pt, D6.02<br />As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por  Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.<br />
  2. 2. Na aula anterior<br />Gestão de projectos<br />Actividades de gestão<br />Planeamento de projectos<br />Calendarização de projectos<br />Gestão do risco<br />2009/2010<br />2<br />Engenharia do Software I<br />
  3. 3. Desenho arquitectónico<br />2009/2010<br />3<br />Engenharia do Software I<br />
  4. 4. Sumário<br />Desenho arquitectónico<br />Decisões no desenho arquitectónico<br />Organização de sistemas<br />Estilos de decomposição<br />Estilos de controlo<br />Arquitecturas de referência<br />2009/2010<br />4<br />Engenharia do Software I<br />
  5. 5. Objectivos<br />Apresentar desenho arquitectónico e discutir sua importância<br />Explicar decisões tomadas no desenho arquitectónico<br />Apresentar três estilos arquitectónicos cobrindo organização, decomposição e controlo<br />Discutir arquitecturas de referência para comunicar e comparar arquitecturas<br />2009/2010<br />Engenharia do Software I<br />5<br />
  6. 6. Arquitectura de software<br />Desenho arquitectónico é o processo de desenho que<br />Identifica subsistemas formando o sistema<br />Identifica estrutura de controlo e comunicação de subsistemas<br />Resulta em descrição da arquitectura do software<br />2009/2010<br />Engenharia do Software I<br />6<br />
  7. 7. Desenho arquitectónico<br />Fase inicial do processo de desenho do sistema<br />Representa ligação entre processos de especificação e desenho<br />Frequentemente em paralelo com actividades de especificação<br />Identifica principais componentes do sistema e sua comunicação<br />2009/2010<br />Engenharia do Software I<br />7<br />
  8. 8. Vantagens da arquitectura explícita<br />2009/2010<br />Engenharia do Software I<br />8<br />
  9. 9. Características da arquitectura e do sistema<br />2009/2010<br />Engenharia do Software I<br />9<br /><ul><li>Security: segurança face a actos de pessoas, por exemplo fraude, roubo ou acesso ilícito.
  10. 10. Safety: segurança face a falhas e acontecimentos físicos.</li></li></ul><li>Conflitos arquitectónicos<br />Componentes com granularidade grossa<br />Melhor desempenho<br />Menor manutenibilidade<br />Dados redundantes<br />Melhor disponibilidade<br />Segurança (security) mais difícil<br />Características de segurança (safety) confinadas<br />Normalmente maior comunicação<br />Menor desempenho<br />2009/2010<br />Engenharia do Software I<br />10<br />
  11. 11. Estruturação do sistema<br />Foco na decomposição do sistema em subsistemas interagentes<br />Desenho arquitectónico normalmente expresso como diagrama de blocos representando vista da estrutura do sistema<br />Pode desenvolver-se modelos mais específicos mostrando partilha de dados, distribuição e interface entre subsistemas<br />2009/2010<br />Engenharia do Software I<br />11<br />
  12. 12. Exemplo: Sistema de controlo de robot de embalamento<br />2009/2010<br />12<br />Engenharia do Software I<br />Sistema de visão<br />Sistema de identificação de objectos<br />Controlador do braço<br />Controlador da mão<br />Sistema de selecção de embalagens<br />Controlador de tapete rolante<br />Sistema de embalamento<br />
  13. 13. Diagramas de caixas e linhas<br />Muito abstractos, não mostram natureza de relações entre componentes nem propriedades observáveis de subsistemas<br />No entanto, úteis para comunicação com partes interessadas e para planeamento de projectos<br />2009/2010<br />Engenharia do Software I<br />13<br />
  14. 14. Decisões no desenho arquitectónico<br />Desenho arquitectónico é processo criativo<br />Processo varia com tipo do sistema em desenvolvimento<br />Mas há conjunto de decisões comuns a todos os processos de desenho<br />2009/2010<br />Engenharia do Software I<br />14<br />
  15. 15. Decisões no desenho arquitectónico<br />Há arquitectura aplicacional genérica usável?<br />Como distribuir sistema?<br />Que estilos arquitectónicos se apropriam?<br />Que abordagem para estruturar sistema?<br />Como decompor sistema em módulos?<br />Que estratégia de controlo usar?<br />Como avaliar desenho arquitectónico?<br />Como documentar arquitectura?<br />2009/2010<br />Engenharia do Software I<br />15<br />
  16. 16. Reutilização de arquitecturas<br />Sistemas do mesmo domínio têm muitas vezes arquitecturas semelhantes reflectindo conceitos do domínio<br />Linhas de produto aplicacionais construídas em torno de arquitectura central com variantes satisfazendo requisitos particulares do cliente<br />2009/2010<br />Engenharia do Software I<br />16<br />Capítulo 13<br />Capítulo 18<br />
  17. 17. Estilos arquitectónicos<br />Modelo arquitectónico de sistema pode conformar-se a modelo ou estilo arquitectónico genérico<br />Conhecer estilos pode simplificar definição de arquitecturas de sistemas<br />No entanto, muitos dos grandes sistemas são heterogéneos não seguindo estilo arquitectónico único<br />2009/2010<br />Engenharia do Software I<br />17<br />
  18. 18. Modelos arquitectónicos<br />Documentam desenho arquitectónico<br />Modelo estrutural estático mostrando principais componentes do sistema<br />Modelo dinâmico da estrutura de processos do sistema<br />Modelo das interfaces dos subsistemas<br />Modelo de relações entre subsistemas (e.g., modelo de fluxo de dados)<br />Modelo de distribuição dos subsistemas pelos computadores<br />2009/2010<br />Engenharia do Software I<br />18<br />
  19. 19. Organização de sistemas<br />Reflecte estratégia básica usada para estruturar sistema<br />Três estilos organizacionais muito usados<br />Repositório partilhado de dados<br />Serviços e servidores partilhados<br />Máquina abstracta ou estilo em camadas<br />2009/2010<br />Engenharia do Software I<br />19<br />
  20. 20. Modelo de repositório<br />Subsistemas têm de trocar dados<br />Duas formas possíveis<br />Dados em repositório ou base de dados central partilhados por subsistemas<br />Cada subsistema mantém sua base de dados e passa dados explicitamente a restantes subsistemas<br />Modelo de repositório partilhado mais comum quando se partilha grandes quantidades de dados<br />2009/2010<br />Engenharia do Software I<br />20<br />
  21. 21. Exemplo: Arquitectura de conjunto de ferramentas CASE<br />2009/2010<br />21<br />Engenharia do Software I<br />Editor de desenho<br />Gerador de código<br />Editor de programas<br />Tradutor de desenho<br />Repositório do projecto<br />Analisador de desenho<br />Gerador de relatórios<br />
  22. 22. Vantagens do modelo de repositório<br />Eficiente partilhar grandes quantidades de dados<br />Subsistemas não se preocupam com produção de dados<br />Gestão centralizada (cópias de segurança, segurança, etc.)<br />Modelo de partilha publicado como esquema (schema) do repositório<br />2009/2010<br />Engenharia do Software I<br />22<br />
  23. 23. Desvantagens do modelo de repositório<br />Subsistemas têm de acordar modelo de repositório de dados (compromisso)<br />Evolução de dados difícil e onerosa<br />Não há espaço para políticas de gestão específicas<br />Difícil distribuir eficientemente<br />2009/2010<br />Engenharia do Software I<br />23<br />
  24. 24. Modelo cliente-servidor<br />Modelo distribuído de sistema mostrando como dados e processamento se distribuem por conjunto de componentes<br />Conjunto de servidores isolados disponibilizando serviços específicos (impressões, gestão de dados, etc.)<br />Conjunto de clientes usando serviços<br />Rede para clientes acederem a servidores<br />2009/2010<br />Engenharia do Software I<br />24<br />
  25. 25. Exemplo: Mediateca<br />2009/2010<br />25<br />Engenharia do Software I<br />Cliente 1<br />Cliente 1<br />Cliente 1<br />Cliente 1<br />Internet<br />Servidor de catálogo<br />Catálogo da mediateca<br />Servidor de vídeo<br />Ficheiros de vídeo<br />Servidor de imagens<br />Fotografias digitalizadas<br />Servidor Web<br />Informação sobre média<br />
  26. 26. Vantagens do modelocliente-servidor<br />Distribuição de dados óbvia<br />Utilização eficaz de sistemas em rede<br />Pode requerer hardware mais barato<br />Fácil adicionar novos servidores ou actualizar existentes<br />2009/2010<br />Engenharia do Software I<br />26<br />
  27. 27. Desvantagens do modelocliente-servidor<br />Subsistemas com diferentes organizações de dados, sem modelo partilhado de dados<br />Troca de dados pode ser ineficiente<br />Administração separada dos servidores<br />Pode ser difícil saber servidores e serviços disponíveis, sem registo central de nomes e serviços<br />2009/2010<br />Engenharia do Software I<br />27<br />
  28. 28. Arquitectura Orientada por Serviços (SOA)<br />Arquitectura distribuída genérica baseada no paradigma pedido/resposta<br />Exemplos<br />RPC<br />DCOM<br />CORBA<br />Web Services<br />WCF<br />2009/2010<br />Engenharia do Software I<br />28<br />Capítulo 12<br />Cliente<br />Serviço<br />Serviço<br />Serviço<br />Serviço<br />Serviço de directório<br />Parceiros de negócio<br />Outros fornecedores<br />
  29. 29. Princípios arquitecturais da SOA<br />Encapsulamento<br />Ligação fraca (loosecoupling)<br />Contratualidade<br />Abstracção<br />Reutilizabilidade<br />Componibilidade<br />Autonomia<br />Descobribilidade<br />2009/2010<br />Engenharia do Software I<br />29<br />
  30. 30. Modelo de máquina abstracta (em camadas)<br />Subsistemas ligados através de interfaces<br />Organiza sistema em camadas (máquinas virtuais) fornecendo conjunto de serviços<br />Suporta desenvolvimento incremental de subsistemas: alteração de interface só afecta camada adjacente<br />Muitas vezes artificial para estruturar sistemas<br />2009/2010<br />Engenharia do Software I<br />30<br />
  31. 31. Exemplo: Sistema de controlo de versões<br />2009/2010<br />31<br />Engenharia do Software I<br />Gestão de configurações<br />Gestão de objectos<br />Camadas de sistema<br />Bases de dados<br />Sistema operativo<br />
  32. 32. Estilos de decomposição modular<br />Decomposição de subsistemas em módulos<br />Sem distinção rígida entre organização do sistema e decomposição modular<br />2009/2010<br />Engenharia do Software I<br />32<br />
  33. 33. Subsistemas e módulos<br />2009/2010<br />Engenharia do Software I<br />33<br />
  34. 34. Decomposição modular<br />Nível estrutural em que subsistemas se decompõem em módulos<br />Dois modelos abordados<br />Modelo de objectos – Decomposição em objectos em interacção<br />Modelo de fluxo de dados – Decomposição em módulos funcionais transformando entradas em saídas<br />Tentar adiar decisão sobre concorrência até implementação de módulos<br />2009/2010<br />Engenharia do Software I<br />34<br />
  35. 35. Modelos de objectos<br />Estruturam sistema em conjunto de objectos fracamente ligados com interfaces bem definidas<br />Decomposição corresponde a identificar classes de objectos, seus atributos e suas operações<br />Na implementação, objectos criados via classes e modelo de controlo coordena operações dos objectos<br />2009/2010<br />Engenharia do Software I<br />35<br />
  36. 36. Exemplo: Sistema de processamento de facturas<br />2009/2010<br />36<br />Engenharia do Software I<br />Payment<br />- invoiceNumber<br />- date<br />- amount<br />- customerNumber<br />Invoice<br />- invoiceNumber<br />- date<br />- amount<br />- customer<br />+ issue()<br />+ sendReminder()<br />+ acceptPayment()<br />+ sendReceipt()<br />Customer<br />Receipt<br />- customerNumber<br />- name<br />- address<br />- creditPeriod<br />- invoiceNumber<br />- date<br />- amount<br />- customerNumber<br />
  37. 37. Vantagens do modelo de objectos<br />Objectos fracamente ligados, implementação pode mudar sem afectar outros objectos<br />Objectos podem reflectir entidades reais<br />Linguagens de implementação orientadas por objectos muito usadas<br />Mas alterações em interfaces podem causar problemas e entidades complexas podem ser difíceis de representar<br />2009/2010<br />Engenharia do Software I<br />37<br />
  38. 38. Fluxo de dados orientado por funções<br />Transformações funcionais transformam entradas em saídas<br />Também conhecido por modelo pipeline ou modelo pipeandfilter (shell UNIX)<br />Variantes muito comuns: se transformações sequenciais, modelo em lote sequencial usado em sistemas de processamento de dados<br />Mas não apropriado para sistemas interactivos<br />2009/2010<br />Engenharia do Software I<br />38<br />
  39. 39. Exemplo: Sistema de processamento de facturas<br />2009/2010<br />39<br />Engenharia do Software I<br />Emitir recibos<br />Recibos<br />Ler facturas emitidas<br />Identificar pagamentos<br />Procurar pagamentos devidos<br />Emitir lembrete de pagamento<br />Lembretes<br />Facturas<br />Pagamentos<br />
  40. 40. Vantagens do modelo de fluxo de dados<br />Suporta reutilização de transformações<br />Organização intuitiva para comunicar com partes interessadas<br />Fácil adicionar novas transformações<br />Relativamente fácil de implementar em sistemas concorrentes e sequenciais<br />Mas requer formato comum para transferência de dados e difícil suportar interacção baseada em eventos<br />2009/2010<br />Engenharia do Software I<br />40<br />
  41. 41. Estilos de controlo<br />Focam-se no fluxo de controlo entre subsistemas<br />Distintos do modelo de decomposição do sistema<br />2009/2010<br />Engenharia do Software I<br />41<br />
  42. 42. Estilos de controlo<br />2009/2010<br />Engenharia do Software I<br />42<br />
  43. 43. Controlo centralizado<br />Subsistema de controlo com responsabilidade por gerir execução de outros subsistemas<br />2009/2010<br />Engenharia do Software I<br />43<br />
  44. 44. Controlo centralizado<br />2009/2010<br />Engenharia do Software I<br />44<br />
  45. 45. Modelo invocação-retorno<br />2009/2010<br />45<br />Engenharia do Software I<br />Programa principal<br />Rotina 1<br />Rotina 3<br />Rotina 2<br />Rotina 1.1<br />Rotina 1.2<br />Rotina 1.1<br />Rotina 1.2<br />Rotina 1.1<br />Rotina 1.2<br />
  46. 46. Controlo de sistema em tempo real<br />2009/2010<br />46<br />Engenharia do Software I<br />Processos sensores<br />Processos actuadores<br />Controlador do sistema<br />Interface com utilizador<br />Processos de computação<br />Gestor de anomalias<br />
  47. 47. Sistemas guiados por eventos<br />Guiados por eventos gerados externamente<br />Instante de ocorrência dos eventos fora do controlo dos subsistemas que o processam<br />Dois principais modelos<br />Difusão<br />Guiados por interrupções<br />Outros modelos<br />Folhas de cálculo<br />Sistemas de produção<br />2009/2010<br />Engenharia do Software I<br />47<br />
  48. 48. Modelos de sistemas guiados por eventos<br />2009/2010<br />Engenharia do Software I<br />48<br />
  49. 49. Modelo de difusão<br />Eficaz para integrar subsistemas em diferentes computadores de uma rede<br />Subsistemas registam interesse em eventos específicos; quando ocorrem, controlo transferido para subsistemas que com eles podem lidar<br />Política de controlo não está no gestor de eventos e mensagens; subsistemas decidem que eventos são do seu interesse<br />No entanto, subsistemas não sabem se e quando um evento será processado<br />2009/2010<br />Engenharia do Software I<br />49<br />
  50. 50. Difusão selectiva<br />2009/2010<br />50<br />Engenharia do Software I<br />Subsistema 1<br />Subsistema 4<br />Subsistema 3<br />Subsistema 2<br />Gestor de mensagens e eventos<br />
  51. 51. Sistemas guiados por interrupções<br />Usados em sistemas de tempo real onde é essencial responder rápido a eventos<br />Um gestor definido para cada tipo de interrupções conhecido<br />Cada tipo associado a posição de memória; comutador hardware transfere para gestor associado<br />Permitem resposta rápida, mas complexos de programar e difíceis de validar<br />2009/2010<br />Engenharia do Software I<br />51<br />
  52. 52. Controlo guiado por interrupções<br />2009/2010<br />52<br />Engenharia do Software I<br />Interrupções<br />Vector de interrupções<br />Gestor 1<br />Gestor 2<br />Gestor 3<br />Gestor 4<br />Processo 1<br />Processo 2<br />Processo 3<br />Processo 4<br />
  53. 53. Arquitecturas de referência<br />Modelos arquitectónicos podem ser específicos de um dado domínio de aplicação<br />Tipos de modelo específico de domínio<br />Modelos genéricos<br />Modelos de referência<br />2009/2010<br />Engenharia do Software I<br />53<br />
  54. 54. Tipos de modelo específico de domínio<br />2009/2010<br />Engenharia do Software I<br />54<br />Capítulo 13<br />
  55. 55. Arquitecturas de referência<br />Modelos de referência derivados do estudo do domínio de aplicação e não de sistemas existentes<br />Usados como base para implementação de sistemas ou para comparar sistemas<br />São padrão de referência para avaliação de sistemas<br />Modelo OSI é modelo em camadas para sistemas de comunicação<br />2009/2010<br />Engenharia do Software I<br />55<br />
  56. 56. Modelo de referência OSI<br />2009/2010<br />56<br />Engenharia do Software I<br />Aplicação<br />7<br />Aplicação<br />Apresentação<br />6<br />Apresentação<br />Sessão<br />5<br />Sessão<br />Transporte<br />4<br />Transporte<br />Rede<br />3<br />Rede<br />Rede<br />Dados<br />2<br />Dados<br />Dados<br />Físico<br />1<br />Físico<br />Físico<br />Meio de comunicações<br />
  57. 57. Modelo de referência CASE<br />2009/2010<br />Engenharia do Software I<br />57<br />
  58. 58. Modelo de referência CASE da ECMA<br />2009/2010<br />58<br />Engenharia do Software I<br />Organização de normalização de sistemas de informação e comunicação<br />Ver nota neste diapositivo e no anterior.<br />
  59. 59. A reter<br />Arquitectura de software é enquadramento fundamental para estruturar sistemas<br />Decisões arquitectónicas de desenho<br />Tipo de aplicação<br />Distribuição do sistema<br />Estilos arquitectónicos<br />Diferentes modelos arquitectónicos<br />Estrutural<br />De controlo<br />De decomposição<br />2009/2010<br />Engenharia do Software I<br />59<br />
  60. 60. A reter<br />Modelos organizacionais de sistemas<br />De repositório<br />Cliente-servidor<br />De máquinas abstractas<br />Modelos de decomposição modular<br />De objectos<br />De fluxo de dados<br />2009/2010<br />Engenharia do Software I<br />60<br />
  61. 61. A reter<br />Modelos de controlo<br />Controlo centralizado<br />Guiado por eventos<br />Arquitecturas de referência usadas para comunicar arquitecturas específicas de domínio e para avaliar e comparar desenhos arquitectónicos<br />2009/2010<br />Engenharia do Software I<br />61<br />
  62. 62. A ler<br />IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006<br />Capítulo 11<br />Capítulo 12<br />2009/2010<br />Engenharia do Software I<br />62<br />

×