Princípios de Engenharia de Software. Aula 6 Projeto de Software

Transcrição

1 Princípios de Engenharia de Software Aula 6 Projeto de Software

2 Projeto de Software Um projeto de software é uma descrição de estrutura de software a ser implementada, dos dados que são parte do sistema, das interfaces entre os componentes do sistema e, algumas vezes, dos algoritmos utilizados. O processo de projeto pode envolver o desenvolvimento de vários modelos do sistema, em diferentes níveis de abstração. Na decomposição de um projeto, são descobertos erros e omissões em estágios anteriores. Essas informações de feedback permitem a melhoria de modelos de projeto anteriores. 2

3 Projeto de Software Entrada Etapas Resultados Especificação de Requisitos Projeto de Arquitetura Especificação Abstrata Arquitetura de Sistema Especificação de Software Projeto de Interface Especificação de Interface Projeto de Componentes Especificação de Componentes Projeto de Estrutura de Dados Especificação de Estrutura de Dados Projeto de Algoritmos Especificação de Algoritmos Figura 1: modelo geral do processo de projeto 3

4 Projeto de Software As atividades específicas de processo de projeto são: 1. Projeto de Arquitetura os subsistemas que constituem o sistema e suas relações são identificados e documentados. 2. Especificação Abstrata para cada subsistema, é produzida uma especificação abstrata de suas funções e das restrições dentro das quais deve operar. 3. Projeto de interface para cada subsistema, sua interface com outros subsistemas é projetada e documentada. 4. Projeto de Componentes funções são alocadas a diferentes componentes e as interfaces desses componentes são projetadas. 5. Projeto de estrutura de dados as estruturas de dados utilizadas na implementação de sistemas são projetadas em detalhe e especificadas. 6. Projeto de algoritmos os algoritmos utilizados para proporcionarem serviços são projetados detalhadamente e especificados. 4

5 Projeto de Arquitetura Os grandes sistemas são sempre decompostos em subsistemas, que fornecem algum conjunto de serviços relacionados. O processo inicial de projeto, que consiste em identificar esses subsistemas e estabelecer um framework para o controle e a comunicação de subsistemas é chamado de projeto de arquitetura. A saída desse processo de projeto é uma descrição da arquitetura do software. O modelo de arquitetura é, com freqüência, o ponto de partida para a especificação das várias partes do sistema. 5

6 Projeto de Arquitetura Vantagens de se projetar e documentar explicitamente uma arquitetura de software [Bass et al.,1998]: 1. Comunicação com os stakeholders a arquitetura é uma apresentação de alto nível do sistema, que pode ser utilizada como um ponto de discussão para uma gama de diferentes stakeholders. 2. Análise de Sistema tornar explícita a arquitetura de sistemas significa que alguma análise pode ser realizada. As decisões de projeto de arquitetura têm efeito sobre se o sistema pode ou não cumprir requisitos como desempenho, confiabilidade e facilidade de manutenção. 3. Reutilização em larga escala a arquitetura de sistemas é uma descrição compacta e administrável de como um sistema é organizado e de como os componentes operam entre si. Ela pode ser transferida por meio de sistemas com requisitos semelhantes e, dessa forma, fornecer apoio ao reuso de software em larga escala. 6

7 Projeto de Arquitetura Atividades comuns a todos os processos de projeto de arquitetura de software: 1. Estruturação de sistema o sistema é estruturado em uma série de subsistemas principais, em que cada subsistema é uma unidade de software independente. 2. Modelagem de Controle é estabelecido um modelo geral dos relacionamentos de controle entre as partes do sistema. 3. Decomposição modular cada subsistema identificado é decomposto em módulos. Estas atividades são geralmente intercaladas, ao invés de realizadas em seqüência. Durante qualquer um desses processos, é possível que se desenvolva o projeto mais detalhadamente, para averiguar se as decisões de projeto de arquitetura permitem que o sistema cumpra seus requisitos. 7

8 Projeto de Arquitetura A distinção entre subsistemas e módulos não é muito nítida, mas pode-se definir cada um desses conceitos da forma seguinte: 1. Um subsistema é um sistema cuja operação não depende dos serviços fornecidos por outros subsistemas. Os subsistemas são compostos de módulos e têm interfaces definidas, as quais são utilizadas para a comunicação entre subsistemas. 2. Um módulo é geralmente um componente de sistema que fornece um ou mais serviços para outros módulos. Ele utiliza serviços fornecidos por outros módulos e normalmente não é considerado um sistema independente. Os módulos são compostos de uma série de outros componentes de sistema mais simples. A saída do processo de arquitetura é um documento de projeto de arquitetura. Este documento consiste em uma série de representações gráficas dos modelos de sistema, com o texto descritivo associado. 8

9 Projeto de Arquitetura Os diferentes modelos gráficos do sistema apresentam diferentes perspectivas sobre a arquitetura. Entre os modelos de arquitetura que podem ser desenvolvidos estão: 1. Modelo estrutural estático que mostra os subsistemas ou componentes que devem ser desenvolvidos como unidades separadas. 2. Modelo de Processo Dinâmico que mostra como o sistema é organizado em processos em run-time (tempo de execução). Esse processo pode ser diferente do modelo estático. 3. Modelo de Interface que define os serviços oferecidos por cada subsistema em sua interface pública. 4. Modelos de Relacionamento que mostram relacionamentos como o fluxo de dados entre os subsistemas. 9

10 Projeto de Arquitetura A arquitetura do sistema afeta o desempenho, a robustez e a facilidade de distribuição e de manutenção de um sistema. A estrutura e o estilo específico escolhidos para uma aplicação podem, portanto, depender dos requisitos não-funcionais do sistema: 1. Desempenho - se o desempenho for um requisito importante, isso sugere que a arquitetura deve ser projetada para restringir as operações mais importantes dentro de um pequeno número de subsistemas com a menor comunicação possível entre esses subsistemas. 2. Proteção - se a proteção for um requisito fundamental, isso sugere uma estrutura em camadas para a arquitetura, com os ítens mais importantes nas camadas internas. 10

11 Projeto de Arquitetura Disponibilidade se a disponibilidade for um requisito importante, a arquitetura deve conter componentes redundantes, para que seja possível substituir e atualizar componentes, sem a interrrupção do sistema. 4. Facilidade de Manutenção - se a facilidade de manutenção for um requisito fundamental, isso vai sugerir que a arquitetura deve ser projetada utilizando-se componentes encapsulados de menor granularidade, que possam ser rapidamente modificados. Os produtores de dados devem ser separados dos consumidores e as estruturas de dados compartilhadas devem ser evitadas. Existe um conflito em potencial entre algumas dessas arquiteturas. Por exemplo, o desempenho é melhorado pelo uso de componentes de maior granularidade, enquanto que a facilidade de manutenção sugere componentes de menor granularidade. Se ambas as características forem importantes, será necessário encontrar uma solução intermediária.

12 1. Estruturação do Sistema A primeira fase da atividade de projeto de arquitetura é geralmente voltada para a decomposição do sistema em um conjunto de subsistemas que interagem. Em seu nível de maior abstração, um projeto de arquitetura pode ser representado como um diagrama de blocos, em que cada bloco do diagrama representa um subsistema. Blocos dentro de blocos indicam que o subsistema foi, por sua vez, decomposto em subsistemas. As setas indicam que dados e/ou controles são passados de subsistema para subsistema, na direção das setas. 12

13 1. Estruturação do Sistema Exemplo: modelo estrutural de arquitetura para um sistema robotizado de embalagem. Sistema de Visão Sistema de Identificação de Objetos Controlador de Braço Controlador de Garra Sistema de seleção de embalagem Sistema de embalagem Controlador de transportadora 13 Figura 2: Diagrama de Blocos de sistema de controle robotizado de embalagem

14 1. Estruturação do Sistema Exemplo: modelo estrutural de arquitetura para um sistema robotizado de embalagem. Esse sistema de robô pode embalar diferentes tipos de objetos. Ele utiliza um subsistema de visão para apanhar objetos em uma transportadora, identifica o tipo de objeto e seleciona o tipo certo de embalagem. Em seguida, ele retira objetos da transportadora de entrega para serem embalados. Os objetos embalados são colocados em outra transportadora. 14

15 1. Estruturação do Sistema Os diagramas de blocos são eficazes na comunicação com os stakeholders (clientes) do sistema, e para planejar o projeto. O modelo estrutural de arquitetura representado por um diagrama de blocos identifica os principais subsistemas que serão desenvolvidos independentemente. Modelos mais específicos de arquitetura podem ser desenvolvidos, os quais mostram como os subsistemas compartilham dados, como estão distribuídos e como atuam como interface entre si. Modelos-padrão que serão discutidos: 1.1) modelo de repositório, 1.2) modelo clienteservidor e 1.3) modelo de máquina abstrata. 15

16 1.1) Modelo de Repositório Os subsistemas que constituem um sistema precisam trocar informações, para que possam trabalhar em conjunto de modo eficaz. Existem duas maneiras fundamentais para fazê-lo: 1. Todos os dados compartilhados são mantidos em um banco de dados central, que pode ser acessado por todos os subsistemas. Um modelo de sistema com base em um banco de dados compartilhado é, algumas vezes, chamado de modelo de repositório. 2. Cada subsistema mantém seu próprio banco de dados. Os dados são intercambiados com outros subsistemas, transmitindo mensagens para eles. 16

17 1.1) Modelo de Repositório A maioria dos sistemas que utilizam grande quantidade de dados é organizada em termos de um banco de dados compartilhado ou de um repositório. Esse modelo é, portanto, adequado a aplicações em que os dados são gerados por um subsistema e utilizados por outro. Exemplos deste tipo de sistema: sistemas de comando e controle, sistemas de informações gerenciais, sistemas de CAD (computer-aided design projeto auxiliado por computador), e os conjuntos de ferramentas CASE. 17

18 1.1) Modelo de Repositório Exemplo Prático: arquitetura de conjunto de ferramentas CASE, com base em um repositório compartilhado. Editor de Projeto Gerador de Código Tradutor de Projeto Repositório de Projeto Editor de Programa Analisador de Projeto Gerador de Relatório Figura 1: Arquitetura de um conjunto de ferramentas CASE integrado. 18

19 1.1) Modelo de Repositório Vantagens e desvantagens de um modelo de repositório compartilhado: É uma maneira eficiente de compartilhar grandes quantidades de dados. Não há necessidade de transmitir os dados explicitamente de um sistema para outro. Contudo, os subsistemas devem concordar com o modelo de dados de repositório. Este é um meio de conciliar as necessidades específicas de cada ferramenta. O desempenho pode ser prejudicado. A evolução pode ser difícil, uma vez que um grande volume de informações é gerado de acordo com o modelo de dados estabelecido. Atividades de backup e segurança podem ser delegadas ao gerente de repositório, as ferramentas podem focalizar suas principais funções, sem se ocupar com essas questões. O modelo de repositório impõe a mesma política de segurança a todos os subsistemas. 19

20 1.2) Modelo Cliente-Servidor O modelo de arquitetura de 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. Os componentes principais deste modelo são: Um conjunto de servidores em stand-alone, que oferece serviços a outros subsistemas. Exemplos: servidores de impressoras, que oferecem serviços de impressão; servidores de arquivo, que oferecem serviços de gerenciamento de arquivos, e servidores de compilação, que oferecem serviços de compilação de linguagem de compilação. Um conjunto de clientes que solicita os serviços oferecidos pelos servidores. Estes são, normalmente, subsistemas em si. É possível que haja várias instâncias de um programa cliente sendo executadas simultaneamente. Uma rede que permite aos clientes acessar esses serviços. 20

21 1.2) Modelo Cliente-Servidor É possível que os clientes tenham de saber os nomes dos servidores disponíveis, e dos serviços que eles fornecem. Contudo, os servidores não precisam saber a identidade de clientes ou quantos clientes existem. Os clientes têm acesso aos serviços fornecidos por meio de chamadas remotas. A abordagem Cliente-Servidor pode ser utilizada para implementar um sistema com base em repositórios, em que o repositório é fornecido como um servidor de sistemas. Os subsistemas que têm acesso ao repositório são clientes. No entanto, normalmente, cada subsistema gerencia seus próprios dados. 21

22 1.2) Modelo Cliente-Servidor Exemplo de arquitetura Cliente-Servidor: sistema de hipertexto para vários usuários, destinado a fornecer uma biblioteca de filmes e fotografias. Cliente 1 Cliente 2 Cliente 3 Cliente 4 Rede de Banda Larga Servidor de Catálogo Servidor de Vídeo Servidor de Fotografias Servidor de Hipertexto Catálogo Arquivos de clipes de Vídeo Fotografias Digitalizadas Web de Hipertexto Figura 2: Arquitetura de um sistema de biblioteca de filmes e fotografias. 22

23 1.2) Modelo Cliente-Servidor Exemplo de arquitetura Cliente-Servidor: sistema de hipertexto para vários usuários. Objetivo: fornecer uma biblioteca de filmes e fotografias. Configuração: nesse sistema, há vários servidores que gerenciam e exibem os diferentes tipos de mídia. Características: os frames do filme precisam ser transmitidos com rapidez e em sincronia, mas com resolução relativamente baixa. Eles precisam ser compactados em um repositório. As imagens (fotografias) precisam ser transmitidas com alta resolução. O catálogo deve ser capaz de lidar com uma variedade de consultas e fornecer links com os sistemas de informações de hipertexto. O programa cliente é simplesmente uma interface com o usuário, integrada a esses serviços. 23

24 1.2) Modelo Cliente-Servidor Arquitetura Cliente-Servidor: mais características Mudanças nos clientes e servidores existentes podem ser necessárias, afim de se obter os benefícios plenos da integração de um novo servidor. Não há nenhum modelo de dados compartilhado e os subsistemas geralmente organizam seus dados de diferentes formas. Isso significa que modelos específicos de dados podem ser estabelecidos para cada servidor, o que permite otimizar o seu desempenho. A falta de um modelo de referência compartilhado de dados pode sigfnificar que é difícil prever problemas na integração de dados a partir de um novo servidor. Cada servidor deve assumir a responsabilidade por atividades de gerenciamento de dados, como backup e recuperação. 24

25 1.3) Modelo de Camadas Modelo de camadas também é conhecido como modelo de máquina abstrata. Esta arquitetura modela a interface de subsistemas e organiza um sistema em uma série de camadas cada uma das quais fornece um conjunto de serviços. Cada camada define uma máquina abstrata, cuja linguagem de máquina (os serviços fornecidos pela camada) é utilizada para implementar o próximo nível de máquina abstrata. Exemplo: uma forma comum de implementar uma linguagem é definir uma máquina de linguagem ideal e compilar a linguagem no código para essa máquina. Uma etapa adicional de tradução converte esse código de máquina abstrata em código de máquina real. Outro exemplo: modelo de camadas OSI de protocolos de rede (Zimmermann, 1980). 25

26 1.3) Modelo de Camadas Exemplo de Modelo de Camadas: sistema de gerenciamento de versões. Gerenciamento de Versões Gerenciamento de Objeto Sistema de Banco de Dados Sistema Operacional Figura 3: Modelo de máquina abstrata de um sistema de gerenciamento de versões. 26

27 1.3) Modelo de Camadas Exemplo de Modelo de Camadas: sistema de gerenciamento de versões. O sistema de gerenciamento de versões se dedica a gerenciar versões de objetos e fornece recursos gerais de gerenciamento de configuração. Para apoiar esses recursos de gerenciamento de configuração, ele utiliza um sistema de gerenciamento de objetos que fornece serviços de armazenamento e gerenciamento de informações para objetos. Esse sistema emprega um sistema de banco de dados para fornecer armazenamento e serviços de dados básicos, como o gerenciamento de transações, o a recuperação e controle de acesso. O gerenciamento de banco de dados utiliza os recursos básicos de sistema operacional e de repositório de arquivos em sua implementação. 27

28 1.3) Modelo de Camadas Modelo de Camadas: mais características A abordagem em camadas apóia o desenvolvimento gradativo de sistemas. À medida que uma camada é desenvolvida, alguns serviços fornecidos por aquela camada podem se tornar disponíveis para os usuários. Essa arquitetura também pode ser modificada e apresenta portabilidade. Se sua interface for preservada, uma camada poderá ser substituída por outra camada. Quando as interfaces em camadas se modificam, somente a camada adjacente é afetada. Desvantagem da abordagem em camadas: pode ser difícil estruturar sistemas dessa maneira. Recursos básicos, como o gerenciamento de arquivos, exigidos por todas as máquinas abstratas, podem ser fornecidos por camadas internas. Ocorre subversão do modelo, quando uma camada externa não é mais simplesmente dependente da camada imediatamente anterior. 28

29 2) Modelos de Controle Os modelos para estruturar um sistema se ocupam de como um sistema é decomposto em subsistemas. Para trabalhar como um sistema, os subsistemas devem ser controlados de modo que seus serviços sejam fornecidos no local certo e no tempo certo. Os modelos estruturais não incluem (e não devem fazê-lo) informações de controle. O arquiteto de sistemas deve organizar os subsistemas de acordo com algum modelo de controle que complemente o modelo estrutural utilizado. Os modelos de controle em nível de arquitetura dizem respeito ao controle de fluxo entre subsistemas. 29

30 2) Modelos de Controle Pode-se identificar duas abordagens gerais de controle: 2.1) Controle Centralizado Um subsistema tem a responsabilidade geral pelo controle e inicia e interrompe os outros subsistemas. Ele pode também devolver o controle para outro subsistema, mas aguardará que essa responsabilidade pelo controle seja devolvida a ele. 2.2) Controle baseado em eventos em vez de ter as informações de controle embutidas em um subsistema, cada subsistema pode responder a eventos gerados externamente. Esses eventos podem provir de outros subsistemas ou do ambiente do sistema. 30

31 2) Modelos de Controle Os modelos de controle complementam os modelos estruturais. Todos os modelos estruturais mostrados anteriormente (repositório, cliente-servidor, máquina abstrata ou de camadas) podem ser realizados com o uso do: 2.1) controle centralizado; ou 2.2) controle baseado em eventos. 31

32 2.1) Controle Centralizado Em um modelo de controle centralizado, um subsistema é escolhido como o controlador do sistema e tem a responsabilidade de gerenciar a execução dos outros subsistemas. Os modelos de controle centralizado se dividem em duas classes, que dependem de os subsistemas controlados operarem seqüencialmente ou em paralelo. 32

33 2.1) Controle Centralizado Modelo retorno de chamadas esse é o familiar modelo de subrotina top-down, em que o controle começa na parte superior de uma hierarquia de sub-rotina e, por meio de chamadas de sub-rotina, passa para níveis mais inferiores na árvore. Modelo Gerenciador pode ser aplicado a sistemas concorrentes. Um componente de sistema é designado como um gerenciador do sistema e controla o início, a interrupção e a coordenação de outros processos do sistema. 33

34 2.1) Controle Centralizado Modelo retorno de chamadas É um modelo de dinâmica do programa, e não um modelo estrutural. Programa Principal Rotina 1 Rotina 2 Rotina 3 Rotina 1.1 Rotina 1.2 Rotina 3.1 Rotina 3.2 Figura 4: Modelo de retorno de chamadas 34

35 2.1) Controle Centralizado Modelo retorno de chamadas O modelo retorno de chamadas está representado na figura 4. O programa principal pode chamar as subrotinas 1, 2 e 3; a rotina 1 pode chamar as rotinas 1.1 ou 1.2; a rotina 3 pode chamar as rotinas 3.1 ou 3.2, e assim por diante. Não existe necessidade de a rotina 1.1, por exemplo, fazer parte da rotina 1 (esse não é um modelo estrutural). 35

36 2.1) Controle Centralizado Modelo gerenciador Um modelo de gerenciamento centralizado de controle para um sistema concorrente está representado na figura 5. Este modelo é, frequentemente, utiizado em sistemas de tempo real simples, que não têm restrições de tempo muito rígidas. O controlador central gerencia a execução de um conjunto de processos associados com sensores e atuadores. Exemplo: sistema controlador de edifícios. 36

37 2.1) Controle Centralizado Modelo gerenciador Modelo de gerenciamento centralizado de controle para um sistema concorrente. Processos de Sensor Processos de Atuador Processos Computacionais Controlador do Sistema Interfaces com o usuário Manipulador de defeitos Figura 5: Modelo de controle centralizado para sistema de tempo real. 37 O controlador central gerencia a execução de um conjunto de processos associados com sensores e atuadores.

38 2.1) Controle Centralizado Modelo gerenciador O processo controlador de sistemas decide quando os processos devem ser iniciados ou interrompidos, dependendo das variáveis de estado do sistema. Ele verifica se outros processos produziram informações que devem ser processadas ou se é preciso transmitir informações a eles para processamento. De um modo geral, o controlador está em um loop contínuo, verificando sensores e outros processos para eventos e mudanças de estado. 38

39 2.2) Sistemas Orientados a Eventos Nos modelos de controle centralizados, as decisões de controle são normalmente determinadas pelos valores de algumas variáveis de estado do sistema. Por outro lado, os modelos de controle orientados a eventos são baseados em eventos gerados externamente. O termo evento, neste contexto, não significa somente um sinal binário; ele pode ser um sinal capaz de assumir uma gama de valores. 39

40 2.2) Sistemas Orientados a Eventos A distinção entre um evento e uma entrada simples é que a ocorrência do evento está fora do controle do processo que manipula este evento. Um subsistema pode precisar acessar as informações de estado, a fim de manipular esses eventos, mas essas informações de estado em geral não determinam o fluxo de controle. Exemplos de sistemas orientados a eventos que podem ser desenvolvidos: planilhas de cálculo, em que a mudança do valor de uma célula faz com que outras células sejam modificadas; sistemas de produção com base em regras, como utilizado na Inteligência Artificial. 40

41 2.2) Sistemas Orientados a Eventos Modelos de Controle orientados a eventos: 1. Modelo de transmissão nesses modelos, um evento é, em princípio, transmitido para todos os subsistemas. Qualquer subsistema que puder manipular esse evento responderá a ele. 2. Modelos orientados a interrupções são exclusivamente utilizados em sistemas de tempo real, em que interrupções externas são detectadas por um manipulador de interrupções. Eles são, então, passados para algum outro componente para processamento. 41

42 2.2) Sistemas Orientados a Eventos Os modelos de transmissão são eficazes na integração de subsistemas distribuídos em diferentes computadores em rede. Modelos dirigidos por interrupção são utilizados em sistemas de tempo real com rigorosos requisitos de tempo. Em um modelo de transmissão, os subsistemas registram um interesse em eventos específicos. Quando estes eventos ocorrem, o controle é transferido para o subsistema que pode manipular o evento. A distinção entre este modelo e o centralizado é que a política de controle não está incluída no evento e no manipulador de mensagens. 42

43 2.2) Sistemas Orientados a Eventos Modelo de transmissão Todos os eventos podem ser transmitidos para todos os subsistemas, mas isso exige uma grande quantidade de processamento adicional. Mais frequentemente, o manipulador de eventos e mensagens mantém um registro de subsistemas e eventos que lhe interessa. Os subsistemas geram eventos que indicam, talvez, que alguns dados estão disponíveis para processamento. O manipulador de eventos detecta os eventos, consulta o registrador de eventos e passa o evento para aqueles subsistemas que declararam interesse. 43

44 2.2) Sistemas Orientados a Eventos Modelo de transmissão O manipulador de eventos também aceita a comunicação ponto a ponto, ou seja, um subsistema pode explicitamente enviar uma mensagem para outro sistema. Vantagem desta abordagem: evolução é relativamente simples. Novos subsistemas podem ser integrados, registrando-os no manipulador de eventos. Subsistema 1 Subsistema 2 Manipulador de Eventos e Mensagens Subsistema 3 Subsistema 4 Figura 6: Modelo de controle baseado em transmissão (broadcasting) seletiva. 44

45 2.2) Sistemas Orientados a Eventos Modelo orientado a interrupções Os sistemas de tempo real que requerem eventos gerados externamente para serem manipulados muito rapidamente, devem ser orientados a eventos. Exemplo: sistema de tempo real utilizado para controlar o sistema de segurança de um carro, que deve detectar uma possível colisão e talvez inflar um air-bag antes que a cabeça do motorista bata no volante. Para proporcionar esta resposta rápida, o controle dirigido por interrupções deve ser utilizado. 45

46 2.2) Sistemas Orientados a Eventos Modelo orientado a interrupções Existe um número conhecido de tipos de interrupção, com um manipulador definido para cada um deles. Cada tipo de interrupção é associado com a locação de memória em que seu endereço de manipulador estará armazenado. Quando ocorre uma interrupção de um tipo específico, um comutador de hardware provoca a transferência de controle imediatamente para seu manipulador. Este manipulador de interrupção pode então, iniciar ou interromper outros processos, em resposta ao evento assinalado pela interrupção. 46

47 2.2) Sistemas Orientados a Eventos Modelo orientado a interrupções Um modelo de controle dirigido por interupções está ilustrado na figura 7. Interrupções Vetor de Interrupção Manipulador 1 Manipulador 2 Manipulador 3 Processo 1 Processo 2 Processo 3 Figura 7: Modelo de controle dirigido por interrupções 47

48 2.2) Sistemas Orientados a Eventos Modelo orientado a interrupções Este modelo deve ser utilizado somente em sistemas de tempo real, em que a resposta imediata a algum evento seja necessária. Ele pode ser combinado com o modelo de gerenciamento centralizado. O gerenciador central cuida da operação normal do sistema, com o controle baseado em interrupções para emergências. Vantagem desta abordagem de controle: permite respostas muito rápidas para os eventos a serem implementados. Desvantagem: sua programação é complexa e a sua validação é difícil. Pode ser impossível repetir padrões de tempo de interrupção durante o processo de teste do sistema e pode ser difícil modificar sistemas desenvolvidos utilizando-se este modelo, especialmente se o número de interrupções for limitado por hardware. 48