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 IManuel Menezes de SequeiraDCTI, ISCTE-IULManuel.Sequeira@iscte.pt, D6.02As 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 anteriorGestão de projectosActividades de gestãoPlaneamento de projectosCalendarização de projectosGestão do risco2009/20102Engenharia do Software I

3. Desenho arquitectónico2009/20103Engenharia do Software I

4. SumárioDesenho arquitectónicoDecisões no desenho arquitectónicoOrganização de sistemasEstilos de decomposiçãoEstilos de controloArquitecturas de referência2009/20104Engenharia do Software I

5. ObjectivosApresentar desenho arquitectónico e discutir sua importânciaExplicar decisões tomadas no desenho arquitectónicoApresentar três estilos arquitectónicos cobrindo organização, decomposição e controloDiscutir arquitecturas de referência para comunicar e comparar arquitecturas2009/2010Engenharia do Software I5

6. Arquitectura de softwareDesenho arquitectónico é o processo de desenho queIdentifica subsistemas formando o sistemaIdentifica estrutura de controlo e comunicação de subsistemasResulta em descrição da arquitectura do software2009/2010Engenharia do Software I6

7. Desenho arquitectónicoFase inicial do processo de desenho do sistemaRepresenta ligação entre processos de especificação e desenhoFrequentemente em paralelo com actividades de especificaçãoIdentifica principais componentes do sistema e sua comunicação2009/2010Engenharia do Software I7

8. Vantagens da arquitectura explícita2009/2010Engenharia do Software I8

9. Características da arquitectura e do sistema2009/2010Engenharia do Software I9Security: segurança face a actos de pessoas, por exemplo fraude, roubo ou acesso ilícito.

10. Safety: segurança face a falhas e acontecimentos físicos.Conflitos arquitectónicosComponentes com granularidade grossaMelhor desempenhoMenor manutenibilidadeDados redundantesMelhor disponibilidadeSegurança (security) mais difícilCaracterísticas de segurança (safety) confinadasNormalmente maior comunicaçãoMenor desempenho2009/2010Engenharia do Software I10

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

12. Exemplo: Sistema de controlo de robot de embalamento2009/201012Engenharia do Software ISistema de visãoSistema de identificação de objectosControlador do braçoControlador da mãoSistema de selecção de embalagensControlador de tapete rolanteSistema de embalamento

13. Diagramas de caixas e linhasMuito abstractos, não mostram natureza de relações entre componentes nem propriedades observáveis de subsistemasNo entanto, úteis para comunicação com partes interessadas e para planeamento de projectos2009/2010Engenharia do Software I13

14. Decisões no desenho arquitectónicoDesenho arquitectónico é processo criativoProcesso varia com tipo do sistema em desenvolvimentoMas há conjunto de decisões comuns a todos os processos de desenho2009/2010Engenharia do Software I14

15. Decisões no desenho arquitectónicoHá 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/2010Engenharia do Software I15

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

17. Estilos arquitectónicosModelo arquitectónico de sistema pode conformar-se a modelo ou estilo arquitectónico genéricoConhecer estilos pode simplificar definição de arquitecturas de sistemasNo entanto, muitos dos grandes sistemas são heterogéneos não seguindo estilo arquitectónico único2009/2010Engenharia do Software I17

18. Modelos arquitectónicosDocumentam desenho arquitectónicoModelo estrutural estático mostrando principais componentes do sistemaModelo dinâmico da estrutura de processos do sistemaModelo das interfaces dos subsistemasModelo de relações entre subsistemas (e.g., modelo de fluxo de dados)Modelo de distribuição dos subsistemas pelos computadores2009/2010Engenharia do Software I18

19. Organização de sistemasReflecte estratégia básica usada para estruturar sistemaTrês estilos organizacionais muito usadosRepositório partilhado de dadosServiços e servidores partilhadosMáquina abstracta ou estilo em camadas2009/2010Engenharia do Software I19

20. Modelo de repositórioSubsistemas têm de trocar dadosDuas formas possíveisDados em repositório ou base de dados central partilhados por subsistemasCada subsistema mantém sua base de dados e passa dados explicitamente a restantes subsistemasModelo de repositório partilhado mais comum quando se partilha grandes quantidades de dados2009/2010Engenharia do Software I20

21. Exemplo: Arquitectura de conjunto de ferramentas CASE2009/201021Engenharia do Software IEditor de desenhoGerador de códigoEditor de programasTradutor de desenhoRepositório do projectoAnalisador de desenhoGerador de relatórios

22. Vantagens do modelo de repositórioEficiente partilhar grandes quantidades de dadosSubsistemas não se preocupam com produção de dadosGestão centralizada (cópias de segurança, segurança, etc.)Modelo de partilha publicado como esquema (schema) do repositório2009/2010Engenharia do Software I22

23. Desvantagens do modelo de repositórioSubsistemas têm de acordar modelo de repositório de dados (compromisso)Evolução de dados difícil e onerosaNão há espaço para políticas de gestão específicasDifícil distribuir eficientemente2009/2010Engenharia do Software I23

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

25. Exemplo: Mediateca2009/201025Engenharia do Software ICliente 1Cliente 1Cliente 1Cliente 1InternetServidor de catálogoCatálogo da mediatecaServidor de vídeoFicheiros de vídeoServidor de imagensFotografias digitalizadasServidor WebInformação sobre média

26. Vantagens do modelocliente-servidorDistribuição de dados óbviaUtilização eficaz de sistemas em redePode requerer hardware mais baratoFácil adicionar novos servidores ou actualizar existentes2009/2010Engenharia do Software I26

27. Desvantagens do modelocliente-servidorSubsistemas com diferentes organizações de dados, sem modelo partilhado de dadosTroca de dados pode ser ineficienteAdministração separada dos servidoresPode ser difícil saber servidores e serviços disponíveis, sem registo central de nomes e serviços2009/2010Engenharia do Software I27

28. Arquitectura Orientada por Serviços (SOA)Arquitectura distribuída genérica baseada no paradigma pedido/respostaExemplosRPCDCOMCORBAWeb ServicesWCF2009/2010Engenharia do Software I28Capítulo 12ClienteServiçoServiçoServiçoServiçoServiço de directórioParceiros de negócioOutros fornecedores

29. Princípios arquitecturais da SOAEncapsulamentoLigação fraca (loosecoupling)ContratualidadeAbstracçãoReutilizabilidadeComponibilidadeAutonomiaDescobribilidade2009/2010Engenharia do Software I29

30. Modelo de máquina abstracta (em camadas)Subsistemas ligados através de interfacesOrganiza sistema em camadas (máquinas virtuais) fornecendo conjunto de serviçosSuporta desenvolvimento incremental de subsistemas: alteração de interface só afecta camada adjacenteMuitas vezes artificial para estruturar sistemas2009/2010Engenharia do Software I30

31. Exemplo: Sistema de controlo de versões2009/201031Engenharia do Software IGestão de configuraçõesGestão de objectosCamadas de sistemaBases de dadosSistema operativo

32. Estilos de decomposição modularDecomposição de subsistemas em módulosSem distinção rígida entre organização do sistema e decomposição modular2009/2010Engenharia do Software I32

33. Subsistemas e módulos2009/2010Engenharia do Software I33

34. Decomposição modularNível estrutural em que subsistemas se decompõem em módulosDois modelos abordadosModelo de objectos – Decomposição em objectos em interacçãoModelo de fluxo de dados – Decomposição em módulos funcionais transformando entradas em saídasTentar adiar decisão sobre concorrência até implementação de módulos2009/2010Engenharia do Software I34

35. Modelos de objectosEstruturam sistema em conjunto de objectos fracamente ligados com interfaces bem definidasDecomposição corresponde a identificar classes de objectos, seus atributos e suas operaçõesNa implementação, objectos criados via classes e modelo de controlo coordena operações dos objectos2009/2010Engenharia do Software I35

36. Exemplo: Sistema de processamento de facturas2009/201036Engenharia do Software IPayment- invoiceNumber- date- amount- customerNumberInvoice- invoiceNumber- date- amount- customer+ issue()+ sendReminder()+ acceptPayment()+ sendReceipt()CustomerReceipt- customerNumber- name- address- creditPeriod- invoiceNumber- date- amount- customerNumber

37. Vantagens do modelo de objectosObjectos fracamente ligados, implementação pode mudar sem afectar outros objectosObjectos podem reflectir entidades reaisLinguagens de implementação orientadas por objectos muito usadasMas alterações em interfaces podem causar problemas e entidades complexas podem ser difíceis de representar2009/2010Engenharia do Software I37

38. Fluxo de dados orientado por funçõesTransformações funcionais transformam entradas em saídasTambé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 dadosMas não apropriado para sistemas interactivos2009/2010Engenharia do Software I38

39. Exemplo: Sistema de processamento de facturas2009/201039Engenharia do Software IEmitir recibosRecibosLer facturas emitidasIdentificar pagamentosProcurar pagamentos devidosEmitir lembrete de pagamentoLembretesFacturasPagamentos

40. Vantagens do modelo de fluxo de dadosSuporta reutilização de transformaçõesOrganização intuitiva para comunicar com partes interessadasFácil adicionar novas transformaçõesRelativamente fácil de implementar em sistemas concorrentes e sequenciaisMas requer formato comum para transferência de dados e difícil suportar interacção baseada em eventos2009/2010Engenharia do Software I40

41. Estilos de controloFocam-se no fluxo de controlo entre subsistemasDistintos do modelo de decomposição do sistema2009/2010Engenharia do Software I41

42. Estilos de controlo2009/2010Engenharia do Software I42

43. Controlo centralizadoSubsistema de controlo com responsabilidade por gerir execução de outros subsistemas2009/2010Engenharia do Software I43

44. Controlo centralizado2009/2010Engenharia do Software I44

45. Modelo invocação-retorno2009/201045Engenharia do Software IPrograma principalRotina 1Rotina 3Rotina 2Rotina 1.1Rotina 1.2Rotina 1.1Rotina 1.2Rotina 1.1Rotina 1.2

46. Controlo de sistema em tempo real2009/201046Engenharia do Software IProcessos sensoresProcessos actuadoresControlador do sistemaInterface com utilizadorProcessos de computaçãoGestor de anomalias

47. Sistemas guiados por eventosGuiados por eventos gerados externamenteInstante de ocorrência dos eventos fora do controlo dos subsistemas que o processamDois principais modelosDifusãoGuiados por interrupçõesOutros modelosFolhas de cálculoSistemas de produção2009/2010Engenharia do Software I47

48. Modelos de sistemas guiados por eventos2009/2010Engenharia do Software I48

49. Modelo de difusãoEficaz para integrar subsistemas em diferentes computadores de uma redeSubsistemas registam interesse em eventos específicos; quando ocorrem, controlo transferido para subsistemas que com eles podem lidarPolítica de controlo não está no gestor de eventos e mensagens; subsistemas decidem que eventos são do seu interesseNo entanto, subsistemas não sabem se e quando um evento será processado2009/2010Engenharia do Software I49

50. Difusão selectiva2009/201050Engenharia do Software ISubsistema 1Subsistema 4Subsistema 3Subsistema 2Gestor de mensagens e eventos

51. Sistemas guiados por interrupçõesUsados em sistemas de tempo real onde é essencial responder rápido a eventosUm gestor definido para cada tipo de interrupções conhecidoCada tipo associado a posição de memória; comutador hardware transfere para gestor associadoPermitem resposta rápida, mas complexos de programar e difíceis de validar2009/2010Engenharia do Software I51

52. Controlo guiado por interrupções2009/201052Engenharia do Software IInterrupçõesVector de interrupçõesGestor 1Gestor 2Gestor 3Gestor 4Processo 1Processo 2Processo 3Processo 4

53. Arquitecturas de referênciaModelos arquitectónicos podem ser específicos de um dado domínio de aplicaçãoTipos de modelo específico de domínioModelos genéricosModelos de referência2009/2010Engenharia do Software I53

54. Tipos de modelo específico de domínio2009/2010Engenharia do Software I54Capítulo 13

55. Arquitecturas de referênciaModelos de referência derivados do estudo do domínio de aplicação e não de sistemas existentesUsados como base para implementação de sistemas ou para comparar sistemasSão padrão de referência para avaliação de sistemasModelo OSI é modelo em camadas para sistemas de comunicação2009/2010Engenharia do Software I55

56. Modelo de referência OSI2009/201056Engenharia do Software IAplicação7AplicaçãoApresentação6ApresentaçãoSessão5SessãoTransporte4TransporteRede3RedeRedeDados2DadosDadosFísico1FísicoFísicoMeio de comunicações

57. Modelo de referência CASE2009/2010Engenharia do Software I57

58. Modelo de referência CASE da ECMA2009/201058Engenharia do Software IOrganização de normalização de sistemas de informação e comunicaçãoVer nota neste diapositivo e no anterior.

59. A reterArquitectura de software é enquadramento fundamental para estruturar sistemasDecisões arquitectónicas de desenhoTipo de aplicaçãoDistribuição do sistemaEstilos arquitectónicosDiferentes modelos arquitectónicosEstruturalDe controloDe decomposição2009/2010Engenharia do Software I59

60. A reterModelos organizacionais de sistemasDe repositórioCliente-servidorDe máquinas abstractasModelos de decomposição modularDe objectosDe fluxo de dados2009/2010Engenharia do Software I60