Projeto de Arquitetura

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto de Arquitetura Engenharia de Software 2o. Semestre de 2005 Slide 1

2 Projeto de Arquitetura Estabelece a estrutura global de um sistema de software Slide 2

3 Objetivos Introduzir projeto arquitetural e discutir sua importância. Explicar porque vários modelos são necessários para documentar uma arquitetura de software. Descrever os tipos de modelos arquitetural que podem ser usados. Discutir como modelos de referência de domínios específicos podem ser usados como base para famílias de produtos e para comparar arquiteturas de software. Slide 3

4 Tópicos Estruturação de sistema Modelos de controle Decomposição modular Arquiteturas de domínios específicos Slide 4

5 Atividades de projeto Especificação Requir ements de specifica requisitos tion Projeto de Architectur al arquitetura design Especificação Abstr act specifica abstrata tion Projeto de interface Interface design Design acti vities Atividades do projeto Projeto de componentes Component design Projeto de estrutura de dados Data structur e design Projeto de algoritmos Algorithm design Arquitetura System architectur de sistema e Especificação Softw ar e specifica de software tion Especificação Interface de specifica interface tion Especificação Component de specifica componentes tion Especificação Data de structur estruturas e specifica de dados tion Especificação Algorithm de specifica algoritmos tion Produtos Design do pr oducts projeto Slide 5

6 Arquitetura do Software O processo inicial de projeto, que consiste em identificar os subsistemas é chamado de projeto de arquitetura. A saída desse processo de projeto é uma descrição da arquitetura do software. Slide 6

7 Projeto da arquitetura É o primeiro estágio do processo de projeto do sistema Representa a ligação entre a especificação e os processos de projeto. Freqüentemente é realizado em paralelo com algumas atividades de especificação Envolve a especificação dos componentes principais do sistema e das comunicações desses componentes. Slide 7

8 Vantagens de uma arquitetura explícita Comunicação com os usuários Arquitetura é uma representação de alto nível do sistema, que pode ser usada como ponto de discussão para diferentes usuários. Análise de sistema Significa que pode-se fazer uma análise para ver ser o sistema pode ou não cumprir requisitos não funcionais importantes (desempenho, confiabilidade, facilidade de manutenção) Reutilização em larga escala A arquitetura pode ser reutilizada em sistemas com requisitos similares ou para em um sistema pertencente a uma família de aplicações. Slide 8

9 Atividades de Processos de projeto de arquitetura Estruturação de sistema O sistema é decomposto em vários subsistemas principais e a comunicação entre esses subsistemas são identificados. Modelagem de controle É estabelecido um modelo geral dos relacionamentos de controle entre as partes do sistema. Decomposição modular Os subsistemas identificados são decompostos em módulos. O projetista deve decidir sobre o tipo de módulo e suas interconexões. Slide 9

10 Subsistemas e módulos Um subsistema é um sistema cuja operação não depende de serviços fornecidos por outros subsistema. Um módulo é um componente do sistema que fornece serviços a outros componentes, mas normalmente não é considerado um sistema independente. Slide 10

11 Modelos de arquitetura Diferentes modelos de arquitetura pode ser produzidos durante o processo de projeto. Cada modelo representa diferentes perspectivas na arquitetura. Slide 11

12 Modelos de arquitetura Modelo estrutural estático mostra os subsistemas ou componentes que devem ser desenvolvidos. Modelo de processo dinâmico mostra a estrutura do sistema em tempo de execução. Modelo de interface que define as interfaces dos subsistemas. Modelo de relacionamento Modelo de relacionamento que mostram relacionamentos entre subsistemas, tal como o fluxo de dados entre os sistemas. Slide 12

13 Estilos de arquitetura O projeto de arquitetura de um sistema pode ter como base um modelo ou um estilo de arquitetura específico. É importante uma conscientização desses modelos, de suas aplicações, pontos fortes e fracos. A maioria dos sistemas de grande porte não seguem um modelo único. Diferentes partes do sistema podem ser projetadas com o uso de diferentes modelos de arquitetura. Slide 13

14 Arquitetura vs. Requisitos não funcionais. Desempenho Operações devem ser distribuídas para um número menor de subsistemas para minimizar a comunicação entre subsistemas Proteção usar uma arquitetura em camada com alto nível de validação de proteção às camadas mais internas. Segurança Isolar componentes críticos em um pequeno número de subsistemas Disponibilidade (arquiteturas de sistemas tolerantes a falhas) Incluir componente redundantes na arquitetura. Facilidade de manutenção Usar componentes encapsulados de menor granularidade. Slide 14

15 Estruturação do sistema (modelos estruturais) Se preocupa com a decomposição do sistema em subsistemas que interagem. O projeto de arquitetura normalmente é expresso por um diagrama de blocos representando uma visão geral da estrutura do sistema. Modelos mais específicos, que mostram como os subsistemas compartilham dados, estão distribuídos e como atuam como interface entre si podem ser desenvolvidos. (modelo de repositório, modelo cliente-servidor, modelo de máquina abstrata) Slide 15

16 Sistema de controle robotizado de embalagem - Diagrama de blocos Sistema V i si on de s yvisão s te m Sistema de identificação de objetos O b j ec t i d e n t if i c a t io n s y s te m Controlador Ar m de c onbraço tr o ll er Controlador G r i p p e r c on de tr garra o ll er Sistema de P a c ka g in g seleção s e c ti ode n s y s te m embalagem P a c k i ng s y s te m Sistema de embalagem Controlador C o nv e y o rde c on o ll er transportadora Slide 16

17 O modelo de repositório Subsistemas precisam trocar informações. Isso pode ser feito de duas maneiras: Dados compartilhados são mantidos em um banco de dados central, que pode ser acessado por todos os subsistemas. Cada subsistema mantém seu próprio banco de dados e são passados explicitamente para outros subsistemas. Quando grandes quantidades de dados precisam ser compartilhados, o modelo de repositório é usado para organizar os sistemas. Ex. de sistemas: SIG, CAD, CASE, sistema de comando e controle Slide 17

18 Arquitetura de um conjunto de ferramentas CASE integrado Editor Desig nde projeto editor Gerador Co de de generato códigor Tradutor Desig nde translator projeto Repositório Pro ject repo de projeto sito ry Editor Pro g ram de programa edito r Analisador Desig n de analy projeto ser Gerador Repo rtde generato relatórior Slide 18

19 Características de um modelo de repositório Vantagens Maneira eficiente de compartilhar grandes quantidades de dados Subsistemas não precisam se preocupar em como os dados são produzidos. Gerenciamento centralizado de atividades, tais como backup, segurança, etc. O modelo de compartilhamento é visível por meio do esquema do repositório, facilitando a integração de novas ferramentas. Slide 19

20 Características de um modelo de repositório Desvantagens Subsistemas devem concordar com o modelo de dados de repositório. Inevitavelmente um compromisso. A evolução de dados é difícil e cara. Diferentes subsistemas podem ter diferentes requisitos para políticas de proteção, segurança e backup. O modelo de repositório impõe a mesma política. Dificuldade em distribuir o repositório em uma série de máquinas. Pode ser feito, porém pode haver problemas de redundância e inconsistência de dados. Slide 20

21 Arquitetura Cliente-Servidor É um modelo de sistema distribuído que mostra como os dados e o processamento são distribuídos em uma série de processadores. Conjunto de servidores stand-alone que oferece serviços a outros subsistemas, tais como impressão, gerenciamento de arquivos, etc. Conjunto de clientes que solicita esses serviços. Rede que permite os clientes acessar esses serviços. Slide 21

22 Biblioteca de filmes e fotografias Cliente 1 Cliente 2 Client 3 Cliente 4 WRede ide-bandwidth banda larga network Catalogue Servidor server de catálogo Catalogue catálogo Servidor V ideo de server vídeo Film clip Arquivos files de clipes de filmes Servidor Picture de fotografias server Digitiz ed photographs Fotografias digitalizadas Hypertext Servidor de hipertexto s erver Hypertext Web web de hipertexto Slide 22

23 Características de cliente- Servidor Vantagens É uma arquitetura distribuída, permitindo o uso efetivo de sistemas de rede com muitos processadores distribuídos. É fácil incluir um novo servidor e integrá-lo com o restante do sistema ou fazer a atualização do servidor de forma transparente. Normalmente requer hardware mais barato Desvantagens Não há modelo de dados compartilhado, assim os subsistemas usam diferentes organizações de dados. A troca de dados pode ser ineficiente. Gerenciamento redundante em cada servidor. Não existe um registro central de nomes e serviços - pode ser difícil encontrar quais servidores e serviços estão disponíveis Slide 23

24 Modelo de máquina abstrata Usado para modelar a interface de subsistemas Organiza o sistema em um conjunto de camadas (ou máquinas abstratas), cada uma das quais fornece um conjunto de serviços A abordagem em camadas apoia o desenvolvimento gradativo de sistemas. Também facilita mudanças e apresenta portabilidade Uma desvantagem é que pode ser difícil estruturar sistemas dessa maneira. Slide 24

25 Modelo de máquina abstrata (cont) Camada externa pode não ser dependente apenas de sua camada imediatamente anterior Desempenho pode ser comprometido se houver muitas camadas. Slide 25

26 Sistema de gerenciamento de versões (modelo de máquina abstrata) Gerenciamento de Versões Gerenciamento de objetos Sistema de banco de dados Sistema Operacional Slide 26

27 Modelos de controle Diferentes do modelo de decomposição, estão preocupados com a dinâmica ( fluxo de controle) entre os subsistemas. Controle centralizado Um subsistema tem a responsabilidade geral pelo controle e inicia e interrompe os outros. Controle baseado em eventos Cada subsistema pode responder a eventos gerados externamente. Esses eventos poder provir de outros subsistemas ou do ambiente do sistema. Slide 27

28 Controle centralizado Um subsistema tem a responsabilidade de gerenciar a execução dos outros subsistemas. Modelo retorno de chamadas Modelo de controle de subrotina top-down onde o controle começa no topo da hierarquia de subrotina e passa para níveis inferiores na árvore. Aplicável a sistemas seqüenciais. Modelo gerenciador Aplicável a sistemas concorrentes. Um componente do sistema controla o início, a interrupção e a coordenação de outro processos de sistema. Pode ser implementado em sistemas seqüenciais como um comando case. Slide 28

29 Modelo de retorno de chamadas M ain p rog ram Programa Principal R outine 1 Ro utine 2 Routine 3 Rotina 1 Rotina 2 Rotina 3 Rotina 1.1 Rotina 1.2 Rotina 3.1 Rotina 3.2 Rout in e 1.1 Ro ut in e 1.2 Routine 3.1 Ro utin e 3.2 Slide 29

30 Modelo de controle centralizado para sistema de tempo real Processos Sen sor pde ro sensor ces ses Actuator Processos pde roces atuador ses Controlador System contr do sistema o ller CoProcessos mpu tatio n computacionais p ro cesses Interfaces Us ercom o interface usuários Manipulador Fault de h andler defeitos Slide 30

31 Controle baseado a eventos São dirigidos por eventos gerados externamente onde a ocorrência desse evento está fora do controle do processo que manipula esse evento. Dois modelos de controle principais: Modelos de transmissão. Um evento é transmitido para todos os subsistemas. Qualquer subsistema que puder manipular esse evento responderá a ele. Modelos dirigidos por interrupções. Usados em sistemas de tempo real, onde interrupções são detectadas por um manipulador de interrupções e passados para algum outro componente para processamento. Slide 31

32 Modelo de transmissão Eficazes na integração de subsistemas distribuídos em diferentes computadores em rede. Subsistemas registram um interesse em eventos específicos. Quando esses ocorrem, o controle é transferido para o subsistema que pode manipular o evento. A política de controle não está incluída no evento e no manipulador de mensagens. Os subsistemas decidem quais eventos interessam a eles. Slide 32

33 Modelo de controle com base em transmissão (broadcasting seletiva) Sub-s Subsistema ystem 1 Subsistema b-s ystem 2 Subsistema Sub-s ys tem 3 Sub-sys Subsistema 4 Manipulador Event de aneventos d mes sa ge e mensagens han dler Slide 33

34 Modelo orientado a interrupção Usado em sistemas de tempo-real onde a resposta rápida a um evento é essencial. Existem um número conhecido de tipos de interrupções, com um manipulador definido para cada tipo Cada tipo é associado com a locação de memória e um comutador de hardware provoca a transferência de controle para o seu manipulador. Permite resposta rápida, mas a programação é complexa e sua validação é difícil. Slide 34

35 Controle orientado a interrupção Interrupções ts Vetor Interrup de t interrupções vector Manipulador Handl er 1 Manipulador Han dler 2 Manipulador Handl er 33 Manipulador Han dler 4 Processo 1 Processo 2 Processo 3 Processo 4 Slide 35

36 Decomposição em módulos Outro nível estrutural, onde os subsistemas são decompostos em módulos. Dois modelos de decomposição modular serão discutidos: Modelo orientado a objeto - onde o sistema é decomposto em objetos que interagem entre si. Modelo de fluxo de dados - onde o sistema é decomposto em módulos funcionais que transformam entradas em saídas. Também chamado de abordagem de pipeline. Se possível, decisões sobre concorrência ou paralelismo devem ser postergadas até a fase de implementação dos módulos Slide 36

37 Modelos de Objetos Estruturam o sistema em um conjunto de objetos fracamente acoplados com interfaces bem definidas. Decomposição orientada a objetos se preocupa em identificar classes de objetos, seus atributos e operações. Quando implementada, os objetos são criados a partir dessas classes e algum modelo de controle é utilizado para coordenar as operações de objetos. Slide 37

38 Sistema de processamento de faturas (modelo de objetos) Customer Cliente customer# Cliente name # nome address endereço credit period período de crédito Pagamento Payment fatura invoice# # data date quantia amount cliente# customer# Fatura Invoice fatura invoice# # data date quantia amount cliente customer issue () emissão() sendr nder () enviaraviso() acceptpayment () aceitarpagamento() sendr eceipt enviarrecibo() Recibo Receipt invoice# fatura date # data amount quantia cus tomer# cliente # Slide 38

39 Modelos de fluxo de dados Transformações funcionais processam suas entradas e produzem saídas. Podem ser referenciados como um modelo pipe e filtro (como no UNIX) Variantes dessa abordagem são bastante comuns. Quando as transformações são seqüenciais, com dados processados em lotes, esse modelo de arquitetura é um modelo seqüencial em lotes. Não muito apropriado para sistemas interativos Slide 39

40 Sistema de processamento de faturas (modelo de fluxo de dados) Emitir recibos Issue receipts Receipts Recibos Ler faturas emitidas Read issued invo ices Faturas Invoices Identificar Identify pagamentos paymen ts Pagamentos Payments Encontrar Find pagamentos payments devidos due Issu e p ay ment reminder Emitir avisos de pagamento avisos Remin ders Slide 40

41 Arquiteturas de domínio específico Modelos de arquitetura que são específicos a algum domínio de aplicação. Existem dois tipos de modelo de arquitetura de domínio específico: Modelos Genéricos - que são abstrações de vários sistemas reais e que englobam as características principais desses sistemas. Em sistemas de tempo real: modelos de arquitetura genéricos para sistemas de coleta de dados, sistemas de monitoramento, etc Modelos de Referência - são mais abstratos e descrevem uma classe maior de sistemas. São um meio de informar ao projetista sobre a estrutura geral daquela classe de sistema. Ex. modelo de referência idealizado para fábricas de software Slide 41

42 Arquiteturas de domínio específico Modelos genéricos, representações abstratas de sistemas, são derivados bottom-up, a partir de sistemas existentes. Modelos de referência são derivados top-down. Não refletem necessariamente a arquitetura real dos sistemas existentes no domínio. Slide 42

43 Modelos genéricos O exemplo mais conhecido de um modelo genérico de arquitetura é um modelo de compilador. Analisador léxico Tabela de símbolos Analisador sintático Árvore sintática Analisador semântico Gerador de código Os componentes que constituem um compilador podem ser organizados de acordo com diferentes modelos de arquitetura. Slide 43

44 Modelo de fluxo de dados de um compilador Tabela Symbol de símbolos table Lexical Análise analysis Léxica Syntactic Análise analysis Sintática Semantic Análise Semântica analysis Geração Code generation de código Slide 44

45 Modelo de repositório de um sistema de processamento de linguagens Analisador Lex ical analy Léxico ser Analisador Syntax analyser Sintatico Sem Analisador antic anal Semântico yser Prettyp Impressora rinter Árvore Abs tract de sintaxe s yntax abstrata tree Gram Definição m ar dgramatical efi ni tion Otimizador Optim izer Editor Tabela Sym bodel símbolos table Definição Ou tpu t dde efi saída ni tion Gerador Co de generator de código Repo sitory Slide 45

46 Arquiteturas de referência Modelos de referência são derivados de um estudo do domínio da aplicação, e não de sistemas existentes. Podem ser utilizadas como uma base para comparar diferentes sistemas. Atua como um padrão, em relação ao qual os sistemas podem ser avaliados O modelo OSI de protocolos de redes é um modelo em camadas para a interconexão de sistemas abertos. Slide 46

47 Arquitetura do modelo de referência OSI 7 Aplicação Aplicação 6 Apresentação Apresentação 5 Sessão Sessão 4 Transporte Transporte 3 Rede Rede Rede 2 Ligação Ligação Ligação 1 Física Física Física Meios de comunicação Slide 47

48 Outros modelos de referência Modelo para ambiente CASE Alguns padrões de projeto de software. Slide 48

49 Pontos-chave Projeto de arquitetura mostra a estruturação do sistema. Podem ser desenvolvidos diferentes modelos de arquitetura: modelo estrutural, modelo de controle e modelo de decomposição. Modelos estrutural de sistemas incluem modelo de repositório, modelo cliente-servidor e modelo de máquina abstratas. Modelos de controle Modelos de controle incluem os modelos centralizados e os modelos de eventos. Slide 49

50 Pontos-chave Os modelos de decomposição em módulos incluem os modelos de fluxo de dados e os modelos de objetos. Os modelos de arquitetura de domínio específicos são abstrações em relação a um domínio de aplicação. Podem ser construídos a partir de sistemas existentes ou podem ser modelos de referência idealizados. Slide 50

51 Slide 51