Este documento discute o desenho arquitectónico de software, apresentando três estilos arquitectónicos para organização, decomposição e controlo de sistemas. Também discute decisões no desenho arquitectónico e arquitecturas de referência.

1. Engenharia do Software I Manuel Menezes de Sequeira DCTI, ISCTE-IUL Manuel.Sequeira@iscte.pt, D6.02 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.

2. Na aula anterior Gestão de projectos Actividades de gestão Planeamento de projectos Calendarização de projectos Gestão do risco 2009/2010 2 Engenharia do Software I

3. Desenho arquitectónico 2009/2010 3 Engenharia do Software I

4. Sumário Desenho arquitectónico Decisões no desenho arquitectónico Organização de sistemas Estilos de decomposição Estilos de controlo Arquitecturas de referência 2009/2010 4 Engenharia do Software I

5. Objectivos Apresentar desenho arquitectónico e discutir sua importância Explicar decisões tomadas no desenho arquitectónico Apresentar três estilos arquitectónicos cobrindo organização, decomposição e controlo Discutir arquitecturas de referência para comunicar e comparar arquitecturas 2009/2010 Engenharia do Software I 5

6. Arquitectura de software Desenho arquitectónico é o processo de desenho que Identifica subsistemas formando o sistema Identifica estrutura de controlo e comunicação de subsistemas Resulta em descrição da arquitectura do software 2009/2010 Engenharia do Software I 6

7. Desenho arquitectónico Fase inicial do processo de desenho do sistema Representa ligação entre processos de especificação e desenho Frequentemente em paralelo com actividades de especificação Identifica principais componentes do sistema e sua comunicação 2009/2010 Engenharia do Software I 7

8. Vantagens da arquitectura explícita 2009/2010 Engenharia do Software I 8

11. Estruturação do sistema Foco na decomposição do sistema em subsistemas interagentes Desenho arquitectónico normalmente expresso como diagrama de blocos representando vista da estrutura do sistema Pode desenvolver-se modelos mais específicos mostrando partilha de dados, distribuição e interface entre subsistemas 2009/2010 Engenharia do Software I 11

12. Exemplo: Sistema de controlo de robot de embalamento 2009/2010 12 Engenharia do Software I Sistema de visão Sistema de identificação de objectos Controlador do braço Controlador da mão Sistema de selecção de embalagens Controlador de tapete rolante Sistema de embalamento

13. Diagramas de caixas e linhas Muito abstractos, não mostram natureza de relações entre componentes nem propriedades observáveis de subsistemas No entanto, úteis para comunicação com partes interessadas e para planeamento de projectos 2009/2010 Engenharia do Software I 13

14. Decisões no desenho arquitectónico Desenho arquitectónico é processo criativo Processo varia com tipo do sistema em desenvolvimento Mas há conjunto de decisões comuns a todos os processos de desenho 2009/2010 Engenharia do Software I 14

15. Decisões no desenho arquitectónico Há arquitectura aplicacional genérica usável? Como distribuir sistema? Que estilos arquitectónicos se apropriam? Que abordagem para estruturar sistema? Como decompor sistema em módulos? Que estratégia de controlo usar? Como avaliar desenho arquitectónico? Como documentar arquitectura? 2009/2010 Engenharia do Software I 15

16. Reutilização de arquitecturas Sistemas do mesmo domínio têm muitas vezes arquitecturas semelhantes reflectindo conceitos do domínio Linhas de produto aplicacionais construídas em torno de arquitectura central com variantes satisfazendo requisitos particulares do cliente 2009/2010 Engenharia do Software I 16 Capítulo 13 Capítulo 18

17. Estilos arquitectónicos Modelo arquitectónico de sistema pode conformar-se a modelo ou estilo arquitectónico genérico Conhecer estilos pode simplificar definição de arquitecturas de sistemas No entanto, muitos dos grandes sistemas são heterogéneos não seguindo estilo arquitectónico único 2009/2010 Engenharia do Software I 17

18. Modelos arquitectónicos Documentam desenho arquitectónico Modelo estrutural estático mostrando principais componentes do sistema Modelo dinâmico da estrutura de processos do sistema Modelo das interfaces dos subsistemas Modelo de relações entre subsistemas (e.g., modelo de fluxo de dados) Modelo de distribuição dos subsistemas pelos computadores 2009/2010 Engenharia do Software I 18

19. Organização de sistemas Reflecte estratégia básica usada para estruturar sistema Três estilos organizacionais muito usados Repositório partilhado de dados Serviços e servidores partilhados Máquina abstracta ou estilo em camadas 2009/2010 Engenharia do Software I 19

20. Modelo de repositório Subsistemas têm de trocar dados Duas formas possíveis Dados em repositório ou base de dados central partilhados por subsistemas Cada subsistema mantém sua base de dados e passa dados explicitamente a restantes subsistemas Modelo de repositório partilhado mais comum quando se partilha grandes quantidades de dados 2009/2010 Engenharia do Software I 20

21. Exemplo: Arquitectura de conjunto de ferramentas CASE 2009/2010 21 Engenharia do Software I Editor de desenho Gerador de código Editor de programas Tradutor de desenho Repositório do projecto Analisador de desenho Gerador de relatórios

22. Vantagens do modelo de repositório Eficiente partilhar grandes quantidades de dados Subsistemas não se preocupam com produção de dados Gestão centralizada (cópias de segurança, segurança, etc.) Modelo de partilha publicado como esquema (schema) do repositório 2009/2010 Engenharia do Software I 22

23. Desvantagens do modelo de repositório Subsistemas têm de acordar modelo de repositório de dados (compromisso) Evolução de dados difícil e onerosa Não há espaço para políticas de gestão específicas Difícil distribuir eficientemente 2009/2010 Engenharia do Software I 23

24. Modelo cliente-servidor Modelo distribuído de sistema mostrando como dados e processamento se distribuem por conjunto de componentes Conjunto de servidores isolados disponibilizando serviços específicos (impressões, gestão de dados, etc.) Conjunto de clientes usando serviços Rede para clientes acederem a servidores 2009/2010 Engenharia do Software I 24

25. Exemplo: Mediateca 2009/2010 25 Engenharia do Software I Cliente 1 Cliente 1 Cliente 1 Cliente 1 Internet Servidor de catálogo Catálogo da mediateca Servidor de vídeo Ficheiros de vídeo Servidor de imagens Fotografias digitalizadas Servidor Web Informação sobre média

26. Vantagens do modelocliente-servidor Distribuição de dados óbvia Utilização eficaz de sistemas em rede Pode requerer hardware mais barato Fácil adicionar novos servidores ou actualizar existentes 2009/2010 Engenharia do Software I 26

27. Desvantagens do modelocliente-servidor Subsistemas com diferentes organizações de dados, sem modelo partilhado de dados Troca de dados pode ser ineficiente Administração separada dos servidores Pode ser difícil saber servidores e serviços disponíveis, sem registo central de nomes e serviços 2009/2010 Engenharia do Software I 27

28. Arquitectura Orientada por Serviços (SOA) Arquitectura distribuída genérica baseada no paradigma pedido/resposta Exemplos RPC DCOM CORBA Web Services WCF 2009/2010 Engenharia do Software I 28 Capítulo 12 Cliente Serviço Serviço Serviço Serviço Serviço de directório Parceiros de negócio Outros fornecedores

29. Princípios arquitecturais da SOA Encapsulamento Ligação fraca (loosecoupling) Contratualidade Abstracção Reutilizabilidade Componibilidade Autonomia Descobribilidade 2009/2010 Engenharia do Software I 29

30. Modelo de máquina abstracta (em camadas) Subsistemas ligados através de interfaces Organiza sistema em camadas (máquinas virtuais) fornecendo conjunto de serviços Suporta desenvolvimento incremental de subsistemas: alteração de interface só afecta camada adjacente Muitas vezes artificial para estruturar sistemas 2009/2010 Engenharia do Software I 30

31. Exemplo: Sistema de controlo de versões 2009/2010 31 Engenharia do Software I Gestão de configurações Gestão de objectos Camadas de sistema Bases de dados Sistema operativo

32. Estilos de decomposição modular Decomposição de subsistemas em módulos Sem distinção rígida entre organização do sistema e decomposição modular 2009/2010 Engenharia do Software I 32

33. Subsistemas e módulos 2009/2010 Engenharia do Software I 33

34. Decomposição modular Nível estrutural em que subsistemas se decompõem em módulos Dois modelos abordados Modelo de objectos – Decomposição em objectos em interacção Modelo de fluxo de dados – Decomposição em módulos funcionais transformando entradas em saídas Tentar adiar decisão sobre concorrência até implementação de módulos 2009/2010 Engenharia do Software I 34

35. Modelos de objectos Estruturam sistema em conjunto de objectos fracamente ligados com interfaces bem definidas Decomposição corresponde a identificar classes de objectos, seus atributos e suas operações Na implementação, objectos criados via classes e modelo de controlo coordena operações dos objectos 2009/2010 Engenharia do Software I 35

36. Exemplo: Sistema de processamento de facturas 2009/2010 36 Engenharia do Software I Payment - invoiceNumber - date - amount - customerNumber Invoice - invoiceNumber - date - amount - customer + issue() + sendReminder() + acceptPayment() + sendReceipt() Customer Receipt - customerNumber - name - address - creditPeriod - invoiceNumber - date - amount - customerNumber

37. Vantagens do modelo de objectos Objectos fracamente ligados, implementação pode mudar sem afectar outros objectos Objectos podem reflectir entidades reais Linguagens de implementação orientadas por objectos muito usadas Mas alterações em interfaces podem causar problemas e entidades complexas podem ser difíceis de representar 2009/2010 Engenharia do Software I 37

38. Fluxo de dados orientado por funções Transformações funcionais transformam entradas em saídas Também conhecido por modelo pipeline ou modelo pipeandfilter (shell UNIX) Variantes muito comuns: se transformações sequenciais, modelo em lote sequencial usado em sistemas de processamento de dados Mas não apropriado para sistemas interactivos 2009/2010 Engenharia do Software I 38

39. Exemplo: Sistema de processamento de facturas 2009/2010 39 Engenharia do Software I Emitir recibos Recibos Ler facturas emitidas Identificar pagamentos Procurar pagamentos devidos Emitir lembrete de pagamento Lembretes Facturas Pagamentos

40. Vantagens do modelo de fluxo de dados Suporta reutilização de transformações Organização intuitiva para comunicar com partes interessadas Fácil adicionar novas transformações Relativamente fácil de implementar em sistemas concorrentes e sequenciais Mas requer formato comum para transferência de dados e difícil suportar interacção baseada em eventos 2009/2010 Engenharia do Software I 40

41. Estilos de controlo Focam-se no fluxo de controlo entre subsistemas Distintos do modelo de decomposição do sistema 2009/2010 Engenharia do Software I 41

42. Estilos de controlo 2009/2010 Engenharia do Software I 42

43. Controlo centralizado Subsistema de controlo com responsabilidade por gerir execução de outros subsistemas 2009/2010 Engenharia do Software I 43

44. Controlo centralizado 2009/2010 Engenharia do Software I 44

45. Modelo invocação-retorno 2009/2010 45 Engenharia do Software I Programa principal Rotina 1 Rotina 3 Rotina 2 Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2 Rotina 1.1 Rotina 1.2

46. Controlo de sistema em tempo real 2009/2010 46 Engenharia do Software I Processos sensores Processos actuadores Controlador do sistema Interface com utilizador Processos de computação Gestor de anomalias

47. Sistemas guiados por eventos Guiados por eventos gerados externamente Instante de ocorrência dos eventos fora do controlo dos subsistemas que o processam Dois principais modelos Difusão Guiados por interrupções Outros modelos Folhas de cálculo Sistemas de produção 2009/2010 Engenharia do Software I 47

48. Modelos de sistemas guiados por eventos 2009/2010 Engenharia do Software I 48

49. Modelo de difusão Eficaz para integrar subsistemas em diferentes computadores de uma rede Subsistemas registam interesse em eventos específicos; quando ocorrem, controlo transferido para subsistemas que com eles podem lidar Política de controlo não está no gestor de eventos e mensagens; subsistemas decidem que eventos são do seu interesse No entanto, subsistemas não sabem se e quando um evento será processado 2009/2010 Engenharia do Software I 49

50. Difusão selectiva 2009/2010 50 Engenharia do Software I Subsistema 1 Subsistema 4 Subsistema 3 Subsistema 2 Gestor de mensagens e eventos

51. Sistemas guiados por interrupções Usados em sistemas de tempo real onde é essencial responder rápido a eventos Um gestor definido para cada tipo de interrupções conhecido Cada tipo associado a posição de memória; comutador hardware transfere para gestor associado Permitem resposta rápida, mas complexos de programar e difíceis de validar 2009/2010 Engenharia do Software I 51

52. Controlo guiado por interrupções 2009/2010 52 Engenharia do Software I Interrupções Vector de interrupções Gestor 1 Gestor 2 Gestor 3 Gestor 4 Processo 1 Processo 2 Processo 3 Processo 4

53. Arquitecturas de referência Modelos arquitectónicos podem ser específicos de um dado domínio de aplicação Tipos de modelo específico de domínio Modelos genéricos Modelos de referência 2009/2010 Engenharia do Software I 53

54. Tipos de modelo específico de domínio 2009/2010 Engenharia do Software I 54 Capítulo 13

55. Arquitecturas de referência Modelos de referência derivados do estudo do domínio de aplicação e não de sistemas existentes Usados como base para implementação de sistemas ou para comparar sistemas São padrão de referência para avaliação de sistemas Modelo OSI é modelo em camadas para sistemas de comunicação 2009/2010 Engenharia do Software I 55

56. Modelo de referência OSI 2009/2010 56 Engenharia do Software I Aplicação 7 Aplicação Apresentação 6 Apresentação Sessão 5 Sessão Transporte 4 Transporte Rede 3 Rede Rede Dados 2 Dados Dados Físico 1 Físico Físico Meio de comunicações

57. Modelo de referência CASE 2009/2010 Engenharia do Software I 57

58. Modelo de referência CASE da ECMA 2009/2010 58 Engenharia do Software I Organização de normalização de sistemas de informação e comunicação Ver nota neste diapositivo e no anterior.

59. A reter Arquitectura de software é enquadramento fundamental para estruturar sistemas Decisões arquitectónicas de desenho Tipo de aplicação Distribuição do sistema Estilos arquitectónicos Diferentes modelos arquitectónicos Estrutural De controlo De decomposição 2009/2010 Engenharia do Software I 59

60. A reter Modelos organizacionais de sistemas De repositório Cliente-servidor De máquinas abstractas Modelos de decomposição modular De objectos De fluxo de dados 2009/2010 Engenharia do Software I 60

61. A reter Modelos de controlo Controlo centralizado Guiado por eventos Arquitecturas de referência usadas para comunicar arquitecturas específicas de domínio e para avaliar e comparar desenhos arquitectónicos 2009/2010 Engenharia do Software I 61

62. A ler IanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006 Capítulo 11 Capítulo 12 2009/2010 Engenharia do Software I 62