Um sistema de Tempo Real para Controle de Quarto

Apresentação em tema: "Um sistema de Tempo Real para Controle de Quarto"— Transcrição da apresentação:

1 Um sistema de Tempo Real para Controle de Quarto
Sistema Tempo Real BedROOM System Um sistema de Tempo Real para Controle de Quarto Kleucio Claudio Paulo Aragão Prof. Eliane Martins

2 Roteiro Introdução Definição Classificação UML – RT UML ROOM
Processo de desenvolvimento Estudo de Caso do Hotel Neste trabalho trataremos da metodologia UML-RT. Primeiro é feita uma introdução do tempo real, apresentando sua definição e possíveis classificações. Depois abordaremos a metodologia UML-RT que é uma combinação do ROOM e UML. E, finalmente, descrevemos o estudo de caso do hotel no qual é proposto um sistema de tempo real para acompanhando dos possíveis estados de um quarto de hotel. Neste seção também apresentamos a metodologia baseada em UML- RT para desenvolvimento deste sistema.

3 Introdução Tipos de Sistemas: Transformacionais Reativos
Sistemas de Tempo Real Sistemas computacionais podem ser classificados em dois tipos: Os sistemas transformacionais são aqueles que calculam valores de saída a partir valores de entrada e depois terminam seus processamentos. Exemplos deste tipo de sistemas são compiladores, programas de engenharia econômica e programas de cálculo numérico [10]. Os sistemas reativos são aqueles que reagem enviando resposta continuamente à estímulos de entrada vindos de seus ambientes. Sistemas de tempo real se encaixam neste conceito de sistemas reativos, com particularidade de estar sujeito à restrição de tempo.

4 Definição Um sistema tempo real é um sistema computacional que deve reagir a estímulos oriundos do seu ambiente em prazos específicos [10]. Sistema tempo real é dependente do resultado e do tempo em que esses resultados são produzidos [1]. Possui requisitos de restrição de tempo [2]. Uma resposta certa em tempo longo pode ser considerada errada [2]. Os sistemas computacionais são utilizados para controlar uma vasta gama de sistemas que vão do uso doméstico ao industrial. Dependendo da aplicação, sua complexidade e exigência podem aumentar. Algumas aplicações interagem diretamente com o hardware. Com o uso de sistemas computacionais proliferando na sociedade contemporânea as aplicações com requisitos de tempo tornam-se cada vez mais comuns. Essas aplicações variam em relação a complexidade e às necessidades de garantia no atendimento às restrições temporais O sistema tempo real mais simples são os controladores inteligentes que estão embutidos nos eletrodomésticos (lavadoras de roupa, videocassetes). Estes sistemas não apresentam uma forte restrição de tempo (sistemas não críticos) No outro extremo estão os sistemas militares de defesa , os sistemas de controle de plantas industriais e controle de tráfego aéreo e rodoviário. Estes softwares controlam a interação com o ambiente emitindo reposta ou tomando decisões enviando comandos ao hardware[10]. Nessa interação o tempo passa a ser um fator importante. O sistema tempo real é dependente do resultado e do tempo em que esses resultados são produzidos[1]. Esses sistemas possuem requisitos de restrição de tempo, ou seja, uma resposta certa em tempo longo pode ser considerada errada[2].

5 Definição Modelo geral de um sistema tempo real[1]: AMBIENTE estímulo
sensores sistema Em um sistema tempo real, as informações são enviadas ao sistema por sensores do ambiente. Com essas informações o sistema determina o estado do ambiente. A partir da informação do estado do ambiente o sistema reage, elaborando respostas e a enviam para os atuadores que de alguma forma controlam hardware que vão interagir com o ambiente[1]. O fato do sistema tempo real reagir aos estímulos do ambiente permite classificá- lo como um sistema reativo. Ao reagir aos estímulos em um prazo específico resulta no atendimento aos requisitos de natureza temporal. Os estímulos podem ser de dois tipos: Periódico: Eles ocorrem em intervalos de tempo previsíveis. Por exemplo o sistema pode examinar o sensor a cada 15 milisegundos e responder de acordo com o valor desta leitura. Aperiódico: Eles ocorrem irregularmente e em geral são assinalados utilizando o mecanismo de interrupção do computador. Um exemplo deste tipo de estímulo seria uma interrupção que indica que uma transferência de entrada e saída foi concluída e que os dados estavam disponíveis no buffer[2]. resposta atuadores

6 Classificação Quanto à Segurança: Sistemas não Crítico de Tempo Real
Sistemas Crítico de Tempo Real Quanto à Implementação Sistemas de Resposta Garantida Sistemas de Melhor Esforço Quanto ao tipo de estímulo Dirigido a evento (estímulos aperiódicos) Dirigido a tempo (estímulos periódicos) Existem diversos tipos de classificação dos sistemas de tempo real. As classificações mais utilizadas são as seguintes: Quanto à segurança: Sistemas não crítico de tempo real: quando as conseqüências de uma falha devido ao tempo é da mesma ordem de grandeza que os benefícios do sistema em operação normal. Ex: sistema de comutação eletrônica, sistema de processamento bancário. Sistemas crítico de tempo real: quando as conseqüências de pelo menos uma falha temporal excedam em muito os benefícios normais do sistema. Ex: Sistemas de controle de tráfego aéreo, sinalização de ferrovias, sistemas de controle de plantas nucleares. Quanto à implementação: Sistemas de resposta garantida: existem recursos suficientes para suportar a carga de pico e o cenário de falhas definidos. Portanto este tipo de implementação é utilizada em sistemas crítico de tempo real. Sistemas de melhor esforço: Ocorre quando a estratégia de alocação dinâmica de recursos se baseia em estudos probabilísticos sobre a carga esperada e os cenários de falhas aceitáveis. Portanto este tipo de implementação é utilizado em sistemas não críticos de tempo real. Quanto ao tipo de estímulo: Sistemas dirigido a evento: São aqueles que cujas respostas são disparadas na ocorrência de algum evento. Ex: Sistema de abertura da porta de um metrô. Neste caso a porta é aberta quando o metrô para na estação. Portanto recebe estímulos aperiódicos. Sistemas dirigido a tempo: São aqueles em que o controle é efetuado em tempo determinado. Ex: Sistema que monitora a temperatura do ambiente através da verificação em intervalos de tempo fixo. Portanto recebe estímulos periódicos.

7 Aplicações Aernonáutica – controle de navegação
Telecomunicações – envio de dados Automóveis – freios ABS Equipamentos médicos – monitoramento de pacientes Controle de elevadores – fechamento de portas Hotelaria – controle dos quartos Muitas das aplicações do sistemas de tempo real estão ligadas a circunstâncias perigosas: alta tensão, produtos tóxicos, controle de pacientes[2]. Freios ABS, monitoramento de pacientes em hospitais, são outros exemplos de sitemas criticos, pois caso não houver resposta do sistema no intervalo de tempo correto, isto implicará em erro, um exemplo de sistema tempo real não- crítico é o controle da uma porta de elevador, onde caso não for fechada no tempo pré-determinada essa operação se degradará ao longo do tempo[1]. Neste trabalho aplicaremos a metodologia UML-RT ao caso de um Hotel, onde o sistema de tempo real será aplicado ao gerenciamento dos quartos tais como reserva, alteração, manutenção, e fechamento de estadia. Alguns equipamentos de hardware serão necessários para implantação, por exemplo máquinas de alimentos automáticas, leitores de cartões magnéticos, e uma infraestrutura de rede para conectar cada quarto ao sistema de controle.

8 Ferramentas Case ROSE_RT – Rose_RT é uma ferramenta que trabalha com a UML -RT. Outras ferramentas: AxiomSys Real-Time Maude Artisan Real-Time Object-Time Developer Rose_rt – Ferramenta case que utiliza o UML-RT para construção de modelos e geração de códigos. AxiomSys – é uma ferramenta case comprovadamente eficiente que combina uma estrutura de análise(Yourdon –DeMarco) integrada a Hatley-Pirbhai estendida para sistemas tempo-real e conceitos de modelagem de arquitetura[18]. Pode-se construir uma análise de estrutura detalhada do sistema, permite desenvolver o projeto da arquitetura do sistema para a implementação. É uma software comercial, mas possui uma versão teste gratuita limitada apenas pelo tamanho do modelo. Real-Time Maude – é uma linguagem que permite uma especificação formal e análise de sistemas tempo-real e sistemas híbridos. Real-Time Maude permite especificar os objetos do sistema real-time, mas não implementa o sistema tempo real[19]. ARTiSAN – É uma ferramenta multiusuário, que permite implementar e modelar sistemas baseados em componentes é auxiliado pela UML 2.0[20]. Object-Time Developer – é uma ferramenta parecida com o Rose_RE e que implementa os construtores do UML-RT e capacita os desenvolvedores a gerar códigos diretamente de seus modelos visuais.

9 UML - RT UML-RT (UML for Real Time) fornece um modelo para desenvolvimento de aplicações de tempo real através da combinação do UML com o ROOM UML-RT ROOM + UML UML - RT A Rational Software Corporation (atualmente incorporada pela IBM) fez uma parceria com a ObjectTime Ltd. Para desenvolver UML-RT (UML for Real Time). UML- RT usa os mecanismos de extensão do UML para incorporar conceitos de ROOM do ObjectTime [8]. UML-RT é extremamente poderoso para modelar a natureza reativa dos sistemas de tempo real. Como uma ferramenta de sucesso, UML-RT fornece um modelo para análise complexa de sistemas de tempo real dirigidos à eventos simulando a forma como os sistemas de tempo real realmente trabalham e, por último, ajuda a construir e gerar código para aplicações críticas de tempo real. UML ROOM

10 UML UML – linguagem utilizada para desenvolvimento de sistemas orientado a objeto Tipos de Diagramas: Visão do Usuário (diag. de caso de uso) Visão Estrutural (diag. de classes) Visão Comportamental (diag. de estado, sequência, atividade, etc.) Visão de Implementação (diag. de implementação) Visão de Distribuição (diag. de distribuição) O UML (Unified Modeling Language) é uma linguagem utilizada para desenvolvimento de sistemas orientado a objetos e atualmente vem ganhando popularidade para desenvolvimento de sistemas em tempo real[8]. Ele adapta e estende os trabalhos publicados por Grady Booch, Jim Rambaugh e Ivar Jacobson e contêm melhorias e sugestões de dezenas de pessoas [6]. É possível estender o UML para se adaptar a vários tipos de aplicações. Isto pode ser feito através do uso de estereótipos (stereotypes), valores etiquetados (tagged values) e restrições (constraints) [6]. Portanto o uso destas extensões se tornam úteis para desenvolvimento de aplicações em tempo real. O UML disponibiliza nove diagramas para descrever diferentes visões do sistema [6] : Visão do Usuário Diagrama de Caso de Uso – Mostra a interação entre o usuário e o sistema Visão Estrutural Diagrama de Classe – Descreve a estrutura estática do sistema. É composto de classes e associações. Visão Comportamental Diagramas de Estado – Diagrama que captura o comportamento de um objeto mostrando como este se reage a eventos Diagrama de Atividades – É um tipo de diagrama de estado (statechart diagram) onde os estados são atividades e as transições ocorrem quando uma atividade se torna disponível Diagrama de Seqüência – Diagrama que descreve um cenário definido em um caso de uso. Portanto apresenta o comportamento dinâmico do sistema através da troca de mensagens entre os objetos de acordo com sua seqüência de execução Diagrama de Colaboração – Diagrama que mostra a interação entre os objetos. Visão de Implementação Diagrama de Componentes – Mostra a estrutura do código fonte Visão de Distribuição Diagrama de Distribuição – Mostra como o sistema é executado de acordo com sua instalação.

11 ROOM ROOM (Real-time Object Oriented Modeling) -
Elementos de Construção: Protocolos Capsulas Portas Conectores ROOM (Real Time Object-Oriented Modeling) é uma linguagem de modelagem com o objetivo de especificar, visualizar, documentar e automatizar a construção de sistemas de tempo real. ROOM usa conceitos que captura padrões estruturais de comunicação entre componentes de software para suporte arquitetural de padrões de projeto. Os modelos de ROOM são composto de atores que se comunicam entre si enviando mensagens via protocolos [8]. O ROOM têm sido bastante aplicado na indústria de telecomunicações para desenvolver softwares embarcados [7]. O ROOM utiliza basicamente dois tipos de diagramas: Diagrama de estruturas e Diagrama de Estados. Na representação do diagrama de estruturas o ROOM utiliza os seguintes elementos de construção: cápsulas, portas e conectores Visão Estrutural: Diagrama de Estruturas Diagrama de Estados

12 ROOM Protocolos – Define um contrato entre os participantes da comunicação. Os Protocolos são elementos que definem um contrato entre os participantes da comunicação. Eles são usualmente associado com os conectores e a implementação de um protocolo é realizado por uma porta.

13 ROOM Diagrama de Classe com as capsulas e portas
Esta figura representa um diagrama de classe com as portas e cápsulas. Como se pode observar, as portas são atributos de uma cápsula e implementa um protocolo

14 ROOM Diagrama de Estruturas: Portas Cápsulas Conectores a: CapsuleA
X2: ProtB X4: ProtA b: CapsuleB {plug-in} a: CapsuleA c: CapsuleC X1: ProtA Y2: ProtB Y1: ProtC Z2: ProtC X3: ProtB Z1: ProtB Portas Cápsulas- São os elementos fundamentais no ROOM. Estes são a especialização de classes e são agrupadas de acordo com características comuns. As cápsulas são diferentes das classes pelos seus mecanismos de comunicação. Cada cápsula tem pelo menos uma porta através da qual se comunica com outros objetos e as portas são os únicos meios de interação com o mundo externo. A cápsula pode conter sub-capsúlas, como mostrado no diagrama de estruturas ilustrado acima. A cápsula pode ter no máximo uma máquina de estados que está em serviço para enviar e receber sinais através das portas, e controlando certos elementos na estrutura interna. Normalmente, portas, conectores e sub-cápsulas são criadas e destruídas ao mesmo tempo que a capsula mãe. Contudo, algumas sub-cápsulas podem ser criadas e destroídas dinâmicamente pela máquina de estado da cápsula. A cápsula pode assumir o papel de “plug-in”, ou seja, podem se conectar dinamicamente a outras cápsulas Portas – São objetos que atuam como interface na fronteira de uma cápsula (portanto são objetos dentro de uma cápsula). Há dois tipos de portas: Portas Relay – São portas conectadas à sub-cápsulas para simplesmente deixar passar todos os sinais. Portas Finais (end ports) – São portas conectadas á máquina de estados da cápsula como elementos finais de origem e destino dos sinais enviados pelas cápsulas. Cada porta de uma cápsula assume um papel particular na colaboração entre a cápsula e seu objeto de interação. Para definir o fluxo de sinais permitido entre duas capsulas que se interagem, é introduzido o conceito de protocolo. Normalmente cada porta é associada com um protocolo em uma conexão. Conectores – São canais de informação que suporta sinais baseados em protocolos. Um conector pode somente conectar portas que representam papéis complementares no protocolo associado com o conector. A diferença entre um conector e o protocolo é que um protocolo é uma especificação abstrata dos comportamentos desejados enquanto um conector é um objeto físico que transmite os sinais entre as portas Cápsulas Conectores

15 Processo de Desenvolvimento
Utiliza um processo de desenvolvimento iterativo baseada nas seguintes etapas de desenvolvimento: Requisitos e Análise Projeto Implementação Testes A metodologia utilizanda pelo UML-RT é um processo iterativo composto de diversos ciclos de desenvolvimento. O número de ciclos depende da característica do software, bem como da sua complexidade. A metodologia engloba as seguintes etapas de desenvolvimento: Especificação de Requisitos: Esta fase se caracteriza pela definição das funcionalidades do sistema, sem detalhes de implementação do mesmo. Também se decide quais funcionalidades serão desenvolvidas no ciclo corrente. Análise: Permite modelar o software de forma conceitual sem se preocupar com detalhes de implementação. Projeto: Nesta fase se deriva as classes que representam uma solução de implementação do sistema. É comum a utilização de diversos padrões de projeto para a solução do problema. Implementação: Se caracteriza pela escrita do codigo fonte a partir das classes especificadas na fase de projeto. Teste – verificação das funcionalidades especificadas

16 Requisitos e Análise Criação dos Casos de Uso
Criação dos Diagramas de Caso de Uso Construção do Modelo Conceitual Representação dos conceitos Associação entre os conceitos Atributos de conceitos Comportamento do Sistema: Diagramas de Seqüência A fase de requisito e análise engloba as seguintes atividades: Criação dos Casos de Uso – O caso de Uso são textos descritivos em linguagem natural que especifica a interação entre os atores e o sistema Criação dos Diagramas de Caso de Uso – Diagrama que representa graficamente os atores e seus casos de uso Construção do Modelo Conceitual – Cria um diagrama de classes (conceitos) representando as classes referentes ao mundo real. Algumas destas classes (conceitos) serão descartadas na fase de projeto. E ainda outras classes serão adicionadas na fase de projeto para representação da solução de implementação Representação dos conceitos – são as varias classes no modelo conceitual Associação entre os conceitos – interação entre os conceitos Atributos de conceitos – propriedades dos conceitos Comportamento do Sistema: Diagramas de Seqüência – cenário que indica a interação entre os vários conceitos que se origina com a solicitação de uma mensagem enviada pelo ator. São criadas a partir dos casos de uso e dos diagramas de classe

17 Estudo de Caso Na especificação de requisitos se optou por desenvolver o sistema para controle de quarto de acordo com as seguintes funcionalidades Reservar quarto Ocupar quarto Indicar quarto em uso Indicar quarto livre Solicitar manutencao do quarto Indicar quarto em manutencao Indicar termino da manutencao Desocupar quarto Para o desenvolimento do estudo de caso de uso utilizamos o Rose_RT. A descrição completa dos casos de uso foram disponibilizadas junto Com esta apresentação em formato html gerado pela ferramenta Rose_RT. No primeiro ciclo de desenvolvimento se optou por implementar os seguintes casos de uso: Reservar, ocupar, indicar quarto em uso e indicar quarto livre

18 Conclusões UML-RT é baseado em UML, hoje um padrão para desenvolvimento em sistemas orientado a objeto. UML-RT é extremamente poderoso na modelagem dea natureza reativa dos sistemas de tempo real [8] UML-RT fornece modelos para geração completa de código [8] UML-RT não é formalmente bem definido [14]. UML-RT é mais adaptadas em projeto e implementação [14]. UML-RT não disponibiliza uma análise para verificação das restrições de tempo [7, 8] UML-RT é baseado em UML, hoje um padrão para desenvolvimento em sistemas orientado a objeto. UML-RT é extremamente poderoso na modelagem de natureza reativa dos sistemas de tempo real [8] UML-RT não é formalmente bem definido. Isto é uma limitação relevante do UML-RT pois grande parte das aplicações de tempo real são críticas. Portanto a verificação de propriedades (segurança, utilidade, etc..), simulação de sistemas e geração de casos de testes são tarefas difíceis quando as especificações são escritas em notações semi-formais como a UML ou UML-RT. [14] UML-RT apresenta uma notação eficiente para projeto e implementação de sistemas, mas não é muito bem adaptado para representação requisitos ou especificações. Por exemplo, quando a modelagem do ambiente na qual um sistema de tempo real deve trabalhar, é freqüentemente necessário representar comportamentos não determinísticos ou eventos simultâneos. Estes fenômenos não são suportados pelo UML-RT. [14] UML-RT não suporta análise de escalonamento de tempo real e não gera uma implementação que atende as restrições de tempo. Os principais domínios de aplicações da UML-RT são sistemas de telecomunicações, que são geralmente sistemas não crítico de tempo real. Talvez, por este motivo, os projetistas da ferramenta CASE do Rose_RT não tem dado muita ênfase para aplicações de tempo reais com forte restrição ao tempo [7].

19 Bibliografia [1] Ian Sommerville, “Engenharia de Software”
[2]Apresentação. [3]B. Selic, J. Rumbaugh. “Using UML for Modeling Complex Real -Time Systems”, 1998. [4]B. Selic. “An efficient object oriented variation of statecharts formalism for distributed real time systems”, CHDL Abril-1993. [5] Investigating of Models for Real-Time Systems: AIDA through UML and ROOM. [6] Unified Modeling Language for Real-Time System Design.

20 Bibliografia [7] Z. Gu and K. G. Shin. Synthesis of Real Time Implementation from UML-RT Models [8] W. He and S. Goddard. Capturing an Application´s Temporal Properties with UML for Real Time. [9] P. Macedo. Modelação de Sistemas de Tempo Real em UML. Tempo, Análise da Escalonabilidade e do Desempenho [10] Introdução sobre o Tempo Real

21 Bibliografia [11] M. Moller, E. Olderog, H. Rasch and H. Webrheim. Linking CSP-OZ with UML and Java: A Case Study [12] A. Sampaio, A. Mota and R. Ramos. Class and Refinement in UML for Real-Time. Eletronic Notes in Theoretical Computer Science, Vol 95, 23:51, 2004 [13] B. Rumpe, M. Schoenmakers, A. Radermacher, A. Schurr. UML + ROOM as a Standard ADL? [14] V. Bianco, L. Lavazza, M. Mauri and G. Occorso. Towards UML-based formal specifications of componentbased real-time software

22 Bibliografia [15] Rational Rose Corporation. Model Examples – Rational Rose RealTime. Acessado em novembro/2004 [16] Rational Rose Corporation. Modeling Language Guide – Rational Rose RealTime. Acessado em novembro/2004 [17] Rational Rose Corporation. Tutorials – Rational Rose RealTime. Acessado em novembro/2004

23 Bibliografia [18] AxiomSys System Analysis CASE Tool – acessado em 20/11/2004. [19] Real-Time Maude 2.0 Manual - acessado em 20/11/2004. [20] Artisan Real-time Software Tools – Overview, acessado em 20/11/2004.