UNIVERSIDADE CATÓLICA DE PELOTAS ESCOLA DE INFORMÁTICA CURSO DE ANÁLISE DE SISTEMAS E CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE CATÓLICA DE PELOTAS ESCOLA DE INFORMÁTICA CURSO DE ANÁLISE DE SISTEMAS E CIÊNCIA DA COMPUTAÇÃO Automação Hospitalar aplicando a Computação Móvel com a utilização do Holoparadigma por Eduardo da Silva Möller Sandra Moura Kunde Nunes Trabalho de conclusão submetido como requisito parcial para a obtenção do grau de Bacharel em Análise de Sistemas e Ciência da Computação Prof. Dr.Jorge Luis Victória Barbosa Orientador Prof. Guilherme Tomaschewski Netto Co-Orientador Pelotas, Dezembro de 2002

2 UNIVERSIDADE CATÓLICA DE PELOTAS Reitor: Alencar de Mello Proença Pró-Reitor Administrativo: Carlos Ricardo Gass Sinnotti Pró-Reitor de Graduação: Dr. Gilberto de Lima Garcias Diretora do Instituto de Informática: Regina Trilho Otero Xavier Bibliotecária-Chefe: Cristiane de Freitas Chim

3 Agradecimentos A Deus por nos mostrar o caminho para a realização dos nossos sonhos, e por ter nos dado força ao longo de nossa caminhada. Aos nossos pais e as nossas famílias, pelo exemplo de amor, união e dignidade. Aos nossos companheiros pelo apoio, incentivo, compreensão e paciência. Aos nossos amigos pelo espírito solidário e incentivo nos momentos difíceis. Aos nossos professores e aos que nos orientaram neste trabalho Prof. Guilherme Tomaschewski Netto, e em especial ao Dr. Prof. Jorge Luiz Victória Barbosa por ter acreditado no nosso trabalho, e ter sido acima de tudo amigo, guia e companheiro nesta caminhada. Ao Prof. Luiz Antônio Moro Palazzo, pela amizade e o exemplo de dedicação e dignidade pessoal. Aos colaboradores da Fundação de Apoio Universitário e a todas as pessoas que de forma direta ou indireta, contribuíram para a realização deste trabalho. E a nós por todo o trabalho de dedicação, esforço e aprimoramento. Que esta marca permaneça sempre um exemplo para tudo aquilo que ainda viveremos, lutaremos e com certeza venceremos.

4 2 SUMÁRIO Lista de Figuras Lista de Abreviaturas Resumo Abstract Introdução Tema Motivação Contexto e Histórico Objetivos Estrutura do Texto Holoparadigma Gênese do Holo Holossemântica Tipos de Entes Holoclonagem Hololinguagem Holoplataforma HML Mobilidade Conceitos Mecanismos Tecnologia e Equipamentos para Suporte à Mobilidade Mobilidade no Holoparadigma Mobilidade Hospitalar Automação Hospitalar HoloTree Extensão Holo-Parte Diagrama de Entes Dinâmicos Diagrama de Mobilidade Individual Diagrama de Mobilidade Coletiva Diagrama de Visão do Sistema Diagrama de Interação Implementação Introdução Simulação do ente móvel Médico Simulação do ente móvel Enfermeiro Simulação do ente móvel Paciente Simulação do ente móvel Assistente Social Simulação do ente móvel Nutricionista Simulação do ente móvel Psicólogo Simulação do ente móvel Farmacêutico / Químico

5 3 5.9 Simulação do ente móvel Técnico de Manutenção Conclusão Anexo I Diagramas de Mobilidade Individual Anexo II Diagramas de Mobilidade Coletiva Anexo III Diagramas de Visão do Sistema Anexo IV Diagramas de Interação Bibliografia

6 4 LISTA DE FIGURAS Figura Gênese do Holoparadigma Figura Gap Semântico Figura Holosemântica Aplicada a Modelagem Figura Característica dos Entes Figura Ente Elementar, Composto e Composição de Três Níveis Figura Descrição de um Ente Figura Holoplataforma Versão Figura Notação de Ente na HML Figura Notação de Ente Dinâmico Figura Representação da Afirmação na HML Figura Representação de Pergunta na HML Figura Exemplo de Clonagem Estática Figura Representação da Mobilidade Lógica Adaptativa Figura Representação da Mobilidade Lógica Não Bloqueante Figura Representação da Mobilidade Lógica Bloqueante Figura Representação do Elemento de Modelagem Diag. de Interação 32 Figura Diagrama de Interação Figura Diagrama de Interação Figura Diagrama de Mobilidade Individual Figura Diagrama de Mobilidade Coletiva Figura Visão Dinâmica do Sistema Figura Antena Parabólica Figura Antena Parabólica Figura Antena Direcional Figura Antena Omnidirecional Figura Comunicação de Dados Sem Fio Figura Sistema de Antenas Interligadas Via Ondas de Rádio Figura Coletores de Dados Figura Mobilidade Lógica no Holoparadigma Figura Mobilidade Física no Holoparadigma Figura Ente Distribuído Figura Organograma da FAU Figura Àrvore de Entes (Holotree) Figura Equipamentos Instalados Figura Notação da Estrutura Holo-Parte Figura Estrutura Holo-Parte Recipiente-Conteúdos Figura Estrutura Holo-Parte Conjunto Membros Figura Estrutura Holo-Parte Montagem Partes Figura Diagrama de Entes Estáticos com a Extensão Figura Diagrama de Entes Dinâmicos Figura Diagrama de Mobilidade Individual Figura Diagrama de Mobilidade Coletiva Figura Diagrama de Visão do Sistema Tec. de Manipulação Figura Diagrama de Interações Figura Holoprogramas Figura Resultado da Movimentação do Ente Móvel Médico... 77

7 Figura Passos da movimentação do ente Médico Figura Resultado da simulação do ente móvel Enfermeiro Figura Passos da movimentação do ente Enfermeiro Figura Resultado da simulação do ente móvel Paciente Figura Passos da movimentação do ente Paciente Figura Resultado da simulação do ente móvel Assistente Social Figura Passos da movimentação do ente Assistente Social Figura Resultado da simulação do ente móvel Nutricionista Figura Passos da movimentação do ente Nutricionista Figura Resultado da simulação do ente móvel Psicólogo Figura Passos da movimentação do ente Psicólogo Figura Resultado da simulação do ente móvel Farmacêutico Figura Passos da movimentação do ente Farmacêutico Figura Resultado da simulação do ente móvel Técnico Figura Passos da movimentação do ente Técnico

8 6 LISTA DE ABREVIATURAS AJ - Assessoria Jurídica Cirur - Cirurgia CLEI - Cláusula Lógica com Extensão não Imperativa CM - Clínica Médica CPD - Centro de Processamento de Dados Dholo - Distributed Holo DI - Identificador de Destino DP - Departamento de Pessoal DSSS - Direct Sequence Spread Spectrum EIC - Estrutura de Configuração de Invocação Elet - Eletroeletrônica Endos - Endoscopia Enfer - Enfermagem Far - Farmacêutico FAU - Fundação de Apoio Universitário Fisiat - Fisiatria HML - Holo Modeling Language Holo - Holoparadigma HoloEnv - Holo Environment Holo-Tree - Árvore de níveis LA - Logic Action LAB - Laboratório LAN - Local Area Network MA - Multiparadigm Action Man - Manipulação MIA - Modular Imperative Action MLA - Modular Logic Action MT - Medicina do Trabalho OMG - Object Management Group PC - Psicologia Clínica PC - Psicóloga PT - Psicología do Trabalho Radiol - Radiologia RH - Recursos Humanos RP - Relações Públicas RST - Recrutamento, Seleção e Treinamento SEP - Serviço de Estatística e Projetos SPP - Serviço de Prontuário de Pacientes TM - Técnico de Manutenção UFRGS - Universidade Federal do Rio Grande do Sul UML - Unified Modeling Language UTI - Unidade de Tratamento Intensivo WAN - Wide Area Network

9 7 RESUMO Este trabalho propõe o Estudo da Automação Hospitalar aplicando Computação Móvel com a utilização do Holoparadigma, modelo multiparadigma orientado ao desenvolvimento de software distribuído, obter a criação de uma extensão do Holo, descobrindo novas aplicações e novos conceitos. Utilizando para modelagem de dados a HML(Holo Modeling Language), uma linguagem de modelagem para representar visualmente os conceitos propostos pelo Holoparadigma e a Hololinguagem para a programação, que integra paradigmas em lógica, imperativo e orientado a objetos, suportando assim os conceitos da computação móvel. Este texto apresenta conceitos de mobilidade e a capacidade das entidades computacionais deslocar-se de um ambiente para outro, através de um sistema distribuído na automação hospital, uma visão geral de HML e Holoparadigma. Palavras-Chave: Mobilidade, Holoparadigma, Agentes Móveis, Ente

10 8 ABSTRACT This work proposes the study of Hospital Automation applying Movable Computation with the use of Holoparadigm, a multiparadigm model guided to the development of distributed software, obtaining the creation of an extension of Holo, discovering new applications and new concepts. Using for modelling of data HML (Holo Modelling Language), a modelling language to represent the concepts visually proposed by Holoparadigm and Hololanguage for the programming that integrates paradigms in logic, imperative and guided to objects, though supporting the concepts of the movable computation. This text presents mobility concepts and the capacity of the computing entities to move from an atmosphere to another through a system distributed in the hospital automation, ageneral vision os HML and Holoparadigm. keywords: Mobility, Holoparadigm, Movable Agents, Being

11 9 1. Introdução Este capítulo contém uma introdução sobre o trabalho proposto. As próximas seções apresentam o tema pesquisado, a motivação, o contexto e o histórico do trabalho, os objetivos e a estrutura do texto. 1.1 Tema Este texto apresenta a proposta da criação de uma extensão do Holoparadigma [BAR 99], BAR[2000], [BAR 2000a], [BAR 2001], [BAR 2001a], [BAR 2001b], utilizando-a para o sistema Hospital do Hospital Escola Universitário de Pelotas (FAU), como também a utilização da HML( Holo Modeling Language)[LAE 2002], para a modelagem deste sistema e a Hololinguagem[BAR 2002] para sua implementação. Todos estes conceitos aplicados à computação móvel, define como a habilidade de mover-se independentemente de um dispositivo para outro em um sistema distribuído. 1.2 Motivação A evolução das novas tecnologias está provocando mudanças significativas no relacionamento entre as pessoas e, conseqüentemente nas suas relações com o ambiente de trabalho. O conhecimento é móvel por natureza e dispõe de meios para exercer sua função. A sociedade atual está evoluindo para a mobilidade. Acredita-se que este trabalho possa contribuir para a utilização de novos conceitos na área da automação hospitalar ligada à computação móvel e que através da qual gerou um interesse muito grande pela exploração do Holoparadigma (software multiparadigma distribuído), por ser algo inovador e com grandes possibilidades de superar os nossos objetivos. Unir a mobilidade computacional com o Holoparadigma é algo que representa a realidade de um futuro muito próximo.

12 10 Acreditamos em novas tecnologias e na busca de superações. A cada dia realizam-se novas conquistas e descobertas dentro da informática, e uma busca incessante do novo. A mobilidade irá proporcional ao hospital racionalização de procedimentos facilitando os profissionais do corpo clínico o acesso rápido às informações. Acredita-se em uma forte tendência em se desenvolver aplicações para ambientes de computação móvel, envolvendo pesquisa, modelagem e programação. De certa forma as plataformas computacionais vêm migrando de sua natureza centralizada para uma distribuída. Os sistemas distribuídos tem recebido cada vez mais atenção tornando-se a base para o desenvolvimento de sistemas computacionais. A concepção e desenvolvimento de software baseado na comunicação entre processos tem vindo a aumentar continuamente acompanhando o florescimento e crescimento das redes de comunicação e da Internet. Aplicações como: protocolos, sistemas cliente-servidor, sistemas distribuídos, interacção entre robots, transacções bancárias e agentes inteligentes que baseiam o seu funcionamento numa comunicação complexa e recíproca entre vários processos. Paralelamente a estes desenvolvimentos surge um conceito geral - mobilidade - que consiste na capacidade de processos, objetos ou computações mudarem a sua localização consoante a evolução do sistema. A capacidade de alterar dinamicamente a topologia de uma rede será uma das capacidades mais interessantes do ponto de vista teórico e prático pela aplicabilidade imediata a resolução de problemas. Simultaneamente a esta característica, a introdução de concorrência entre processos permite melhorar os tempos de resposta, uma vez que "períodos mortos" ocupados com operações de Input/Output passarão a ser ocupados com o processamento de outras threads de execução. Contudo, estas características são precisamente as grandes responsáveis por um aumento da complexidade nos programas

13 11 em sistemas distribuídos e pela dificuldade em garantir que o comportamento do sistema corresponda à sua especificação. A Computação Móvel representa um novo paradigma computacional, ampliando o conceito de computação distribuída. Visa disponibilizar informações em qualquer lugar e a qualquer tempo, caracterizando também conceitos de computação nômade. Neste contexto, os serviços podem ser classificados em diversas formas, uma delas por grandes áreas : comunicação pessoal, celular, móvel, redes locais e comunicação via satélite. Em sua grande maioria, os sistemas de comunicação sem fio se baseiam na comunicação via rádio e na alocação de frequências. Para suportar a mobilidade de forma transparente para o usuário, a noção de ambiente computacional deve estar presente, ele será o elemento principal no suporte à mobilidade das entidades envolvidas. O Holoparadigma possui uma semântica simples e distribuída. Desta forma, estimula-se a exploração da distribuição implícita desde a modelagem dos sistemas computacionais, contemplando as vantagens introduzidas pela arquitetura de software e pelos modelos multiparadigma. 1.3 Contexto e Histórico O Holo foi desenvolvido por três projetos: Opera [OPE 2001], onde teve sua origem, Appelo[APE 2001] e Holoparadigma [Hol 2001]. O projeto Opera iniciou suas atividades no laboratório de Génie Informatique (universidade de Joseph Fournier em Grenoble /França). Atualmente, encontra-se em fase de aperfeiçoamento na universidade Federal do Rio Grande do Sul- UFRGS, uma ramificação deste projeto. Estudos e testes já estão sendo feito com relação a sua utilização, alguns usuários já encontram-se utilizando a Hololinguagem. Atualmente foi elaborado um suporte para a modelagem e desenvolvimento de programas em Holo denominado HML(Holo Modeling Language)[LAE 2002], que permitirá ao usuário modelar sistemas em Holo facilitando a documentação e compreensão dos mesmos, futuramente será desenvolvida uma ferramenta denominada HoloCase que permitirá ao usuário

14 12 representar graficamente na tela a utilização da HML, permitindo a definição das características de cada um dos entes modelados, esta ferramenta será integrada ao ambiente de desenvolvimento HoloEnv e permitirá ao usuário a criação de soluções na Hololinguagem usando HML(Holo Modeling Language). 1.4 Objetivos Objetivo Geral O presente projeto tem por objetivo realizar estudos sobre Automação Hospital aplicando a computação móvel, utilizando um modelo multiparadigma orientado ao desenvolvimento de software distribuído denominado Holoparadigma. Assim como também a possibilidade de uma nova extensão do Holoparadigma e suas aplicabilidades dentro da Automação Hospital, através da realização de novas pesquisas e tendo como base os modelos já existentes. Por conseqüência usar este estudo para propor o desenvolvimento de um sistema hospitalar utilizando o Holoparadigma, baseado também nos conceitos da extensão Objetivos Específicos Este trabalho tem como objetivos específicos. Estudar modelos existentes aplicados à computação móvel; Realizar pesquisas em busca de novas atuações da computação móvel; Realizar o estudo do Holoparadigma; Utilizar a pesquisa para a possibilidade do desenvolvimento de uma extensão do Holoparadigma; Realizar estudo de caso para uma automação hospitalar usando mobilidade e holoparadigma baseados na nova extensão do Holo; Modelar este estudo de caso; Realizar testes utilizando a Hololinguagem.

15 Estrutura do Texto O texto está organizado em seis capítulos e quatro anexos. Os anexos constituem uma extensão do capítulo quatro, contendo toda a modelagem proposta para a execução deste trabalho. O segundo capítulo apresenta o estudo do Holoparadigma, que é uma nova proposta para o desenvolvimento de software, sua aplicação, sua semântica, a aplicação em sistemas distribuídos, e uma linguagem de modelagem projetada para suporte ao Holoparadigma, a HML( Holo Modeling Language), que tem por objetivo apresentar as representações criadas para os elementos definidos pelo Holo. Este estudo tem por objetivo demonstrar sua aplicabilidade que através da qual, dará suporte a este trabalho podendo representar toda a mobilidade da FAU, por intermédio de seus conceitos e sua programação. O terceiro capítulo apresenta os conceitos de mobilidade, os mecanismos, as tecnologias e equipamentos de suporte à mobilidade, ambientes que permitem a exploração da mobilidade, e a mobilidade representada através do Holoparadigma. Este capítulo tem como principal objetivo, mostrar toda a tecnologia utilizada através de equipamentos sem fios, utilizando toda a tecnologia de ponta para total informatização de um sistema hospitalar. O quarto capítulo representa a essência deste trabalho, ele apresenta toda a especificação do sistema utilizado para a Automação Hospitalar, como também os equipamentos instalados, o organograma da FAU, e também toda a especificação que gerou uma extensão do HML (Holo Modeling Language), aplicada a FAU e incorporada ao diagrama de entes estáticos representando toda a estrutura, apresenta a mobilidade no hospital, o diagrama de entes dinâmicos representando a execução de entes dentro do sistema hospitalar e o diagrama de interação representando a interação dos entes que fazem parte do setor de Recursos Humanos da FAU. O quinto capítulo apresenta a implementação em alguns módulos do sistema, contém os testes gerados utilizando a Hololinguagem, linguagem de programação suportada pelo Holoparadigma. O sexto capítulo contém uma conclusão geral, e nossas considerações contendo também as principais contribuições para trabalhos futuros. Visto que este trabalho é o

16 14 pioneiro para a automação de um sistema que utiliza uma nova proposta de um software multiparadigma, introduzindo uma modelagem até então recém criada e ainda não utilizada por outros trabalhos, integrados aos conceitos de computação móvel. O primeiro anexo contém a representação gráfica da modelagem do diagrama de mobilidade individual referenciado no capítulo quatro, que descreve toda a mobilidade dos entes móveis. O segundo anexo contém a representação gráfica da modelagem do diagrama de mobilidade coletiva referente ao capítulo quatro, representando os entes dentro do sistema de forma concorrente. O terceiro anexo contém a representação gráfica da modelagem do diagrama de visão do sistema referenciado no capítulo quatro, onde conta os aspectos estáticos e dinâmicos do sistema. O quarto anexo contém a representação gráfica do diagrama de interação, referenciado no capítulo quatro, onde um ente tem a capacidade de interagir com outros entes. Neste anexo representa-se a interação de todos os entes do sistema.

17 15 2. Holoparadigma É um modelo multiparadigma que possui uma semântica simples e distribuída. Através dessa semântica, o modelo estimula a exploração automática da distribuição (distribuição implícita). O estímulo à distribuição implícita é seu principal objetivo. Os princípios gerais do modelo foram publicados em [BAR 99a], [BAR 2000a], [BAR 2000e] e [BAR 2001]. Além disso, os aspectos específicos relacionados com paralelismo e distribuição foram analisados em [BAR 2000c], [BAR 2001b]. 2.1 Gênese do Holoparadigma É uma nova proposta para o desenvolvimento de software multiparadigma distribuído. Ele busca integrar os esforços de vários campos estudados pela ciência da computação. A criação do Holoparadigma pode ser percebida em três níveis de temas de pesquisa (Figura 2.1): básico, intermediário e final. Temas Básicos Paralelismo Implícito Sistemas Distribuídos Multiparadig ma Arquitetura de Software Temas Intermediários Distribuição Implícita Novos Paradigmas Tema Final Holoparadigma Figura 2.1-Gênese do holoparadigma

18 16 A unificação dos seguintes temas de pesquisa conduz à criação do Holoparadigma: Paralelismo Implícito: Propõe a detecção automática do paralelismo e sua exploração através dos mecanismos inseridos no software básico dos sistemas computacionais; Sistemas Distribuídos: Têm recebido cada vez mais dedicação tanto dos centros de pesquisa quanto das empresas. Neste contexto merecem destaque os seguintes tópicos: uso de redes de computadores como arquiteturas paralelas, mobilidade de código e dados e tratamento da heterogeneidade de hardware em redes; Distribuição Implícita: No contexto de sistemas distribuídos, torna-se interessante à integração dos temas paralelismo implícito e sistemas distribuídos em um único tópico de pesquisa. Este tópico busca a exploração automática da distribuição através de mecanismos inseridos no software básico; Multiparadigma: Propõe a criação de modelos de desenvolvimento de software através da integração de paradigmas básicos. Arquitetura de Software: Este tema de pesquisa dedica-se à descrição de componentes, a interações entre eles e os padrões que guiam sua composição; Novos paradigmas de software: Une em uma única abordagem de pesquisa os temas multiparadigma e arquitetura de software. Um paradigma orienta todo o desenvolvimento de sistemas, desde a modelagem até a implementação. 2.2 Holosemântica O Holoparadigma propõe, através de tratamento automático, retirar do desenvolvedor a preocupação com paralelismo e distribuição, permitindo ao mesmo voltar a atenção para criação de algoritmos que satisfaçam suas reais necessidades e de seus clientes.

19 17 Um paradigma suporta a modelagem de sistemas computacionais. Com esse intuito, estabelece um conjunto de abstrações que serão utilizadas para criação dos modelos. A eficiência do paradigma está relacionada com a distância entre o significado dessas abstrações e os conceitos existentes no domínio modelado. No âmbito da engenharia de software, essa distância é denominada gap semântico (Figura 2.2) Um pequeno gap semântico significa que as abstrações são adequadas. A semântica está relacionada com o significado. No caso dos paradigmas, a semântica estabelece o significado de suas abstrações. Por exemplo, o paradigma orientado a objetos possui como principal abstração o objeto. No âmbito deste paradigma, objeto é a unidade de modelagem e significa qualquer realidade que possa ser organizada em uma unidade que encapsule atributos e métodos. REALIDADE Domínio Gap Semântico Modelagem Modelo Computacional Figura 2.2-Gap semântico A semântica do Holo é denominada Holosemântica. A Holosemântica estabelece a utilização de duas unidades de modelagem: Unidade de existência ENTE: a existência é modelada através de um ente; Unidade de informação SÍMBOLO: a informação é modelada através de símbolos.

20 18 A modelagem em Holo utiliza somente essas unidades. Sendo assim, a criação de modelos computacionais é simplificada. A figura 2.3 mostra a aplicação da Holosemântica. REALIDADE Domínio Fontes de Distribuição Ente: Símbolo: Unidade de Existência gap Unidade de informação semântico Holosemântica Modelo Computacional Distribuição Implícita Exploração automática da distribuição Arquitetura Distribuída Figura 2.3-Holosemântica aplicada à modelagem O ente é a principal abstração do Holoparadigma. Toda existência é um ente, desde a mais simples até a mais complexa. O ente possui duas características básicas: Distinção: um ente existe de forma distinta, ou seja, pode ser distinguido do restante da realidade. Sendo assim, a existência de um ente depende da percepção de quem distingue. Se uma distinção é percebida, existe um ente. A distinção está relacionada com níveis de abstração. Por exemplo, um texto é um ente. No entanto, em níveis mais baixos de abstração existem vários outros entes (capítulos, seções, subseções, parágrafos, frases e caracteres).

21 19 A existência deles depende do nível de abstração com que o leitor percebe o texto. Um ente pode ser um objeto, um ser vivo, um software, um modelo computacional, uma organização, um grupo de entes e outras existências; História: um ente possui história. Sendo assim, o ente é uma existência temporal, possuindo passado, presente e futuro. Desde sua criação inicia a construção de uma história, a qual evolui até sua extinção. A história é o passado do ente. Algumas constatações realizadas no presente entram para a história. Além disso, alterações na sua história o afetam de diversas formas. REALIDADE História História Distinção Figura 2.4 -Características dos entes 2.3 Tipos de Entes O bloco principal de construção no Holoparadigma é o ente. Todos os elementos até os mais básicos são considerados entes. Em Holo existem duas classificações básicas para os entes. Classificação organizacional: Ente Elementar: ente sem níveis de composição; Ente Composto: ente formado pela composição de outros entes. Não existe limite para níveis de composição.

22 20 Classificação funcional: Ente Estático: definição estática de um ente. São utilizados como matrizes estáticas para criação de outros entes. Além disso, estabelecem um estado inicial para execução de programas. Um ente estático equivale a uma classe no paradigma Orientado a Objetos. Ente Dinâmico: ente em execução. Um programa em execução é composto de entes dinâmicos. Podem ser comparadas com objetos na Orientação a Objetos. Entes dinâmicos são provenientes de estáticos. Um ente elementar é organizado em três partes: Interface: descreve suas possíveis relações com os demais entes. Comportamento: contém ações que implementam a funcionalidade de um ente. O Holo não estabelece os tipos de ações a serem utilizadas, no entanto, estabelece que existem dois tipos básicos de comportamento: Imperativo: o comportamento imperativo é composto de ações imperativas que descrevem os caminhos para solução de um problema (enfoque no controle, ou seja, como deve ser realizada a ação); Lógico: o comportamento lógico é composto de ações lógicas que expressam um problema de forma declarativa (enfoque no que deve ser realizado). História: é um espaço de armazenamento compartilhado no interior de um ente. O símbolo é o átomo de informação no Holoparadigma. O Holo propõe a utilização do processamento simbólico como principal instrumento para o tratamento de informações. Esta características é herdada do paradigma em lógica. O Holo estabelece que a história deve ser direcionada para armazenamento e gerenciamento de símbolos. Portanto, o paradigma em lógica torna-se uma alternativa adequada para sua implementação.

23 21 Um ente composto possui a mesma organização de um ente elementar, no entanto, suporta a existência de outros entes na sua composição (entes componentes). Cada ente possui uma história. A história fica encapsulada no ente e, no caso dos entes compostos, é compartilhada pelos entes componentes. Os entes componentes participam do desenvolvimento da história compartilhada e sofrem os reflexos das mudanças históricas. Sendo assim, podem existir vários níveis de encapsulamento da história. Os entes acessam somente a história em um nível. A figura 2.5 mostra dois níveis de história encapsulada em um ente composto organizado em três níveis. Figura 2.5 Ente elementar e composto e composição de 3 níveis 2.4 Holoclonagem O Holoparadigma estabelece que um software pode ser percebido através de dois domínios:

24 22 Estático: é realizada na descrição dos entes, ou seja, durante a especificação em nível de modelagem e programação. A clonagem estática permite a descrição de entes através da extensão de especificações de outros entes; Dinâmico: ocorre em tempo de execução. Esta clonagem cria uma cópia de um ente em execução. Neste caso, o clone possui a estrutura (interface e comportamento) e o estado (história e composição) do clonado. O clone é criado no mesmo nível e passa a acessar a mesma história que ele acessa. A clonagem sintetiza 3 operações utilizadas na orientação a objetos: Clonagem Estática: assemelha-se à herança. Clonagem de Transição: equivale à instanciação de objetos usando classes. Clonagem dinâmica: corresponde a criação de clones suportada por algumas linguagens orientadas a objetos. A possibilidade da existência de características não-deterministas nos entes permite ainda que a clonagem possa ser de dois tipos: Construtiva: estabelece que as especificações do clone e dos clonados são combinadas de forma construtiva. Esta combinação é uma união das especificações nãodeterministas, por exemplo o comportamento lógico. A união pode seguir diversas políticas. Destrutiva: estabelece que as especificações do clone e dos clonados são combinadas de forma destrutiva. As especificações mais recentes sobrepõem as anteriores (padrão utilizado na herança da orientação a objetos). 2.5 Hololinguagem A Hololinguagem [BAR 99a], [BAR 2001], [BAR 2001a], [BAR 2001b], é uma linguagem multiparadigma direcionada para o desenvolvimento de sistemas distribuídos Descrição de entes na Hololinguagem O programa em HOLO é formado por descrições de entes (entes estáticos).

25 23 A figura 2.6 mostra a descrição de um ente. A descrição é formada por cabeça e corpo [HOL 2001]. A cabeça contém o nome do ente, seus argumentos e uma descrição de sua clonagem. As variáveis utilizadas são visíveis em todo o corpo. Estas variáveis podem receber valores no momento da criação de um ente, mas não podem ser alteradas durante sua existência. O único espaço de armazenamento compartilhado no interior de um ente é a história. Na cabeça são explicitadas as ações que implementam a funcionalidade. A história é um blackboard que pode ser acessado pelas ações, pelos entes componentes ou pela história. A história armazena Cláusulas Lógicas com Extensão não Imperativas (CLEI). A CLEI é uma cláusula lógica que suporta apenas extensões extralógicas não imperativas (facilidades aritméticas ou facilidades de comparação). Comportamento <nome>(<argumentos>)cloning(<descrição>) Interface<açõesexportadas>. { Ações Cabeça História history { CLEIs } } Corpo Figura Descrição de um ente O comportamento de um ente é descrito através de ações. As ações suportam invocações com o uso de nomes e argumentos. Além disso, cada ação pode ser identificada univocamente através de um Identificador de Ação.

26 24 Existem 5 tipos de ações: Ação lógica (LA): ação formada por um único predicado. Ação imperativa (IA): ação formada por uma função imperativa. Ação modular lógica (MLA): é um módulo que encapsula LAs. Ação modular imperativa (MIA): ação formada por um módulo que encapsula ações imperativas. Ação multiparadigma (MA): ação que suporta o encapsulamento de LAs e IAs Tipos de invocação na Hololinguagem Na Hololinguagem uma invocação é configurada usando uma Estrutura de Configuração de Invocação (EIC) composta de três campos: Identificador de destino (DI) Modo de invocação Informação simbólica 2.6 Holoplataforma Uma plataforma é um conjunto de software e hardware que suporta o desenvolvimento e a execução de sistemas computacionais. A figura 2.7 apresenta a organização da atual plataforma do Holopardigma (Holoparadigma 1.0) [BAR 99a], [BAR 2001a], [BAR 2001c]. Atualmente o Holoparadigma suporta o ciclo de desenvolvimento e execução em ambientes centralizados. Ainda não existe suporte à execução distribuída.

27 25 HoloEnv 1.0 HoloJava 1.0 Ambiente Java Kava C + JVM,) Arquitetura Centralizada DHolo Arquitetura Distribuída Figura Holoplataforma versão 1.0 HoloEnv 1.0 é um ambiente para desenvolvimento de soluções na Hololinguagem. HoloJava é uma ferramenta para conversão de programas para Hololinguagem. Esta ferramenta converte programas em Holo para programas em Java. Esta técnica é bastante usada na avaliação de novas linguagens, pois a utilização de uma linguagem destino que possua uma plataforma (compilação e execução) já disponível, antecipa a realização de testes e a difusão de resultados da pesquisa. Ambiente Java é utilizado para compilação e execução de programas Holo convertidos em Java. Ela será utilizada até o desenvolvimento de uma plataforma completa para a execução de programas em Holo que envolve a criação de uma máquina multiparadigma, a especificação de seu código virtual e a construção de um compilador.

28 26 Distributed Holo (DHolo): é um ambiente para execução distribuída de Holoprogramas. O seu desenvolvimento depende da implementação de suporte para mobilidade física e história distribuída. Para isso, torna-se necessário à utilização de bibliotecas especiais. Estas bibliotecas devem estar disponíveis para a HoloJava. 2.7 HML (Holo Modeling Language) É uma modelagem proposta para o Holoparadigma. Inicialmente será dada uma visão geral da linguagem, suas características básicas e aplicação, em seguida é abordada a notação de entes, sua estrutura e representação na linguagem. Por fim são discutidos os diagramas básicos inicialmente propostos pela linguagem [LAE 2002] Visão Geral O Holoparadigma propõe uma visão de software diferente das conhecidas atualmente. Por ser o ente um bloco básico da construção de qualquer aplicativo em Holo, merece uma atenção especial, que não pode ser dada pelos métodos de modelagem conhecidos. Neste contexto surge a HML (Holo Modeling Language), uma linguagem de modelagem projetada para visualização, especificação, implementação e documentação de programas em Holo. A HML está sendo especificada para auxiliar o desenvolvedor na criação de soluções na Hololinguagem. Estas podem ser modeladas por representações gráficas trazidas pela linguagem de modelagem, facilitando assim o entendimento do projeto e a comunicação entre as pessoas envolvidas no mesmo. A HML possui muitas características da UML. Podem ser citados, por exemplo, o diagrama de ente que na HML este diagrama define quais os entes estáticos devem pertencer ao sistema. Em UML existe o diagrama de classes, cuja finalidade é representar as estruturas estáticas de objetos. A partir dessa definição são criadas instâncias de objetos em tempo de execução (teoria de clonagem dinâmica de entes).

29 Elementos de Modelagem da HML São todos os elementos que constituem um diagrama. Podem ser entes estáticos, entes dinâmicos, notas, representação de diagramas, clonagens, afirmações, perguntas, etc Notação de ente estático na HML No Holoparadigma, o elemento fundamental para construção de programas é o ente. A importância do ente no Holo pode ser comparada a do objeto na orientação a objetos. O ente é representado na sua forma estática por um retângulo com quadro divisões que corresponde cada uma as partes de um ente estático: Nome do ente <nome>(<argumentos>)cloning(<descrição>) Interface<açõesexportadas>. { Cabeça Interface Comportamento História Ações history { CLEIs } } Corpo Figura 2.8 Notação de ente na HML O ente possui as seguintes características: Nome: é um identificador único para o ente dentro do sistema. História: é um espaço de armazenamento compartilhado no interior de um ente. Ela armazena Cláusulas Lógicas com Extensões não Imperativas (CLEI), que representam o conhecimento inicial do ente.

30 28 Comportamento: armazena as ações executadas pelo ente em determinado momento de sua existência. Pode-se comparar o comportamento de um ente com os métodos de um objeto na orientação a objetos Notação de ente dinâmicos É um ente em execução. Durante sua existência um ente dinâmico pode executar ações ou interagir com outros entes de acordo com seus comportamentos e histórias. Um ente dinâmico sempre é clonado de um ente estático, esta clonagem pode ser comparada à instanciação de um objeto na orientação a objetos, onde o ente estático é a classe e o ente dinâmico o objeto. Na HML um ente dinâmico é representado por um círculo e seu nome é colocado logo abaixo. Mineiro Figura Notação de ente dinâmico Notação de modos de invocação No Holoparadigma existem dois modos de invocação para a interação entre entes de um sistema: a afirmação e a pergunta. Ha HML, cada um destes modos possui uma representação gráfica que permite a identificação do mesmo. Afirmação: É representada por uma linha com uma seta partindo da origem, que esta afirmando, chegando até o ente ou parte do ente que recebe a afirmação. Uma afirmação é sempre não bloqueante, ou seja, não estabelece sincronismo e permite a concorrência máxima. A seta possui uma Informação Simbólica, que representa o que se esta afirmando. No caso de uma afirmação para a história, a informação simbólica é

31 29 uma tupla, que será adicionada a história. Uma afirmação segue todas as regras definidas pela configuração de invocações do Holoparadigma. Informação Simbólica Figura 2.10 Representação de afirmação na HML Pergunta: No Holoparadigma a pergunta pode ser realizada entre entes ou entre as partes de um ente. Uma pergunta pode ser bloqueante (símbolo.), ou sem símbolo quando a invocação é de ação própria, ou não bloqueante (símbolo?). Uma pergunta pode ser destrutiva que exige a destruição no destino. As perguntas destrutivas somente podem ser executadas na região imperativa. Uma pergunta não bloqueante retorna sucesso apenas se as respostas exigidas estiverem disponíveis imediatamente, uma pergunta destrutiva destrói apenas se o número de respostas exigidas for encontrado. Na HML, as perguntas são representadas por uma linha que parte da origem e termina com um símbolo < > no destino. Dentro desse símbolo deve-se especificar o tipo de pergunta.. Bloqueante não destrutivo.# Bloqueante destrutivo? Não bloqueante não destrutivo?# Não bloqueante destrutivo Figura Representação de pergunta na HML

32 Notação dos tipos de clonagem A HML permite a representação da clonagem estática de entes definida pela Hololinguagem. A clonagem estática entre entes pode ser completa ou seletiva, a HML traz uma representação para cada um dos tipos de clonagem existentes. Clonagem completa: é representada por uma linha sólida que liga o ente origem (clonado) com o clone. Esta linha possui um terminador na forma de um traço que aparece próximo ao ente clone (figura 2.12). Clonagem seletiva: utiliza símbolos ao clone. A tabela a seguir apresenta os símbolos que representam a clonagem seletiva. Esta tabela possui três colunas: Tipo de clonagem, símbolo para clonagem construtiva e símbolo para clonagem destrutiva. Tipo de Clonagem Clonagem Construtiva Clonagem Destrutiva Interface Comportamento História Representação de clonagens entre entes O Holoparadigma especifica que um ente estático pode derivar de mais de um ente (clonagem múltipla), que na HML pode ser representada como na figura 2.12, onde o ente3 está sendo clonado do ente1 e ente2. Sendo que o ente3 é clonado de forma completa do ente1 e de forma seletiva do ente 2 (somente o comportamento de forma construtiva e a história de forma destrutiva). ente1 ente2 ente3 Figura 2.12 Exemplo de clonagem estática

33 31 No exemplo acima o quadrado preenchido representa a clonagem destrutiva da história e o triângulo representa a clonagem construtiva do comportamento, portando o ente3 vai receber todas as informações da história do ente2. O comportamento do ente3 vai receber todas as ações do ente2, seguindo as políticas para clonagem definidas pelo Holoparadigma Notação dos tipos de Mobilidade Lógica A Hololinguagem permite ao programador definir explicitamente as mobilidades lógicas executadas pelos entes. As mobilidades físicas ficam implícitas para o programador sendo realizadas automaticamente pela plataforma de execução, no balanceamento da carga ou em uma mobilidade lógica cujo ente destino esteja em outro modo da rede. A mobilidade na HML é representada por uma seta ligando o ente móvel ao seu destino. Para que haja a mobilidade o ente destino deve existir no ambiente. No entanto, a definição da Hololinguagem permite que um ente mova-se para dentro de outro ente mesmo que este não esteja visível. Há três tipos de mobilidade lógica definida pela Hololinguagem: Mobilidade Adaptativa: o ente origem atravessa todas as barreiras de entes necessárias até encontrar o ente destino. O ente destino é procurado em todo o ambiente, caso não seja encontrado uma exceção é gerada e o ente origem continua na mesma posição. Uma seta aberta representa a mobilidade adaptativa na HML (figura 2.13). Figura 2.13 Representação da mobilidade lógica adaptativa Mobilidade Não Bloqueante: somente ocorre se o ente destino for visível ao ente origem. Caso o ente destino não esteja visível para o ente, é gerada uma exceção e o ente origem continua na mesma posição. Na HML, a mobilidade não bloqueante é representada por uma seta fechada (figura 2.14).

34 32 Figuras Representação da mobilidade lógica não bloqueante Mobilidade Bloqueante: Caso o ente destino esteja visível para o ente origem, a mobilidade ocorre instantaneamente. Caso contrário, o ente fica congelado até que o ente destino torne-se visível, neste instante a mobilidade ocorre automaticamente. Uma seta fechada preenchida representa a mobilidade bloqueante na HML (figura 2.15). Figuras Representação da mobilidade lógica bloqueante Notação do Diagrama de Interação O diagrama de interação como um elemento de modelagem é representado por um retângulo com setas nas suas laterais esquerda e direita que representam a troca de informações, e um nome que sugere as interações executadas pelo mesmo. A figura 2.16 exemplifica esse tipo de representação. Descarregar informações na base Figura 2.16 Representação do elemento de modelagem diagrama de interação 2.8 Diagramas São as representações gráficas que especificam o funcionamento estático ou dinâmico de um sistema. Os diagramas descrevem possíveis visões do sistema.

35 Diagrama de Entes Estáticos Este diagrama é utilizado para descrever os entes que fazem parte de um programa em Holo. Ele é composto por descrições de entes estáticos, as quais estabelecem interfaces, comportamentos e histórias. Um ente estático possui um nome para identificá-lo, uma interface que permite aos outros entes interagirem com o mesmo, os comportamentos e a história inicial, que poderá ser alterada quando o mesmo tornase um ente dinâmico através da clonagem de transição. O diagrama de entes estáticos pode ser considerado como o estado inicial de um programa Holo antes de sua execução. Ele pode ser comparado com um diagrama de classes na orientação a objetos. Também pode representar os tipos de clonagem definidos no Holoparadigma. O diagrama de ente estático da HML foi desenvolvido para permitir ao projetista criar a estrutura de um programa em Holo, definindo comportamentos e conhecimentos iniciais de todos os entes do sistema antes de sua execução. Este diagrama possibilita a geração automática de código na Hololinguagem Diagramas de Interação Este diagrama apresenta uma visão interna de um determinado ente, sendo formado pela história do ente, sua interface e seu comportamento e os entes que estão inseridos dentro deste ente composto (representação de ente dinâmico). Ente1 tupla1 Ente2 tupla1 HISTÓRIA Figura 2.17 Diagrama de interação

36 34 O objetivo do diagrama de interação é permitir a visualização interna do ente em determinado instante de tempo dentro do sistema. Na figura 2.17, o ente1 e o ente2 fazem uma pergunta bloqueante destrutiva a história e os dois ficam bloqueados esperando que esta informação seja adicionada na história do ente composto. Devido ao tipo de pergunta efetuado, os entes 1 e 2 somente poderão continuar sua execução após obterem o valor solicitado na história. Em seguida poderia ser modelado um diagrama, como na figura 2.18, onde o ente3 faz uma afirmação à história, inserindo um valor, esperando pelos entes 1 e 2, porém somente um destes entes poderá prosseguir a execução, pois ambas as perguntas são destrutivas. Neste caso, o primeiro ente que obter a informação exclui a mesma da história e o outro continuará esperando até que a informação seja novamente inserida na história. O critério a ser utilizado para controle de concorrência é o mesmo definido nas estruturas do tipo fila, onde o primeiro ente que solicitará a informação recebe a prioridade. Ente3 Ente1 Ente2 tupla1 tupla1 HISTÓRIA (a) Ente3 faz afirmação à história

37 35 Ente3 Ente1 Ente2 tupla1 HISTÓRIA (b) Ente1 é desbloqueado Figura 2.18 Diagrama de interação Diagramas de Mobilidades Na HML os diagramas de mobilidade são utilizados para representação da mobilidade lógica dos entes dentro de um ambiente. Foram definidos dois tipos de diagramas para representar a mobilidades dos entes dentro de um sistema. No primeiro denominado diagrama de mobilidade individual, as mobilidades são representadas individualmente pelo diagrama, sendo necessário um diagrama para representar cada ente em separado. O ente é representado por um pequeno círculo preenchido, que pode mover-se para a linha do tempo de outros entes. Este diagrama pode representar apenas um ente por vez. A figura 2.19 demonstra o gráfico.

38 36 = mineiro Holo mina 1 mina 2 Início 1º Mov. 2º Mov. 3º Mov. 4º Mov. Figura 2.19 Diagrama de mobilidade individual O segundo diagrama é denominado diagrama de mobilidade coletiva. Ele possibilita a modelagem da movimentação de vários entes ao mesmo tempo. É também composto por linhas horizontais que representam os entes dentro do sistema. Um ente móvel é uma destas linhas e move-se para outro ente que por sua vez também pode mover-se, permitindo assim a representação da mobilidade de vários entes de forma concorrente. A linha do ente Holo é a única que não recebe uma representação de ente dinâmico por ser este um ente que sempre vai existir em um ambiente. As linhas verticais representam um instante de mobilidade, ou seja, o ponto em que foi disparada a mobilidade do ente. O exemplo da figura 2.20 representa a mesma mobilidade apresentada no diagrama de mobilidade individual. Neste caso pode haver a mobilidade dos entes da mina1 e mina2. Mas alguns erros podem aparecer e devem ser evitados, como por exemplo mover a mina1 e a mina2 no instante1. Apesar de ser permitida na Hololinguagem, ficaria difícil a compreensão pois não se saberia qual das mobilidades deve ocorrer primeiro, se o mineiro 1 ou o mineiro 2. A seta pontilhada do diagrama demonstra o tipo de problema.

39 37 HOLO Mineiro mina 1 mina 2 Instante Instante Instante Instante Instante Figura 2.20 Diagrama de mobilidade coletiva Diagramas de Visões do Sistema Este diagrama é equivalente ao diagrama de mobilidade individual apresentado na figura 2.19, porém ele permite a visualização das interações que ocorrem durante a movimentação do ente minerador. Isso é possível pois o diagrama exibe alguns elementos de modelagem que são ligações para os diagramas de invocação correspondentes. A figura 2.21.

40 38 = mineiro Holo mina 1 mina 2 Início 1º Mov. 2º Mov. 3º Mov. 4º Mov. Armazena Informações na mina1 Armazena Informações da mina2 Descarrega informações na base Descarrega informações na base Figura 2.21 Visão dinâmica de um sistema

41 39 3. Mobilidade Define-se mobilidade como a capacidade das entidades computacionais deslocar-se de um ambiente para outro, através do sistema distribuído. Atualmente, a maioria das aplicações de mobilidade são desenvolvidas utilizando ou baseando-se nos paradigmas de orientação a objetos ou de agentes. Podese observar que estes dois paradigmas, estão cada vez mais presentes no desenvolvimento destas aplicações [DÖM 2002]. Os sistemas distribuídos apresentam várias características que são objetos de constante pesquisa na busca de soluções, tais como: afastamento, concorrência, ausência de estado global, ocorrência de falhas parciais, assincronismo, heterogeneidade, autonomia e mobilidade Conceitos As pesquisas que envolvem mobilidade conceituam este termo de várias formas. A maioria refere-se à mobilidade através do termos código móvel (mobile code) e agentes móveis (mobile agent). Mobilidade é a habilidade de mover-se independentemente de um dispositivo para outro através da rede. Código móvel pode ser definido como a capacidade de dinamicamente trocar as ligações entre os fragmentos de código e a localização onde o código é executado. Código móvel é um software que viaja através de redes heterogêneas, atravessando vários domínios, sendo que é automaticamente executado quando chega em seu destino. Agentes móveis são programas que podem ser disparados de um computador cliente e transportado para um computador remoto para ser executado.

42 40 Agentes móveis são programas que podem se mover através de uma rede de computadores conforme queiram seus usuários. Agentes móveis são programas inteligentes que podem ser transmitidos entre os diversos computadores de um sistema distribuído. Podemos notar um elemento presente em todos os conceitos: O deslocamento das entidades envolvidas (objetos ou agentes). Pode-se dizer que mobilidade é a capacidade das entidades envolvidas na computação deslocarem-se através de um sistema distribuído [COM 2002]. Mobilidade não é uma concepção nova. Um exemplo é a migração, pois migrar processos ou objetos é uma forma de mobilidade que já é usada em pequena escala. As pesquisas em mobilidade vem crescendo muito atualmente devido principalmente a possibilidade de explorar código móvel em grande escala, onde as redes interligadas são heterogêneas e gerenciadas por organizações diferentes Mecanismos Tecnologias que exploram mobilidade devem prover mecanismos que suportem o deslocamento de suas entidades. Estes mecanismos necessitam de uma estrutura computacional que suporte à mobilidade. Sendo assim, a concepção de um ambiente computacional (Computational Environment) deve ser introduzida para suportar os diversos mecanismos necessários à mobilidade. Um ambiente computacional retêm a identidade do nodo onde está localizado dando suporte para que as aplicações tenham a capacidade de recolocar dinamicamente seus componentes em diferentes ambientes computacionais. Um exemplo de ambiente computacional é a máquina virtual Java (Java Virtual Machine). À mobilidade é determinada pela característica do sistema. Por exemplo, em Java é possível mover somente o código de um Applet. Já em Java Aglet, tanto o código quanto o estado são movidos [INF 2002].

43 41 Podem ser identificadas duas formas de mobilidade: mobilidade forte e mobilidade fraca. A Mobilidade forte permite que a unidade de execução possa mover seu código e o estado da computação para diferentes ambientes computacionais. Neste caso, a execução é suspensa, transmitida para o ambiente computacional destino, e sua execução é retomada. Mobilidade fraca permite transferir código de um ambiente computacional para outro. O código pode conter alguns dados inicializados, mas o estado da unidade de execução não é movido. A mobilidade forte pode ser explorada através de dois mecanismos: migração (migration) e clone remoto (remote cloning). O mecanismo de migração suspende a execução de uma unidade de execução, transmite para o ambiente computacional destino e retoma sua execução. Mecanismos que suportam mobilidade fraca têm a capacidade de transferir código através de ambientes computacionais e ligar-se dinamicamente com uma unidade de execução ativa ou criar uma nova unidade de execução no ambiente remoto para a execução. Estes mecanismos podem ser classificados de acordo com a direção da transferência do código, a natureza do código movido, a sincronização envolvida e o momento em que o código é executado no ambiente remoto Tecnologias e equipamentos para suporte à mobilidade Apresentamos algumas ferramentas usadas para desenvolver sistemas que suportam mobilidade e alguns ambientes que permitem explorar mobilidade, tais como Java, Obliq e Oz Distribuído, que são linguagens de programação que permitem implementar mobilidade. Apresentamos também o CORBA, destacando sua contribuição para exploração da mobilidade e alguns ambientes que suportam mobilidade, tais como Voyager, Aglets e Concórdia.

44 42 JAVA Java é uma linguagem orienta a objetos, baseada em classes, criada pela Sun Microsystems, com ênfase em portabilidade e segurança. O compilador Java transforma programas fontes em uma linguagem independente de plataforma chamada Java Byte Code. Um dos fatores de sucesso de Java é o seu uso na Internet. Browsers suportam JVM e carregam classes chamadas Applet. Java provê suporte aos mecanismos da linguagem que permitem implementar mobilidade. A sua entidade computacional é o objeto. Além disso, Java explora mobilidade fraca, do tipo autônoma, pois permite que os programas sejam carregados dinâmicamente pela rede, através do ClassLoader. Java é uma das linguagem mais usada para implementar mobilidade. Ainda pode-se observar que aplicações móveis desenvolvidas através do paradigma de Código em demanda podem ser desenvolvidas utilizando Java. OBLIQ Obliq, é uma linguagem com um escopo léxico, e dinamicamente tipada, baseada em protótipo, projetada para computação distribuída orientada a objeto e pertence a uma classe de linguagens orientada a objetos. Nestas linguagens não existem classes e objetos são criados por cópia (clone) de objetos existentes (os protótipos), Obliq é tipada dinamicamente, suporta o paradigma de avaliação remota e objetos serializados. Obliq suporta mobilidade forte, tanto através de migração quanto através de clone remoto, Além disso, a máquina de execução Obliq oferece um ambiente computacional propício a exploração da mobilidade e sua entidade base é o objeto. OZ DISTRIBUÍDO A linguagem Oz distribuída é uma linguagem projetada para processamento simbólico concorrente. O Oz integra vários paradigmas de programação, incluindo orientação a objetos, funcional e de restrições lógicas em um único modelo.

45 43 A mobilidade em OZ é a habilidade que uma entidade stateful, que pode mudar seu estado, tem de migrar entre os sites ou de permanecer estacionária entre os sites, sua entidade base é o objeto, seu ambiente computacional é a Oz Virtual Machine que, como em Java, é portável, podendo executar tanto em Unix como em Windows. CORBA A organização OMG (Object Management Group) estabeleceu a arquitetura CORBA como uma forma de especificar um middleware aberto composto de objetos distribuídos. O objetivo primário é alcançar sistemas baseados em objetos em ambientes distribuídos heterogêneos com características de reusabilidade, portabilidade e interoperabilidade. O CORBA permite que diferentes objetos escritos em diferentes linguagens, sejam auto-documentáveis e possam interoperar através das redes e de sistemas operacionais Ambientes que permitem explorar a mobilidade VOYAGER O Voyager consiste de uma plataforma ORB implementado em Java e com suporte a agentes. É uma plataforma que integra computação distribuída com tecnologia de agentes, suportando objetos móveis e agentes autônomos. Permite que objetos e agentes possam enviar mensagens padrão Java para um agente mesmo sem saber sua localização. Um pacote adicional Java permite ao Voyager criar uma interface para ser usada em um cliente ou servidor CORBA. O voyager permite balanceamento dinâmico de carga.

46 44 Um objeto Voyager é um componente de software que tem um conjunto bem definido de funções e dados encapsulados. Quando um programa Voyager inicia, ele automaticamente cria threads que provêem algum serviço, como garbage collection e verificação do tráfego da rede. Cada programa Voyager tem um endereço na rede consistindo no nome da máquina e o número da porta de comunicação, que é um inteiro único para a máquina. Voyager suporta agentes móveis, sua filosofia é que o agente é simplesmente uma espécie especial de objeto que pode mover-se independentemente, podendo continuar sua execução ao se mover, e no entanto comportar-se exatamente como qualquer outro objeto. AGLETS Aglets são objetos Java com a capacidade de se mover de uma máquina para outra em uma rede, levando consigo o código de programa e o estado dos objetos que compõe o Aglet. Este é um agente móvel porque suporta a idéia de execução autônoma e rota dinâmica de seu etinerário. O modelo Aglet provê comportamentos essenciais com relação a um agente tais como: criação, clonagem, envio, retirada, desativação, ativação, liberação, mensagem e nomeação. Aglets são objetos Java que podem migrar de uma máquina para outra, eles tem um potencial de acesso para todos os recursos da máquina. Eles também confiam na segurança do interpretador Java para sua própria execução. Assim, segurança em Aglet e segurança em Java andam juntas. CONCORDIA O Concordia, concebido pela Mitsubishi constitui-se de um framework para o desenvolvimento e gerenciamento de aplicações de agentes móveis.

47 45 O Concordia compreende múltiplos componentes, todos escritos em Java, na qual são combinados para prover um ambiente para aplicações distribuídas. Este sistema é simples, e requer somente uma implementação padrão do servidor Concordia, feito em cima da máquina virtual Java, e seu ambiente é composto de um servidor e um conjunto de agentes. Quanto a arquitetura do sistema, cada nodo num sistema Concordia consiste em um servidor Concordia e provê serviços básicos para criação, migração, execução, comunicação e administração de agentes móveis Equipamentos para suporte à mobilidade WIRELESS Através de plataformas, muito além de dispositivos e ao redor do mundo, o próximo avanço da revolução do mercado de e-business vem tomando forma. O panorama da tecnologia de informação já está mudando, passando da computação estática para o acesso móvel e inopresente, da relevância limitada para o usuário, para informações verdadeiramente personalizadas. O nome wireless vem do inglês, significando sem fio (wire=fio, less=sem), ou seja acesso sem fio, sendo comumente utilizado no meio da informática para designar as tecnologias que permitem comunicação sem conexão física direta entre os equipamentos. A primeira idéia que vem a cabeça é a utilização de radio para comunicação, que é realmente o meio mais popular, entretanto, é importante lembrar que wireless engloba outros meios de comunicação, como uso de raios de luz infravermelha, menos popular devido a limitações como: não haver qualquer tipo de barreira física entre os pontos de comunicação. Mas a utilização do radio é o meio mais difundido para comunicação de dados sem fio.

48 46 O funcionamento do sistema é muito simples. Podemos compará-lo ao do celular da seguinte maneira: Existe uma antena (figura 3.4), num ponto central e estratégico. Esta antena esta conectada a uma rede local, onde existe um cachê e este conecta-se diretamente a um backbone [MOV 2001]. Esta antena emite um sinal na freqüência de mais ou menos 2.4 GHz utilizando talves o sistema chamado Direct Sequence Spread Spectrum (DSSS). Este sinal é captado por antenas (figuras 3.1, 3.2 e 3.3) instaladas na casa ou na empresa do usuário e é levada até uma placa especial que é instalada dentro de seu computador (esta placa substituí seu FAX Modem), e a partir daí você estará conectado. Basta ligar seu computador para a conexão estar ativa. Figura Parabólica Figura 3.2 Parabólica Figura Direcional Figura Omnidirecional

49 47 Requisitos mínimos para a instalação do nosso sistema Wireless: Pentium 100 com 32 Mbytes de memória RAM ou melhor. Um slot ISA ou PCI vazio 3 Mbytes de espaço disponível em disco. Um ponto com visada direta à antena Windows 95, 98, NT ou Windows Figura Comunicação de dados sem fio WIRELESS LANS (REDES SEM FIO) Esta é uma das aplicações mais populares para a tecnologia wireless, em que se utiliza ondas de rádio para interligação de pontos de redes locais (LANs). Basicamente existem 2 configurações mais comuns: - Interligação de 2 redes locais (ponto-a-ponto), normalmente entre edificações distantes desde algumas centenas de metros até alguns kilometros [INT 2002]. A maior limitação desta aplicação, além da distância, é a necessidade de se ter uma visada direta entre os 2 pontos, sendo como solução de contorno a utilização de repetidores no meio do caminho. - Interligação de estações de redes locais (multi-ponto), normalmente em ambientes fechados, incluindo-se galpões, escritórios e até locais públicos como

50 48 aeroportos. Nesta aplicação, a wireless LAN substitui o cabeamento convencional pela tecnologia de comunicação via rádio. É importante lembrar que quanto mais se está próximo ao limite da distância, mais baixa será a velocidade de comunicação [ISAM 2002]. Também é importante ter em mente que a velocidade da rede sem fio é compartilhada, isto é, todos os nós ativos compartilham a banda, assim, quando se tem muitas estações sem fio a performance é reduzida. Isto deixa claro que esta tecnologia não veio para substituir completamente as redes com fios, como alguns chegam a dizer, pois sua performance não tem como atender as aplicações atuais nem competir em termos de custo, como os benefícios com os switches e Fast Ethernet, por exemplo. Figura Sistema de antenas interligadas entre si, via ondas de rádio COLETORES DE DADOS São utilizados para apontamento de dados, atendendo desde aplicações básicas a projetos complexos integrados ao sistema de informação da empresa em tempo real, através de comunicação via rádio frequência. Estes coletores são utilizados na automação do controle de acesso, entrada/aquisição e consulta de dados, controle de ponto, controle de produção, etc. Seu design de bolso, o leitor potente e leve, aliado à caneta, é usada para entrada de dados, permitem uma série de aplicações, tanto para a indústria como para o varejo e o segmento de serviços [OSH 2002].

51 49 Os coletores da linha SPT foram desenvolvidos na plataforma Palm. Graças a sua capacidade de processamento são indicados para aplicações que requeiram ambientes gráficos, com manipulações complexas de dados. Seus aplicativos são desenvolvidos em PalmOS, o que garante estabilidade, desempenho e versatilidade dos programas Por estas características, a linha SPT tem sido muito usada na área médica, comercial e industrial. Mas as vantagens não param por aí, a linha SPT 1740 e 1746 já vem com módulo de comunicação por radio freqüência acoplado, permitindo comunicação online com seu sistema. O PT 600 pode ser programado em C ou com a ferramenta JobGen. Com essa ferramenta basta você desenhar as telas e usar as funções pre-determinadas, como consultas a banco de dados e cálculos matemáticos. O que muda entre as opções é o grau de tolerância ao trabalho pesado e o tipo de conexão com o computador central [PRO 2002]. Figura Coletores de dados 3.4 Mobilidade no Holoparadigma No Holoparadigma a mobilidade é a capacidade que permite o deslocamento de um ente. Existem dois tipos de mobilidade: Mobilidade Lógica - É a mobilidade que está relacionada com o deslocamento em nível de modelagem. Um ente se move quando cruza uma ou mais fronteiras de entes.

52 50 Na mobilidade lógica quando à um deslocamento, o ente móvel não possui mais acesso à história no ente origem, passando a ter acesso à história no ente destino. Mobilidade Física - É a mobilidade que está relacionada com o deslocamento entre nodos de uma arquitetura distribuída. Um ente se move quando desloca-se de um nodo para outro. Somente acorrerá mobilidade física se os entes origem e destino estiverem alocados em diferentes nodos de uma arquitetura distribuída. As mobilidades lógicas e físicas são independentes, a ocorrência de um tipo de deslocamento não implica na ocorrência de outro. Figura Mobilidade lógica no holoparadigma

53 51 Figura Mobilidade física no holoparadigma O holoparadigma busca a distribuição implícita através da Holosemântica. Um ente assume dois estados de distribuição: Centralizado - Um ente se encontra centralizado quando se localiza em apenas um nodo de um sistema distribuído. Distribuído - Um ente se encontra distribuído quando se localiza em mais de um nodo de um sistema distribuído.

54 52 Figura Ente distribuído Os estudos sobre mobilidade em sistemas distribuídos deu-se pelo surgimento da internet e pela proliferação de dispositivos eletrônicos portáteis. Cardelli [CAL 2000, p.8]destaca que os sistemas distribuídos estáticos baseados em LANs e WANs serão suplantados por um novo paradigma baseado em mobilidade, onde os nodos serão móveis, sendo assim tornam-se relevantes estudos relacionados com formalismo para modelagem de concorrência, distribuição e principalmente mobilidade. Cardelli cria o cálculo de ambientes, este cálculo serve como modelo abstrato para a computação em WANs e possui como principal conceito a noção de barreiras. Neste contexto Cardelli destaca a maioria dos aspectos relacionados à mobilidade que envolvem barreiras: Localidade a noção de posicionamento é induzida pela existência de diversas localizações físicas ou virtuais dependendo de uma topologia de barreiras;

55 53 Mobilidade - deslocamento entre posições envolve a travessiade barreiras; Composição controlada pelas barreiras, comunicações locais que ocorrem no escopo de uma barreira e remotas dependem de mobilidade comunicações locais. 3.5 Mobilidade Hospitalar O Sistema integrado Hospitalar possibilita trabalhar com dispositivos sem fios, tais como computadores de mão e coletores de dados conectados à rede hospitalar por rádio freqüência agregando mobilidade e racionalização. Por esse processo opcional, os profissionais do corpo clínico e do quadro administrativo do Hospital, como médicos, enfermeiros, farmacêuticos, técnicos, e auxiliares, podem usar estes equipamentos que são conectados a rede de computadores do Hospital sem o uso de fios, ou seja a conexão é feita por rádio. Esses dispositivos são conectados ao sistema central de computação através de conexões de rádio, por onde enviam e recebem informações. Essa tecnologia proporciona grande racionalização de procedimentos, facilidades e mobilidade para os profissionais e acesso rápido às informações. O Sistema Hospitalar utilizará tecnologia de ponta para a total informatização do Hospital, englobando todos os seus setores. Essas tecnologias melhoram o atendimento ao paciente e apóiam a administração com informações precisas. Algumas dessas tecnologias são parte do núcleo do sistema, enquanto outras podem ser selecionadas livremente pelo cliente, utilizando-se dos melhores recursos de tecnologia de informação, desde a metodologia de desenvolvimento até o uso das melhores linguagens e banco de dados, proporcionando confiabilidade.

56 54 As principais são: Sistema de código de barras, que traz agilidade e segurança na identificação de pacientes, medicamentos e procedimentos profissionais etc. Computadores e dispositivos sem fio, conectados à rede hospitalar porrádio freqüência, agregando mobilidade e racionalização; O sistema é relevante na Automação Hospitalar por ser aderente aos principais Standards internacionais e incorpora forte especialização em protocolos clínicos; O sistema abrange e integra completamente os assuntos que envolvem a administração hospitalar.

57 55 4. Automação Hospitalar A Automação Hospitalar abrange setores como centro cirúrgico, internação, UTI, enfermagem, farmácia hospitalar, imagens, radiologia, setores administrativos, RH, nutrição e os demais setores que compõe a FAU. Isto possibilita o uso de coletores de dados, ou seja, computadores móveis sem fio, para identificação de pacientes, medicamentos, prontuário e prescrição eletrônica. É um sistema que permite customização às necessidades específicas da Instituição. Ele irá proporcionar a FAU, qualidade e rapidez de atendimento para o paciente, modernização, controle adequado e rentabilidade para a instituição, segurança, racionalização de atividades e evolução para os profissionais. Irá abranger todas as áreas do hospital, como controlar e racionalizar os procedimentos desde a entrada do paciente, consultas, internações, centro cirúrgico, enfermagem e também irá apoiar e automatizar as atividades administrativas como faturamento, compras, estoques e custos dentro da área Administração Financeira. Os médicos poderão usar coletores de dados para consultar prontuários e registrar procedimentos e resultados, logo que entrarem no hospital. Todas as informações sobre pacientes podem ser acessadas via terminal eletrônico, e ou coletores de dados, de forma rápida e eficiente, pois o prontuário eletrônico integra as informações sobre pacientes. O Sistema Hospitalar da FAU possibilitará trabalhar com dispositivos sem fios, tais como computadores portáteis e coletores de dados. Os profissionais do corpo clínico e do quadro administrativo do Hospital, como médicos, enfermeiros, farmacêuticos, técnicos e auxiliares podem usar computadores portáteis e coletores de dados que são conectados à rede de computadores do Hospital sem o uso de fios, ou seja a conexão é feita por rádio. Esses dispositivos são conectados ao sistema central de computação através de conexões de rádio, e por antenas onde enviam e recebem informações, por meio de ondas de rádiofreqüência. Essa tecnologia proporciona grande racionalização de procedimentos, facilidades e mobilidade para os profissionais e acesso rápido às informações.

58 56 Esta é uma solução que compreende todos os processos administrativos e clínicos do paciente, e vem ao encontro das aspirações do Administrador Hospitalar e do Corpo Clínico, proporcionando eficácia, segurança, qualidade e racionalização de procedimentos. O ponto fundamental é o prontuário eletrônico que se interliga com todos os outros módulos do sistema, tanto nas funções de apoio e controle clínico quanto nas funções administrativas. Esta funcionalidade pode ser complementada pela adoção de tecnologias modernas de computação e telecomunicações. Destacam-se os computadores portáteis e wireless, que se comunicam com a rede de dados e com os bancos de dados via rádiofreqüência, permitindo que o prontuário seja consultado e atualizado pelos profissionais do corpo clinico. Hoje a FAU é composta por um conselho e uma direção formada por médicos, e uma diretoria executiva composta por dezenove (19) departamentos, sendo que fazem parte da Administração Financeira e do Apoio mais oito departamentos para cada um, e o Recursos Humanos composto por quatro (4) departamentos. A direção conta ainda com uma Assessoria Jurídica, Relações Públicas, e uma Secretaria. 4.1 Visão Geral dos Equipamentos Instalados na FAU Figura 4.1- Organograma da FAU

59 57 A árvore de entes (HOLOTREE) é uma estrutura hierárquica de entes, criada na execução de um programa. A Holotree implementa e encapsulamento de entes em níveis de composição, além disso a Holotree suporta o aspecto dinâmico da política em grupos, mudando durante a execução do programa através das ações de clonagem e mobilidade. Um ente composto possui ligações com seus entes componentes, localizados nos níveis abaixo. Os entes componentes possuem acesso à história e ao comportamento do ente composto, no qual estão inseridos. O ente composto possui acesso aos comportamentos dos demais entes no mesmo nível. A mobilidade é implementada através de gerenciamento de grupo. Quando a mobilidade ocorre, torna-se necessária a mudança de visão do grupo, o ente movido possui uma nova visão. Se o movido for um ente composto, a visão dos seus componentes não muda. A mobilidade implica na atualização de composição dos entes origem e destino. A mobilidade de um ente elementar equivale a realocação de uma folha da árvore e a mobilidade de um composto transfere um ramo contendo vários entes. A Holotree deste sistema mostra o nível zero, sendo representado pelo ente FAU. O nível um representado pelo ente conselho da FAU. No nível dois representa-se a direção da FAU, e o nível três formado pelos seus entes componentes. O nível quatro é formado pelos entes componentes do ente Diretoria Executiva. Sucessivamente o próximo nível será formado pelos entes componentes que fazem parte dos entes Adm. Financeira, RH e Apoio.

60 Holotree FAU HOLOTREE Nível 0 Cons. FAU Nível 1 Dir. FAU Nível 2 Ass. Jur. Dir. Exec Rel. Púb Secretaria Nível 3. Manip. Oncol. Farm.Dis. Clin. Cirur. Ginec/Obst. Pediat. Endosc. Pré-Nat UTI Imag Fisiat. Espirom. Radil. Ad. Financ RH Apoio Nível 4 C.Médicas CPD SEP SPP Compras Contab. Almox. Gráfica Psic.Trab. DP Med. Trab. RST Nutrição Psic.Clínica Higieniz. Serv.Social Manutenção El.Eletrôn. Recepção Portaria Figura 4.2- Árvore de entes (Holotree)

61 59 Atualmente a FAU contém em suas instalações um número de 140 (cento e quarenta) computadores ligados em rede e 5 (cinco) servidores, sendo que 4 (quatro) estão instalados no Centro de Processamento de Dados, onde podemos constatar um com o sistema operacional Linux, (2) dois com o sistema operacional Windows NT e um Netware. Na Faculdade de Medicina está sendo utilizado um servidor com o sistema operacional Linux. Já encontra-se instalados em alguns pontos da FAU, 4 (quatro) antenas, sendo que uma do tipo Omnidirecional que capta o sinal através de um ângulo de 360º em um plano horizontal, com um peso de menos de 1 kg, uma altura de 1,56 m, resistência ao vento de 100 km/h e polarização vertical, elas trabalham excepcionalmente bem em áreas amplas ou em aplicações multiponto. Usualmente, esse tipo de antena é utilizada em estações de base, com estações remotas colocadas ao seu redor, localizada no prédio do Santa Tereza e as direcionais, concentram o sinal em uma única direção, seus sinais podem ter um alcance longo e estreito ou curto e amplo, quanto maior e estreito o sinal, maiores distâncias ele alcançará. Normalmente este tipo de antena é utilizada com uma ou mais estações bases. Uma localizada no prédio do Centro de Processamento de Dados, outra na Faculdade de Medicina e a última no prédio central da FAU. Futuramente irão ser instaladas mais duas antenas do tipo direcional, sendo uma na Casa de Coleta e a última no Departamento de Pessoal da FAU. Futuramente será instalada mais duas antenas do tipo direcional, uma na Casa de Coleta e outra no Departamento Pessoal da FAU.

62 60 Figura 4.3- FAU - Equipamentos instalados 4.2. Extensão O modelo proposto, foi pensando em simplificar e representar as partes de entes integrantes de um sistema, e especificar seus relacionamentos através da simbologia criada e integrada ao HML (Holo Modeling Language), para facilitar o entendimento da modelagem do projeto num todo e suas partes. A idéia é que se tenha um símbolo, que represente algo físico no ambiente, ou seja, através do diagrama de entes estáticos podemos visualizar toda a estrutura do ambiente de modelagem, no caso à FAU, podemos saber de que forma os entes estão sendo clonados, se de maneira total ou seletiva através de seus componentes interface, história e comportamento, mas não se tinha uma maneira de representar de que partes o principal ente era composto, ele poderia ser clonado, mas na sua estrutura faltava um complemento que pudesse representar as partes deste ente, e de certa forma, poderia ser representado para todos os outros entes. Assim nasceu o Holo-Parte, uma simbologia que mostra o relacionamento entre um ente composto (todo) e os entes que o compõem (partes ou componentes). Foi

63 61 utilizado como parâmetro a UML ((Unified Modeling Language), acrescentando-se assim mais uma especificação ao HML (Holo Modeling Language) Holo-Parte A estrutura do Holo-Parte é mostrada com um Ente (Holo) e depois um Ente (parte), com uma linha desenhada entre eles. Um triângulo preto dentro de um circulo cinza distingue os entes que formam uma estrutura Holo-Parte. A notação é direcional, de forma que a estrutura pode ser desenhada em qualquer ângulo, queremos representar o fato de que um todo possui algumas partes. Um todo pode ter diferentes tipos de partes. Pontos de uma estrutura Holo-Parte são posicionados para refletir um mapeamento entre os entes [OLI 2001]. PARTE 1 HOLO PARTE 2 Figura Notação da estrutura Holo-Parte Podemos considerar algumas variações na estrutura Holo-parte : Recipiente-Conteúdos Conjunto-Membros Montagem-Partes Podemos considerar alguns exemplos destas variações da Estrutura Holo-Parte:

64 62 Médico Clínica Médica Figura Estrutura Holo-Parte Recipiente-Conteúdos Neste exemplo a clinica médica é considerada como um recipiente. Os médicos estão dentro dela [COA 1994]. E se o domínio de problemas e as responsabilidades do sistema incluírem informações sobre médicos qualificados para uma clinica médica específica, então um ente médico será necessário. Funcionário Organização Figura 4.6- Estrutura Holo-Parte Conjunto Membros Este exemplo representa que uma organização é um conjunto de funcionários. Aplica-se o método conjunto-membro para a administração da complexidade de um domínio do problema. Contas Médicas Adm. Financeira Figura Estrutura Holo-Parte Montagem Partes

65 63 O setor administração financeira é uma montagem. Outros setores fazem parte do ente administração financeira, fazendo com que ele exista, contas médicas é apenas um dos entes que o formam, ou seja é uma das partes deste ente que foi usada para esta representação. Figura Diagrama de entes estáticos com a extensão Este diagrama representa a clonagem dos entes de maneira múltipla, seletiva e física. A Diretoria Executiva está sendo clonado de forma múltipla por todos os entes que o compõem. Onde existe uma clonagem da história dos entes de forma construtiva e uma interface destrutiva e fisicamente ele está sendo representado pelo Holo-Parte que na sua estrutura executa a clonagem somente física do ente, não clonando os elementos que constituem o ente (comportamento, história e interface) [RUM 1994].

66 64 A Administração Financeira é composta por uma história e uma interface destrutiva, isto significa que todas as informações dos setores: gráfica, compras, Setor de Prontuário de Pacientes (SPP) e Setor de Estatística e Projetos (SEP), sobrepõe as anteriores, isto é, destruindo as mesmas, caso não haja mais necessidade de armazenálas. Da mesma forma, é clonado uma história construtiva e uma interface destrutiva dos setores do Centro de Processamento de Dados (CPD) e Almoxarifado, que significa que a história será armazenada no interior do ente Administração Financeira. O ente Contabilidade será necessário ser clonado todos os elementos que o compõem (história, comportamento e interface), representado por um terminador na forma de um traço, próximo ao ente clone. O ente Contas Médicas é clonado apenas a história e a interface construtiva. Ao final de cada clonagem dos elementos dos entes aplicou-se a clonagem física através da extensão chamada HOLO-PARTE que significa que todos os entes que o compõem fazem parte da sua estrutura física. Da mesma forma é representado o ente de Recursos Humanos que é composto de 4 entes que são clonados de formas diferentes, ou seja, de forma completa, somente história e comportamento construtivo, somente história construtiva e comportamento destrutivo que por sua vez, significa que todas as ações de um ente especificadas em seu funcionamento não são armazenadas de forma definitiva no ente Recursos Humanos (RH), ou seja, as ações mais recentes sobrepõem as anteriores. Com o término da clonagem dos elementos dos entes que fazem parte do ente RH, segue-se sempre aplicando o HOLO-PARTE representando toda a parte física que compõem o ente RH. O ente Apoio é composto por 8 (oito) entes representados da seguinte maneira: 3 (três) entes clonados com uma história e uma interface destrutiva, 3 (três) entes clonados apenas com uma história construtiva e uma interface destrutiva e 2 (dois) entes clonados com uma história e um comportamento destrutivos, seguidos sempre pelo HOLO-PARTE, onde todos os entes que o compõem fazem parte da composição da sua estrutura física. A Secretaria, Relações Públicas e a Assessoria Jurídica fazem parte da Direção da FAU, isto significa que são partes da estrutura física da Direção da FAU, com uma história e um comportamento construtivo de seus elementos.

67 65 O Conselho da FAU recebe do ente Direção da FAU uma história construtiva e um comportamento destrutivo e ainda toda a clonagem física dos entes que compõem a estrutura da Diretoria Executiva. E finalmente o ente FAU recebe a história e o comportamento construtivo dos elementos do ente do Conselho da FAU, juntamente com toda a parte física de todos os entes que compõem todos os setores da FAU. 4.3 Diagrama de Entes Dinâmicos Este diagrama representa a idéia de como é feita a mobilidade lógica dos entes dentro do sistema, a partir da execução do programa. Também conhecido como D.HOLO. A mobilidade ocorre por meio de níveis de entes onde o menor nível existente representa o maior ente no sistema. Figura Diagrama de entes dinâmicos

68 Diagrama de Mobilidade Individual No Diagrama de Mobilidade Individual, as mobilidades são representadas individualmente pelo diagrama, sendo necessário um diagrama para representar cada ente em separado. Este diagrama é representado na HML por um cabeçalho contendo o nome do ente móvel, as linhas horizontais representam os entes que fazem parte do ambiente e irão receber o ente móvel definido no cabeçalho, as linhas verticais representam o tempo em passos de mobilidade, cada uma das linhas verticais pode receber uma descrição do passo de mobilidade para melhor ilustrar o diagrama, esta descrição ficará contida na parte inferior de cada uma das linhas. O ente move-se da esquerda para a direita e cada seta representa um tipo de mobilidade lógica. A figura 4.9 traz um exemplo de diagrama de mobilidade individual para o ente médico clínico geral. O médico clínico geral está localizado no ente principal Holo FAU, em uma primeira movimentação o ente move-se para dentro da Clínica Médica, esta mobilidade é não bloqueante, ou seja, no caso da Clínica Médica não esteja visível para o ente, uma exceção será gerada e o ente vai permanecer na mesma posição. Em um segundo momento o ente médico clínico geral volta ao ente Holo FAU, esta mobilidade por sua vez é adaptativa, isso significa que o mesmo ente Holo FAU não estando visível ao ente médico clínico geral, este vai varrer todo o sistema a procura do destino, por fim o ente médico clínico geral move-se para o ente cirurgia e em seguida volta ao ente Holo FAU, e sucessivamente este processo se estenderá ao ente UTI, Imagem, Radiologia, Laboratório e Medicina do Trabalho, até terminar a representação da mobilidade. A posição do ente no sistema é exibida o tempo todo no diagrama. O ente é representado por um pequeno círculo preenchido, que pode mover-se para a linha do tempo de outros entes. Este diagrama pode representar a mobilidade de apenas um ente por vez.

69 67 = MÉDICO CLÍNICO GERAL Holo FAU Clín ica Méd Ciru rgia UTI Ima gem Radi ol. Lab Med Trab Início 1º Mov 2º Mov 3ºMov 4ºMov 5ºMov 6ºMov 7ºMov 8ºMov 9ºMov 10ºMov 11ºMov 12ºMov 13ºMov 14ºMov Figura Diagrama de mobilidade individual 4.5 Diagrama de Mobilidade Coletiva Na HML o diagrama de mobilidade coletiva é composto por linhas horizontais que representam os entes dentro do sistema. O ente móvel é uma destas linhas e move-se para outro ente que por sua vez também pode mover-se, permitindo assim a representação da mobilidade de vários entes de forma concorrente. A linha do ente Holo-FAU é a única que não recebe uma representação de ente dinâmico por ser este um ente que sempre vai existir em um ambiente. As linhas verticais representam um instante de mobilidade, ou seja, o ponto em que foi disparada a mobilidade do ente. Cada uma destas linhas pode possuir uma descrição que aparecem na parte inferior do ente.

70 68 Na figura 4.10 representa a mesma mobilidade representada no diagrama de mobilidade individual. Porém, neste caso, o ente móvel Auxiliar Administrativo sai do Holo-FAU e percorre todo o caminho que ele executa diariamente dentro da FAU. Em um primeiro momento ele sai do Holo-FAU e desloca-se até o ente Secretaria e retorna ao ente Holo-FAU. Em um segundo momento o mesmo ente móvel desloca-se para o ente Apoio e logo a seguir retornando ao Holo-FAU. No terceiro momento ele desloca-se para o ente Recursos Humanos retornando a base. O término de sua mobilidade se dará no ente Administração Financeira, onde o ente móvel auxiliar administrativo desloca-se até ele retornando a base, ou seja, o Holo- FAU. HOLO FAU AUX. ADM. Sec. Apoio RH Adm. Finan Instante Instante Instante Instante Instante Instante Instante Instante Instante Figura Diagrama de mobilidade coletiva

71 Diagrama de Visão do Sistema Visões representam os aspectos estáticos e dinâmicos de um sistema. Uma visão é formada por diagramas. No caso para representação da visão estática pode-se utilizar o diagrama de entes estáticos e para a representação da visão dinâmica, utilizam-se os diagramas de interação e mobilidade. Existem ainda a possibilidade de unir diagramas para formar uma visão mais detalhada da solução. A figura 4.11 demonstra um diagrama de mobilidade que contém em cada uma das movimentações uma ligação para um determinado diagrama de interação, permitindo a melhor compreensão do diagrama. O diagrama de visões do sistema é equivalente ao diagrama de mobilidade individual, porém ele permite a visualização das interações que ocorrem durante a movimentação do ente paciente. Isto é possível, pois o diagrama possui alguns elementos de modelagem que são ligações para os diagramas de invocação correspondente. Cada elemento de modelagem representa um diagrama de invocação, ligando-se a uma movimentação no diagrama de mobilidade individual. A HML permite ainda que vários destes elementos apareçam interligados, a ordem com que eles aparecem é a ordem com que serão executados. Porém o primeiro elemento deve estar ligado a uma movimentação. A idéia de visão pode ser aplicada também nos diagramas de mobilidade coletiva, onde os elementos que representam os diagramas de interação, estarão ligados aos instantes de tempo do diagrama de mobilidade coletiva, e seguem as mesmas regras definidas para o diagrama de mobilidade individual.

72 70 = TÉCNICOS DE MANIPULAÇÃO Holo FAU Gráfi ca Man. Elet. Elet. Início 1º Mov 2º Mov 3ºMov 4ºMov 5ºMov 6ºMov Armazena informações na Gráfica Armazena informações na Manut. Armazena informações na Eletroel. Descarrega informações na base Descarrega informações na base Descarrega informações na base Figura Diagrama de visão do sistema Técnicos de Manipulação 4.6 Diagrama de Interação Nos diagramas de interação um ente tem a capacidade de interagir com outros entes. Este diagrama demonstra uma foto interna do ente em um determinado instante dentro do sistema e todos os entes que estão inseridos dentro dele. A primeira figura mostra uma representação gráfica do ente Recursos Humanos (RH), e os entes que fazem parte dele, como: o Recrutamento Seleção e Treinamento, Psicologia do Trabalho, Departamento Pessoal e Medicina do Trabalho. A segunda figura mostra os entes Departamento Pessoal e Medicina do Trabalho em um determinado instante de tempo dentro do sistema, interagindo através da história, realizando uma pergunta bloqueante destrutiva, que significa que os mesmos ficam aguardando a afirmação de outros entes que também fazem parte do ente Recursos Humanos, ou seja, ficam bloqueados até que a afirmação seja inserida na história para possível utilização.

73 71 A última figura é mostra o ente Departamento Pessoal acessando a história do ente Recursos Humanos, através da qual de forma concorrente, ele busca a resposta relativa a sua pergunta e obtém através de uma estrutura do tipo FILA, onde o primeiro ente que solicitara a informação recebe a prioridade, e os entes concorrentes que realizaram a mesma pergunta, ficam aguardando até que seja inserida novamente na história do ente RH uma nova afirmação.. HISTÓRIA. HISTÓRIA

74 72. HISTÓRIA Figura Diagrama de interações OBS: Segue em anexo a representação gráfica da modelagem na HML da Fundação de Apoio Universitário FAU, demonstrando todos os diagramas de mobilidade individual, coletiva, visão do sistema e de interação de todos os entes móveis e de ambiente.

75 73 5. Implementação 5.1 Introdução Este capítulo apresenta programas criados usando a Hololinguagem. Esta linguagem foi escolhida por suportar o desenvolvimento de programas utilizando os princípios do HOLO e por ser uma linguagem multiparadigma direcionada para o desenvolvimento de sistemas distribuídos, e devido também as suas principais características como por exemplo: suporte a mobilidade e suporte a holoclonagem. Por se tratar também de uma linguagem nova que até então está em fase de desenvolvimento e não foi utilizada ainda por nenhum tipo de sistema. O Holoparadigma ainda não se aplica em sistemas distribuídos embora esteja caminhando para tal. Atualmente a holoplataforma suporta o ciclo de desenvolvimento e execução em ambientes centralizados, no entanto, um projeto inicial do HOLO distribuído já foi criado. O seu desenvolvimento depende da implementação de suporte para mobilidade física e história distribuída, para isso torna-se necessário à utilização de bibliotecas especiais que devem estar disponíveis para a Holojava. As arquiteturas distribuídas estão ficando cada vez mais básicas em sistemas computacionais, tornando-se cada vez mais importante a criação de softwares que suportam a exploração da distribuição. Nesse contexto podemos citar que o Holoparadigma está se tornando um dos mais completos sistemas para a arquiteturas distribuídas. Figura Holoprogramas

76 Simulação do ente móvel médico /********************************************************** NOME: Medico.holo DATA: 06/11/02. RESPONSAVEIS: Eduardo Moller e Sandra Kunde. FUNCAO: Simulacao de mobilidade do ente medico. SAIDA: Mensagens na tela mostrando os resultados da simulacao e, em especial, a soma do total de pacientes durante o seu deslocamento. OBSERVACOES: 1) cria 7 setores e um medico e um ente gerenciador; 2) o ente movel gerenciador entra em cada setor e informa o numero de pacientes de cada setor; 3) o ente movel medico entra em cada setor e resgata o dado informado pelo gerenciador; 4) o resultado consiste em um somatorio do numero de pacientes ao longo de sua trajetoria; **********************************************************************/ //******************* ENTE PRINCIPAL ******************************* holo() { holo() { writeln('holo: Vou criar sete setores e um medico'), clone(setor(clinica),clinica), //cria o primeiro setor. clone(setor(cirurgia),cirurgia), //cria o segundo setor. clone(setor(uti),uti), //cria o terceiro setor. clone(setor(imagem),imagem), //cria o quarto setor. clone(setor(radiologia),radiologia), //cria o quinto setor. clone(setor(laboratorio),laboratorio), //cria o sexto setor. clone(setor(medicina_do_trabalho),medicina_do_trabalho), //cria o setimo setor. clone(gerenciador,gerenciador_d), //cria o ente gerenciador. history#geren_saiu, //adiciona a história do ente Holo a informacao. } } clone(medico,medico_d), //Cria o ente medico. time(inicio), //marca o inicio do tempo do percurso do ente medico. history.med_saiu, //o ente medico adiciona a historia do Holo a informacao que saiu. time(fim), writeln('holo: Terminou o deslocamento. Tempo = ',(Fim-Inicio), ' milisegundos.') //************************** ENTE SETOR ****************************** setor() { setor(ident)

77 75 { writeln('setor ',Ident,': Fui criada') } } //******************** ENTE GERENCIADOR *************************** gerenciador() { gerenciador() { writeln('gerenciador foi criado'), writeln('ele tem a funcao de inserir o numero de pacientes em cada setor'), writeln(' '), move(self,clinica), //Passo 1 - Entra na clínica out(history)!pacientes(10), //Passo 2 - Insere na historia do ente clinica o numero de pacientes. move(self,out), //Passo 3 - Sai da clinica move(self,cirurgia), //Passo 4 - Entra na cirurgia out(history)!pacientes(20), //Passo 5 - Insere na historia do ente cirurgia o numero de pacientes. move(self,out), //Passo 6 - Sai da cirurgia move(self,uti), //Passo 7 - Entra na uti out(history)!pacientes(30), //Passo 8 - Insere na historia do ente uti o numero de pacientes. move(self,out), //Passo 9 - Sai da uti move(self,imagem), //Passo 10 - Entra na imagem out(history)!pacientes(40), //Passo 11 - Insere na historia do ente imagem o numero de pacientes. move(self,out), //Passo 12 - Sai da imagem move(self,radiologia), //Passo 13 - Entra na radiologia out(history)!pacientes(10), //Passo 14 - Insere na historia do ente radiologia o numero de pacientes. move(self,out), //Passo 15 - Sai da radiologia move(self,laboratorio), //Passo 16 - Entra no laboratorio out(history)!pacientes(10), //Passo 17 - Insere na historia do ente laboratorio o numero de pacientes. move(self,out), //Passo 18 - Sai do laboratorio move(self,medicina_do_trabalho), //Passo 19 - Entra na medicina_do_trabalho out(history)!pacientes(10), //Passo 20 - Insere na historia do ente medicina_do_trabalho o numero de pacientes. move(self,out), //Passo 21 - Sai da medicina_do_trabalho writeln('gerenciador: Termino da movimentacao.'), out(history)!geren_saiu //Insere na historia do Holo que o gerenciador saiu. } }

78 76 //*********************** ENTE MEDICO ******************************* medico() { medico() { writeln('medico foi criado'), writeln('tem a funcao de resgatar a informacao ao longo de sua trajetoria'), writeln(' '), Soma := 0, move(self,clinica), //Passo 1 - Entra na clínica out(history).pacientes(#x), //Passo 2 - Acessa a historia do ente clinica e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 3 - Sai da clinica Soma := Soma + X, //Passo 4 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,cirurgia), //Passo 5 - Entra na cirurgia out(history).pacientes(#x), //Passo 6 - Acessa a historia do ente cirurgia e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 7 - Sai da cirurgia Soma := Soma + X, //Passo 8 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,uti), //Passo 9 - Entra na uti out(history).pacientes(#x), //Passo 10 - Acessa a historia do ente uti e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 11 - Sai da uti Soma := Soma + X, //Passo 12 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,imagem), //Passo 13 - Entra na imagem out(history).pacientes(#x), //Passo 14 - Acessa a historia do ente imagem e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 15 - Sai da imagem Soma := Soma + X, //Passo 16 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,radiologia), //Passo 17 - Entra na radiologia. out(history).pacientes(#x), //Passo 18 - Acessa a historia do ente radiologia e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 19 - Sai da radiologia. Soma := Soma + X, //Passo 20 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,laboratorio), //Passo 21 - Entra no laboratorio. out(history).pacientes(#x), //Passo 22 - Acessa a historia do ente laboratorio e obtem o numero de pacientes de forma bloqueante. move(self,out), //Passo 23 - Sai do laboratorio. Soma := Soma + X, //Passo 24 - Adiciona o numero de pacientes e acumula em uma variavel soma. move(self,medicina_do_trabalho), //Passo 25 - Entra na medicina do trabalho.

79 77 out(history).pacientes(#x), //Passo 26 - Acessa a historia do ente medicina do trabalho e obtem o numero de pac. de forma bloqueante. move(self,out), //Passo 27 - Sai da medicina_do_trabalho. Soma := Soma + X, //Passo 28 - Adiciona o numero de pacientes e acumula em uma variavel soma. writeln('medico obteve a soma de ', Soma,' pacientes em todo o seu percurso'), writeln(' '), writeln('medico: Termino da movimentacao.'), out(history)!med_saiu //informa que o ente medico saiu do Holo. } RESULTADO Figura Resultado da simulação do ente móvel médico

80 78 MÉDICO O programa é composto por sete Entes Estáticos: Clínica Médica, Cirurgia, UTI, Imagem, Radiologia, Laboratório e Medicina do Trabalho. O Ente Dinâmico D- HOLO (criado automaticamente para o Ente HOLO) cria sete setores e um ente móvel médico. Logo a seguir aguarda os dados serem colocados na história pelo gerenciador. Os setores notificam sua criação e aguardam a entrada do médico. O médico entra em um setor, realiza o processamento dos dados, sai do setor e insere o resultado na história do D-HOLO. Estes passos são executados para cada setor. A figura 5.3 mostra os vinte e oito passos do médico. O cálculo é realizado pelo médico usando uma FILA. O Ente Médico é responsável pelo controle de sua mobilidade. Os passos 2, 6, 10, 14, 18, 22 e 26 do médico utilizam o acesso a história externa. Este acesso é realizado na ação mining. O código mining apesar de ser o mesmo nos sete passos, o out(history) é sensível ao contexto (setor).

81 79 Figura 5.3- Passos da movimentação do ente médico

82 Simulação do ente móvel enfermeiro /********************************************************** NOME: Enfermeiro.holo DATA: 11/11/02. RESPONSAVEIS: Eduardo Moller e Sandra Kunde. FUNCAO: Simulacao de mobilidade do ente enfermeiro. SAIDA: Mensagens na tela mostrando os resultados da simulacao e, em especial, a soma do total de pacientes durante o seu deslocamento. OBSERVACOES: 1) cria 11 setores e um ente movel enfermeiro e outro ente movel gerenciador; 2) o ente movel gerenciador entra em cada setor e informa o numero de pacientes atendidos de cada setor; 3) o ente movel enfermeiro entra em cada setor e resgata o dado informado pelo gerenciador; 4) o resultado consiste em um somatorio do numero de pacientes atendidos ao longo de sua trajetoria; **********************************************************************/ //******************* ENTE PRINCIPAL ******************************** holo() { holo() { writeln('holo: Vou criar onze setores e um ente movel enfermeiro'), clone(setor(enfermagem),enfermagem), //cria o primeiro setor. clone(setor(cirurgia),cirurgia), //cria o segundo setor. clone(setor(ginecologia),ginecologia), //cria o terceiro setor. clone(setor(pediatria),pediatria), //cria o quarto setor. clone(setor(endoscopia),endoscopia), //cria o quinto setor. clone(setor(pre_natal),pre_natal), //cria o sexto setor. clone(setor(uti),uti), //cria o setimo setor. clone(setor(clinica_medica),clinica_medica), //cria o oitavo setor. clone(setor(fisiatria),fisiatria), //cria o nono setor. clone(setor(espirometria),espirometria), //cria o decimo setor. clone(setor(oncologia),oncologia), //cria o decimo primeiro setor. clone(gerenciador,gerenciador_d), //cria o ente gerenciador. history#geren_saiu, //adiciona a história do ente Holo a informacao. clone(enfermeiro,enfermeiro_d), //cria o ente enfermeiro. time(inicio), //marca o inicio do tempo do percurso do ente enfermeiro. history.enf_saiu, //o ente enfermeiro adiciona a historia do Holo a informacao que ele saiu. time(fim), writeln('holo: Terminou o deslocamento. Tempo = ',(Fim-Inicio), ' milisegundos.')

83 81 } } //************************** ENTE SETOR ****************************** setor() { setor(ident) { writeln('setor ',Ident,': Fui criada') } } //******************** ENTE GERENCIADOR *************************** gerenciador() { gerenciador() { writeln('gerenciador foi criado'), writeln('ele tem a funcao de inserir o numero de pacientes em cada setor'), writeln(' '), move(self,enfermagem), out(history)!pacientes(10), numero de pacientes atendidos. move(self,out), move(self,cirurgia), out(history)!pacientes(20), numero de pacientes atendidos. move(self,out), move(self,ginecologia), out(history)!pacientes(30), numero de pacientes atendidos. move(self,out), move(self,pediatria), out(history)!pacientes(40), numero de pacientes atendidos. move(self,out), move(self,endoscopia), out(history)!pacientes(10), numero de pacientes atendidos. move(self,out), move(self,pre_natal), out(history)!pacientes(10), numero de pacientes atendidos. move(self,out), move(self,uti), out(history)!pacientes(10), de pacientes atendidos. move(self,out), move(self,clinica_medica), //Passo 1 - Entra na enfermagem. //Passo 2 - Insere na historia do ente enfermagem o /Passo 3 - Sai da enfermagem. //Passo 4 - Entra na cirurgia. //Passo 5 - Insere na historia do ente cirurgia o //Passo 6 - Sai da cirurgia. //Passo 7 - Entra na ginecologia. //Passo 8 - Insere na historia do ente ginecologia o //Passo 9 - Sai da ginecologia. //Passo 10 - Entra na pediatria. //Passo 11 - Insere na historia do ente pediatria o //Passo 12 - Sai da pediatria. //Passo 13 - Entra na endoscopia. //Passo 14 - Insere na historia do ente endoscopia o //Passo 15 - Sai da endoscopia. //Passo 16 - Entra no pre_natal. //Passo 17 - Insere na historia do ente pre_natal o //Passo 18 - Sai do pre_natal. //Passo 19 - Entra na uti. //Passo 20 - Insere na historia do ente uti o numero //Passo 21 - Sai da uti. //Passo 22 - Entra na clinica_medica.

84 82 out(history)!pacientes(11), //Passo 23 - Insere na historia do ente clinica_medica de pacientes atendidos. move(self,out), //Passo 24 - Sai da clinica_medica. move(self,fisiatria), //Passo 25 - Entra na fisiatria. out(history)!pacientes(9), //Passo 26 - Insere na historia do ente fisiatria de pacientes atendidos. move(self,out), //Passo 27 - Sai da fisiatria. move(self,espirometria), //Passo 28 - Entra na espirometria. out(history)!pacientes(15), //Passo 29 - Insere na historia do ente espirometria de pacientes atendidos. move(self,out), //Passo 30 - Sai da espirometria. move(self,oncologia), //Passo 31 - Entra na oncologia. out(history)!pacientes(15), //Passo 32 - Insere na historia do ente oncologia de pacientes atendidos. move(self,out), //Passo 33 - Sai da oncologia. writeln('gerenciador: Termino da movimentacao.'), out(history)!geren_saiu //Insere na historia do Holo que o gerenciador saiu. } } //*********************** ENTE ENFERMEIRO ************************** enfermeiro() { enfermeiro() { writeln('enfermeiro foi criado'), writeln('tem a funcao de resgatar a informacao ao longo de sua trajetoria'), writeln(' '), Soma := 0, move(self,enfermagem), //Passo 1 - Entra na enfermagem. out(history).pacientes(#x), //Passo 2 - Acessa a historia do ente enfermagem e obtem o n. de pacientes atendidos de forma bloqueante. move(self,out), //Passo 3 - Sai da enfermagem. Soma := Soma + X, //Passo 4 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,cirurgia), //Passo 5 - Entra na cirurgia. out(history).pacientes(#x), //Passo 6 - Acessa a historia do ente cirurgia e obtem o n. de pacientes atendidos de forma bloqueante. move(self,out), //Passo 7 - Sai da cirurgia. Soma := Soma + X, //Passo 8 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,ginecologia), //Passo 9 - Entra na ginecologia. out(history).pacientes(#x), //Passo 10 - Acessa a historia do ente ginecologia e obtem o n. de pacientes atendidos de forma bloqueante. move(self,out), //Passo 11 - Sai da ginecologia. Soma := Soma + X, //Passo 12 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma.

85 83 move(self,pediatria), //Passo 13 - Entra na pediatria. out(history).pacientes(#x), //Passo 14 - Acessa a historia do ente pediatria e obtem o n. de pacientes atendidos de forma bloqueante. move(self,out), //Passo 15 - Sai da pediatria. Soma := Soma + X, //Passo 16 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,endoscopia), //Passo 17 - Entra na endoscopia. out(history).pacientes(#x), //Passo 18 - Acessa a historia do ente endoscopia e obtem o n. de pacientes atendidos de forma bloqueante. move(self,out), //Passo 19 - Sai da endoscopia. Soma := Soma + X, //Passo 20 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,pre_natal), //Passo 21 - Entra no pre_natal. out(history).pacientes(#x), //Passo 22 - Acessa a historia do ente pre_natal e obtem o n.de pacientes atendidos. move(self,out), //Passo 23 - Sai do pre_natal. Soma := Soma + X, //Passo 24 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,uti), //Passo 25 - Entra na uti. out(history).pacientes(#x), //Passo 26 - Acessa a historia do ente uti e obtem o numero de pac. atendidos de forma bloqueante. move(self,out), //Passo 27 - Sai da uti. Soma := Soma + X, //Passo 28 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,clinica_medica), //Passo 29 - Entra na clinica_medica. out(history).pacientes(#x), //Passo 30 - Acessa a historia do ente clinica_medica e obtem o n. de pac. atendidos. move(self,out), //Passo 31 - Sai da clinica_medica. Soma := Soma + X, //Passo 32 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,fisiatria), //Passo 33 - Entra na fisiatria. out(history).pacientes(#x), //Passo 34 - Acessa a historia do ente fisiatria e obtem o n. de pacientes atendidos. move(self,out), //Passo 35 - Sai da fisiatria. Soma := Soma + X, //Passo 36 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,espirometria), //Passo 37 - Entra na espirometria. out(history).pacientes(#x), //Passo 38 - Acessa a historia do ente espirometria e obtem o n. de pacientes atendidos. move(self,out), //Passo 39 - Sai da espirometria. Soma := Soma + X, //Passo 40 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. move(self,oncologia), //Passo 41 - Entra na oncologia. out(history).pacientes(#x), //Passo 42 - Acessa a historia do ente oncologia e obtem o n. de pacientes atendidos. move(self,out), //Passo 43 - Sai da oncologia. Soma := Soma + X, //Passo 44 - Adiciona o numero de pacientes atendidos e acumula em uma variavel soma. writeln('enfermeiro obteve a soma de ', Soma,' pacientes em todo o seu percurso'),

86 84 writeln(' '), writeln('enfermeiro: Termino da movimentacao.'), out(history)!enf_saiu //informa que o ente enfermeiro saiu } } RESULTADO Figura Resultado da simulação do ente móvel enfermeiro

87 85 ENFERMEIRO O programa é composto por onze Entes Estáticos: Enfermagem, Cirurgia, Ginecologia, Pediatria, Endoscopia, Pré-Natal, UTI, Clínica Médica, Fisiatria, Espirometria e Oncologia.. O Ente Dinâmico D-HOLO, cria automaticamente para o Ente Holo, onze setores e um ente móvel Enfermeiro. Logo após aguarda os dados a serem colocados na história. Os setores notificam sua criação e aguardam a movimentação do Ente Enfermeiro. Este entra em cada setor e conta o número de pacientes que estão internados, sai do setor e insere o resultado na história do D-HOLO. Os passos são executados para cada setor. A figura 5.5 mostra todos os passos do Enfermeiro dentro do hospital. O Enfermeiro é responsável pelo controle de sua mobilidade. Os passos 2, 6, 14, 18, 22, 265, 30, 34, 38 e 42 do Enfermeiro utilizam o acesso a história externa que é realizado pela ação mining.

88 86 Figura 5.5- Passos da movimentação do ente enfermeiro

89 Simulação do ente móvel paciente /********************************************************** NOME: Paciente.holo DATA: 07/11/02. RESPONSAVEIS: Eduardo Moller e Sandra Kunde. FUNCAO: Simulacao de mobilidade do ente paciente. SAIDA: Mensagens na tela mostrando os resultados da simulacao e, em especial, a soma do total de consultas durante o seu deslocamento. OBSERVACOES: 1) cria 12 setores, um paciente e um ente gerenciador; 2) o ente movel gerenciador entra em cada setor e insere na historia do Holo o numero de consultas e entradas de cada setor; 3) o ente movel paciente entra em cada setor e resgata o dado informado pelo gerenciador; 4) o resultado consiste em dois somatorio do numero de consultas e do numero de entradas nos setores. **********************************************************************/ //******************* ENTE PRINCIPAL ******************************** holo() { holo() { writeln('holo: Vou criar doze setores e um paciente'), clone(setor(clinica),clinica), //cria o primeiro setor. clone(setor(oncologia),oncologia), //cria o segundo setor. clone(setor(cirurgia),cirurgia), //cria o terceiro setor. clone(setor(ginecologia),ginecologia), //cria o quarto setor. clone(setor(pediatria),pediatria), //cria o quinto setor. clone(setor(endoscopia),endoscopia), //cria o sexto setor. clone(setor(pre_natal),pre_natal), //cria o setimo setor. clone(setor(uti),uti), //cria o oitavo setor. clone(setor(imagem),imagem), //cria o nono setor. clone(setor(fisiatria),fisiatria), //cria o decimo setor. clone(setor(espirometria),espirometria), //cria o decimo primeiro setor. clone(setor(radiologia),radiologia), //cria o decimo segundo setor. clone(gerenciador,gerenciador_d), //cria o ente gerenciador. history#geren_saiu, //adiciona a história do ente Holo a informacao. clone(paciente,paciente_d), //Cria o ente paciente. time(inicio), //marca o inicio do tempo do percurso do ente paciente. history.pacien_saiu, //o ente paciente adiciona a historia do Holo a informacao que ele saiu. time(fim), writeln('holo: Terminou o deslocamento. Tempo = ',(Fim-Inicio), ' milisegundos.') }

90 88 } //************************** ENTE SETOR ****************************** setor() { setor(ident) { writeln('setor ',Ident,': Fui criada') } } //******************** ENTE GERENCIADOR *************************** gerenciador() { gerenciador() { writeln('gerenciador foi criado'), writeln('ele tem a funcao de inserir o numero de consultas em cada setor'), writeln(' '), move(self,clinica), //Passo 1 - Entra na clinica. out(history)!consultas(2), //Passo 2 - Insere na historia do ente clinica o numero de consultas. move(self,out), //Passo 3 - Sai da clinica. move(self,oncologia), //Passo 4 - Entra na oncologia. out(history)!consultas(3), //Passo 5 - Insere na historia do ente oncologia o numero de consultas. move(self,out), //Passo 6 - Sai da oncologia. move(self,cirurgia), //Passo 7 - Entra na cirurgia. out(history)!entradas(5), //Passo 8 - Insere na historia do ente cirurgia o numero de entradas. move(self,out), //Passo 9 - Sai da cirurgia. move(self,ginecologia), //Passo 10 - Entra na ginecologia. out(history)!consultas(4), //Passo 11 - Insere na historia do ente ginecologia o numero de consultas. move(self,out), //Passo 12 - Sai da ginecologia. move(self,pediatria), //Passo 13 - Entra na pediatria. out(history)!consultas(5), //Passo 14 - Insere na historia do ente pediatria o numero de consultas. move(self,out), //Passo 15 - Sai da pediatria. move(self,endoscopia), //Passo 16 - Entra na endoscopia. out(history)!consultas(1), //Passo 17 - Insere na historia do ente endoscopia o numero de consultas. move(self,out), //Passo 18 - Sai da endoscopia. move(self,pre_natal), //Passo 19 - Entra no Pre_natal. out(history)!consultas(3), //Passo 20 - Insere na historia do ente pre_natal o numero de consultas. move(self,out), //Passo 21 - Sai do pre-natal. move(self,uti), //Passo 22 - Entra na uti. out(history)!entradas(1), //Passo 23 - Insere na historia do ente uti o numero de entradas.

91 89 move(self,out), //Passo 24 - Sai da uti. move(self,imagem), //Passo 25 - Entra na imagem. out(history)!entradas(3), //Passo 26 - Insere na historia do ente imagem o numero de entradas. move(self,out), //Passo 27 - Sai da imagem. move(self,fisiatria), //Passo 28 - Entra na fisiatria. out(history)!consultas(1), //Passo 29 - Insere na historia do ente fisiatria o numero de consultas. move(self,out), //Passo 30 - Sai da fisiatria. move(self,espirometria), //Passo 31 - Entra na espirometria. out(history)!consultas(3), //Passo 32 - Insere na historia do ente espirometria o numero de consultas. move(self,out), //Passo 33 - Sai da espirometria. move(self,radiologia), //Passo 34 - Entra na radiologia. out(history)!entradas(1), //Passo 35 - Insere na historia do ente radiologia o numero de entradas. move(self,out), //Passo 36 - Sai da radiologia. writeln('gerenciador: Termino da movimentacao.'), out(history)!geren_saiu //informa que o ente gerenciador saiu do Holo. } } //*********************** ENTE PACIENTE ***************************** paciente() { paciente() { writeln('paciente foi criado'), writeln('tem a funcao de resgatar a informacao ao longo de sua trajetoria'), writeln(' '), Soma := 0, Ent := 0, move(self,clinica), //Passo 1 Entra na clinica. out(history).consultas(#x), //Passo 2 Acessa a historia do ente clinica e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 3 Sai da clinica. Soma := Soma + X, //Passo 4 Adiciona o numero de consultas e acumula em uma variavel soma. move(self,oncologia), //Passo 5 - Entra na oncologia. out(history).consultas(#x), //Passo 6 - Acessa a historia do ente oncologia e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 7 - Sai da oncologia. Soma := Soma + X, //Passo 8 - Adiciona o numero de consultas e acumula em uma variavel soma. move(self,cirurgia), //Passo 9 - Entra na cirurgia. out(history).entradas(#y), //Passo 10 - Acessa a historia do ente cirurgia e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 11 - Sai da cirurgia. Ent := Ent + Y, //Passo 12 - Adiciona o numero de consultas e acumula em uma variavel soma.

92 90 move(self,ginecologia), //Passo 13 - Entra na ginecologia. out(history).consultas(#x), //Passo 14 - Acessa a historia do ente ginecologia e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 15 - Sai da ginecologia. Soma := Soma + X, //Passo 16 - Adiciona o numero de consultas e acumula em uma variavel soma. move(self,pediatria), //Passo 17 - Entra na pediatria. out(history).consultas(#x), //Passo 18 - Acessa a historia do ente pediatria e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 19 - Sai do ente pediatria. Soma := Soma + X, //Passo 20 - Adiciona o numero de consultas e acumula em uma variavel soma. move(self,endoscopia), //Passo 21 - Entra na endoscopia. out(history).consultas(#x), //Passo 22 - Acessa a historia do ente endoscopia e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 23 - Sai do ente endoscopia. Soma := Soma + X, //Passo 24 - Adiciona o numero de consultas e acumula em uma variavel soma. move(self,pre_natal), //Passo 25 - Entra no pre_natal. out(history).consultas(#x), //Passo 26 - Acessa a historia do ente pre_natal e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 27 - Sai do ente pre_natal. Soma := Soma + X, //Passo 28 - Adiciona o numero de consultas e acumula em uma variavel soma. move(self,uti), //Passo 29 - Entra na uti. out(history).entradas(#y), //Passo 30 - Acessa a historia do ente uti e obtem o munero de entradas de forma bloqueante. move(self,out), //Passo 31 - Sai do ente uti. Ent := Ent + Y, //Passo 32 - Adiciona o numero de entradas e acumula em uma variavel Ent. move(self,imagem), //Passo 33 - Entra no ente imagem. out(history).entradas(#y), //Passo 34 - Acessa a historia do ente imagem e obtem o numero de entradas de forma bloqueante. move(self,out), //Passo 35 - Sai do ente imagem. Ent := Ent + X, //Passo 36 - Adiciona o numero de entradas e acumula em uma variavel Ent. move(self,fisiatria), //Passo 37 - Entra no ente fisiatria. out(history).consultas(#x), //Passo 38 - Acessa a historia do ente fisiatria e obtem o numero de consultas de forma floqueante. move(self,out), //Passo 39 - Sai do ente fisiatria. Soma := Soma + X, //Passo 40 - Adiciona o numero de consultas e acumula em uma variavel Soma. move(self,espirometria), //Passo 41 - Entra no ente espirometria. out(history).consultas(#x), //Passo 42 - Acessa a historia do ente espirometria e obtem o numero de consultas de forma bloqueante. move(self,out), //Passo 43 - Sai do ente espirometria. Soma := Soma + X, //Passo 44 - Adiciona o numero de consultas e acumula em uma variavel Soma. move(self,radiologia), //Passo 45 - Entra no ente radiologia.

93 91 out(history).entradas(#y), //Passo 46 - Acessa a historia do ente radiologia e obtem o numero de entradas de forma bloqueante. move(self,out), //Passo 47 - Sai do ente radiologia. Ent := Ent + Y, //Passo 48 - Adiciona o numero de entradas e acumula em uma variavel Ent. writeln('paciente obteve a soma de ', Soma,' consultas em todos setores durante o percurso'), writeln('paciente obteve a soma de ',Ent,' entradas em todos os setores durante o percurso'), writeln(' '), writeln('paciente: Termino da movimentacao.'), out(history)!pacien_saiu //informa que o ente paciente saiu. } } RESULTADO Figura Resultado da simulação do ente móvel paciente

94 92 PACIENTE O programa é composto por doze Entes Estáticos: Clínica Médica, Oncologia, Cirurgia, Ginecologia, Pediatria, Endoscopia, Pré-Natal, UTI, Imagem, Fisiatria, Espirometria e Radiologia. O Ente Dinâmico D-HOLO cria doze setores e um Ente Móvel Paciente e a seguir aguarda os resultados a serem colocados na história pelo ente gerenciador. Os doze setores notificam sua criação e aguradam os dados e a movimentação do Paciente. O paciente entra em um setor para a realização de consultas ou outro procedimento, realiza o processamento de dados, ou seja, conta o número de consultas e o número de entradas tais como: o número de entradas na Cirurgia, Radiologia e Imagem. No momento de sua saída insere o resultado na história do D-HOLO. Estes passos são executados para cada um. A figura 5.7 mostra os quarenta e oito passos do paciente. O Ente Paciente é responsável pelo controle de sua mobilidade. Os passos 2, 6, 14, 18, 22, 26, 30, 34, 38, 42 e 46 do paciente estão utilizando o acesso a história externa.

95 93 Figura 5.7- Passos da movimentação do ente paciente