CONSTRUÇÃO DE UMA APLICAÇÃO DE BANCO DE DADOS USANDO XML E ASP PROF. CELSO MASSAKI HIRATA (PQ) JULIANA DE MELO BEZERRA (IC) O presente trabalho foca o estudo e a construção de uma aplicação de banco de dados usando uma linguagem emergente chamada XML (extensible Markup Language) e outras tecnologias, como SQL, COM+, Visual Basic (VB) e ASP. A XML é uma linguagem de marcação, assim como a HTML, porém seu objetivo reside em descrever dados salientando sua estrutura. Médicos, pacientes e laboratórios na área de ginecologia compõem o sistema desenvolvido e interagem dentro dele. Ao médico confere-se o acesso à ficha completa dos seus pacientes, podendo ele requisitar novos exames, solicitar medicamentos, ver anotações de outros médicos que já atenderam sua paciente e ainda observar resultados de exames anteriormente feitos pela mesma. Assim o médico pode acompanhar o histórico da paciente e diagnosticá-la com maior precisão. No próprio sistema, a paciente pode escolher em qual laboratório pretende realizar seu exame e este recebe a notificação da escolha para posteriormente entrar em contato com a paciente e marcar o horário de atendimento. Projetou-se o sistema como uma aplicação em três camadas, assim alguns passos bem definidos foram cumpridos. O primeiro passo englobou a escolha do sistema e suas funcionalidades. O segundo, a definição e construção das tabelas de banco de dados no SQL Server 7.0 e de stored procedures em SQL que implementam as funcionalidades especificadas no primeiro passo. Ao terceiro passo atribuiu-se o desenvolvimento de toda camada de regras de negócio usando VB. E, por último, o estudo do ASP associado ao XML e XSL. The current project focuses on the study and the construction of a database application using the XML (extensible Markup Language) and other technologies: SQL, COM+, Visual Basic (VB) e ASP. The XML is a markup language like the HTML, but its objective is to describe data by emphasying to data structure. Doctors, patients, and laboratories in gynecologic area form the system. The doctor can access the patient s card, and can later request new exams and medication, see the notes of other doctors who already served his patient, and access the results of exams that these other doctors demanded. On this way, the doctor can follow patient history and diagnose her with more precision. In the system, the patient can choose the laboratory where she will take the exam and the laboratory receives the ask for call the patient and schedule an appointment. The system was design as a three layers application, and some steps are followed for this. The first one was to choose the system and its functions. The second step was to define and develop the database tables in SQL Serve 7.0 and the stored procedures using SQL that implements functions from the first step. The development of the Business Service layer takes place in the third step, using VB. At the last step, the study of ASP associated to XML and XSL was undertaken.
1. O CONTEXTO DO SISTEMA Existem alguns inconvenientes enfrentados pelas pessoas ao fazer seu acompanhamento médico, são eles: guardar seus exames anteriores e mudar de médico. Guardar exames é necessário para que o médico possa acompanhar a evolução de um problema detectado ou a situação do organismo. Caso o médico não tenha acesso aos exames anteriores aumentará a complexidade de uma decisão de tratamento, pois ele irá encarar o problema do paciente como novo e passar vários exames de modo a embasar o diagnóstico. Entretanto, tomar o problema como novo é ineficiente, já que o mesmo tem um passado a ser levado em consideração. Comumente se muda de médico. Pelo serviço público de saúde, o paciente às vezes não pode escolher qual médico deseja ir e acaba realizando sua consulta com um médico diferente do que lhe atendeu anteriormente. As pessoas que têm plano de saúde também sentem o problema de mudar de médico quando trocam de plano, caso o novo plano não possua convênio com os especialistas utilizados anteriormente. O inconveniente da mudança reside em ter que explicar ao novo médico qual seu problema, os exames antes realizados, os medicamentos tomados e as recomendações recebidas. Seria mais fácil se o médico sempre possuísse acesso aos dados históricos da paciente para poder diagnosticar melhor. 2. O SISTEMA PROPOSTO Neste trabalho relata-se a implementação do protótipo de um sistema voltado ao atendimento de pacientes na área da Ginecologia. Tal escolha reside no fato das mulheres possuírem acompanhamento ginecológico durante toda sua vida, a partir de aproximadamente treze anos de idade, estando, então, expostas aos dois inconvenientes básicos: guardar exames anteriores e mudar de médico. O ideal é o ginecologista estar ciente das alterações que por ventura ocorram em sua paciente e conseguir observar adequadamente o andamento destas alterações. Daí a necessidade de disponibilizar o histórico da mulher, com observações, exames e medicações feitas. Por outro lado, há remédios que causam complicações a certas pacientes e se, o médico dispuser desta informação, não irá receitar o mesmo remédio novamente. O sistema proposto consiste na interação entre paciente, médico e laboratório que realiza os exames. Um banco de dados gerencia as informações sobre os pacientes, os médico e os laboratórios; e a cada um dos três é oferecida uma interface diferente tendo em vista o atendimento de suas necessidades específicas. As principais funcionalidades que cada um deles poderá ralizar são: a) Paciente: acessar seus exames já realizados e as observações emitidas pelos médicos que lhe acompanharam, escolher em qual laboratório deseja realizar os exames requisitados e ver as instruções de seu médico quanto à utilização de um dado medicamento. b) Médico: ver a ficha de seus pacientes e seus exames antigos, requisitar novos exames, inserir novas observações sobre um determinado paciente, além de receitar os remédios a serem tomados. c) Laboratório: tem acesso aos exames que foram designados pelo médico e inserir os resultados no próprio sistema.
Editar dados Requisitar novo exame Ver exames anteriores Inserir observação Ver observações do médico paciente Ver exames requisitados Escolher o laboratório onde fará o exame Solicitar novo medicamento médico laboratório Ver médicos cadastrados Ver pacientes cadastradas Ver laboratórios cadastrados Ver exames a fazer Figura 1: Use cases do sistema 3. TECNOLOGIAS UTILIZADAS NO SISTEMA Entre as tecnologias empregadas no desenvolvimento do sistema estão: SQL: Usa-se a linguagem SQL (Structured Query Language) para se estabelecer uma interação com um banco de dados, sendo definida, pela ANSI (American National Standards Institute), como linguagem padrão de sistemas de gerência de banco de dados relacionais. Alguns dos sistemas de gerência de banco de dados relacionais mais utilizados são: Oracle, Sybase, Microsoft SQL Server, Access e Ingres. No presente projeto, optou-se pelo Microsoft SQL Server, o qual dispõe de recursos como stored procedures: funções em SQL que lidam diretamente com os dados mantidos no banco de dados. [17][18] COM+: Foi desenvolvido com a finalidade de simplificar a criação e o uso de componentes de software. COM+ provê runtime e serviços já usados por qualquer linguagem ou ferramenta de programação, além disso, permite interoperabilidade entre componentes sem se preocupar com como estes foram implementados. Alguns dos objetivos do COM+: Tornar-se simples para construção de componentes; Tratar questões chaves no desenvolvimento de aplicações; Prover novos serviços para os desenvolvedores; Prover um mecanismo de extensão de padrão para incorporar inovações. [12,13] Visual Basic: A Microsoft baseou o Visual Basic (VB) em uma linguagem de programação chamada BASIC (Beginner s All-purpose Symbolic Code). O BASIC é estritamente uma linguagem baseada em texto. Tanto o seu programa como sua saída são textuais e não produzem saídas gráficas em janelas como os programas atuais. Houve uma longa evolução desta linguagem até chegar no VB, que é gráfico e bastante simples de usar. O VB tornou-se bastante popular, porque pode ser utilizado tanto interpretado
quanto compilado. Pode-se testar um programa em VB executando-o de forma interpretada até eliminar todos seus bugs. Uma vez eliminado os bugs e depois de ter testado completamente o programa, o desenvolvedor pode então compilá-lo em um programa executável rápido e seguro que pode ser distribuído para outras pessoas utilizarem. [5][15] ASP: Active Server Pages (ASPs) são páginas Web que contêm server-side scripts em adição à mistura usual de texto e tags HTML (Hipertext Markup Language). Define-se server-side scripts como comandos especiais colocados nas páginas Web e processados no próprio servidor Web antes das páginas serem enviadas para o browser Web da pessoa que requisitou tais páginas. No sistema proposto, usamos o IIS (Internet Information Server) como servidor Web. XML: Significa extensible Markup Language, suas aplicações classificam-se em dois tipos: de documentos e de dados. A vantagem principal da XML em aplicações de documentos é que ela se concentra na estrutura do documento e o torna independente do meio de distribuição. Assim possibilita editar e manter documentos em XML e publicá-los automaticamente em diferentes meios com auxilio da XSL (XML Stylesheet Language). Como aplicações de dados, a XML pode ser usada na troca de dados. Sistemas computacionais e banco de dados contêm dados em formatos incompatíveis, e um desafio para os desenvolvedores habita na troca desses dados entre sistemas pela internet. Convertendo os dados para XML, reduz-se a complexidade, criando-se dados que podem ser lidos por diferentes tipos de aplicação. [3][6] 4. A IMPLEMENTAÇÃO DO SISTEMA O sistema foi desenvolvido como uma aplicação em três camadas, que consiste em duas aplicações cliente/servidor encadeadas. Existem três camadas porque são três partes envolvidas. Cada camada recebe um nome em especial, são elas: camada de dados (Data Services), camada de regras de negócio (Business Services) e camada de interface (User Services).[1] Camada de interface Cliente Camada de regras de negocio Camada de dados Banco de dados Figura 2: Esquema de uma aplicação em três camadas A camada de dados acessa diretamente o banco de dados Microsoft SQL Server 7.0, sendo, no sistema desenvolvido, representada pelas stored procedures em SQL. Um exemplo simples da criação de uma procedure utilizada para resgatar todas informações dos médicos cadastrados, é apresentada a seguir: CREATE PROCEDURE VERMEDICOS AS BEGIN SELECT * FROM MEDICOS END
A camada de regras de negócio contém os objetos que representam regras ou lógica do fluxo de operações que se deseja automatizar. Estes objetos, implementados em VB, recorrem aos da camada de dados quando desejam acessar o banco de dados e são gerenciados pela tecnologia COM+. Embora o Visual Basic não seja uma linguagem orientada a objetos, utilizou-se uma maneira alternativa para tornála orientada objetos, que consiste em implementar funções representando construtores e funções representando métodos de acesso às variáveis. Segue o exemplo de uma função destinada ao resgate de todos dados sobre os médicos: Public Function VerMedicos() As Collection On Error GoTo TRAP Dim CONNECTION As New CONNECTION Dim COMMAND As New COMMAND CONNECTION.ConnectionString = AUXCONNECTION CONNECTION.CommandTimeout = 0 CONNECTION.Open COMMAND.ActiveConnection = CONNECTION COMMAND.CommandText = "VERMEDICOS" COMMAND.CommandType = adcmdstoredproc Dim Recordset As New Recordset Set Recordset = COMMAND.Execute() If Recordset.EOF Then Call Err.Raise(1, "Não foi encontrado nenhum registro") End If Dim col As New Collection Dim med As New medico Do While Not Recordset.EOF Call med.newmedico(recordset("idmedico"), Recordset("NOME"), Recordset("ENDERECO"), Recordset("TELEFONE")) col.add med Set med = Nothing Recordset.MoveNext Loop Recordset.Close CONNECTION.Close Set VerMedicos = col Exit Function TRAP: Set VerMedicos = Nothing End Function A camada de interface contém os objetos (como formulários) sob a perspectiva do cliente, é conhecida como camada de apresentação porque nela se realiza a interface com o usuário final. As partes das telas do sistema, como barra de menu, foram desenvolvidas em HTML. Inseriu-se código ASP para processar as informações desejadas, chamando as funções dos objetos em VB. Nos casos onde há exposição dos dados na telas, como uma lista de exames ou de medicamentos, o ASP monta um documento XML cuja formatação é dada por uma folha de estilo XSL associada. Figura 3: Tela inicial da paciente e página com medicamentos a ela requisitados
5. CONCLUSÃO O desenvolvimento deste projeto permitiu uma visão total de uma aplicação voltada para internet, desde sua concepção até o objetivo final, que é obter um site funcionando. Percebeu-se a importância de um sistema em três camadas tanto para organização do código quanto para sua otimização. Em cada camada, as descobertas foram surpreendentes, proporcionando um aprendizado intenso de várias tecnologias. A maior dificuldade encontrada foi o aprendizado dos ambientes ainda desconhecidos, como o SQL Server 7.0 e o Visual Studio 6.0. Estudou-se o ambiente Microsoft SQL Server 7.0 no qual se emprega a linguagem SQL, objetivando construir as tabelas do banco de dados e procedimentos necessários para manipular seus dados. A importância do Visual Studio 6.0 foi observada no desenvolvimento de componentes em VB da camada de regras de negócio para prover uma maior divisão entre as camadas do sistema. Como conseqüência, houve um foco na pesquisa sobre a tecnologia COM+ e na própria manipulação da linguagem VB. No desenvolvimento da camada de interface, empregou-se ASP e XML. Assim pode se perceber a importância do ASP no processamento de informações de sistemas cliente/servidor e como é fácil se trabalhar com XML, permitindo uma excelente separação entre layout dos dados e os dados propriamente ditos, já que este layout pode ser atribuído pela aplicação de folhas de estilo XSL. AGRADECIMENTOS A Deus que me deu esta oportunidade de aprendizado e crescimento. E à minha família, que mesmo distante, conforta-me a todo momento. REFERÊNCIAS BIBLIOGRÁFICAS [1] Wilson, Mark; Wilson, Tracey. XML Programação com VB e ASP. Rio de Janeiro: Ciência Moderna Ltda., 2001 (Trad. de XML Programming with VB and ASP); [2] McGrath, Sean. XML Aplicações Práticas, Como desenvolver aplicações de comércio eletrônico. Rio de Janeiro: Campus, 1999 (Trad. de XML by Example, por V.H.P Alves); [3] Marchal, Benoît. XML Conceitos e Aplicações. São Paulo: Berkey, 2000 (Trad. por Daniel Vieira); [4] Mitchell, Scott; Atkinson, James. Aprenda em 21 dias ASP Active Server Pages 3.0. Rio de Janeiro: Campus, 2000 (Trad. por E. Furmankiewicz e J. Figueiredo); [5] Perry, Greg. Aprenda em 21 dias Visual Basic 6. Rio de Janeiro: Editora Campus Ltda., 1999 (Trad. de Teach Tourself Visual Basic 6 in 21 Daysi, por Edson Furmankiewicz) [6] http://xml101.com [7] http://lists.xml.org/archives/xml-dev/200106/msg01040.html [8] http://www.w3schools.com/xml/default.asp [9] http://www.ibiblio.org/xml/books/bible2/chapters/ch17.html [10] http://www.microsoft.com/com/tech/com.asp [11]http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnguion/html/msdn_drguion020298.asp [12] http://www.microsoft.com/com/tech/complus.asp [13] http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm&nav= /msj/1197/newnav.htm [14] http://msdn.microsoft.com/vbasic/productinfo/previous/vb6/articles/aspsecurity/ default.asp [15] http://www.progsys.com/whyvb.htm [16] http://www.asptutorial.info/ [17] http://www.sqlcourse.com/ [18] http://www.w3schools.com/sql/sql_intro.asp
INSTITUTO TECNOLÓGICO DE AERONÁUTICA INTEGRAÇÃO DE UM AMBIENTE COOPERATIVO DE SIMULAÇÃO Tony Calleri França IC (tony@h8.ita.br) Celso Massaki Hirata Prof. Dr. PQ Instituto Tecnológico de Aeronáutica Divisão de Ciência da Computação Praça Mal. Eduardo Gomes, n o 50, Vila das Acácias CEP: 12228-900, São José dos Campos SP Resumo: O processo de simulação discreta compreende três passos: o estudo do sistema real a ser simulado e sua modelagem, a implementação do modelo obtido usando um ambiente de programação visual ou uma linguagem de programação e a execução da simulação seguida da obtenção e análise de resultados. Em geral, no processo de simulação colaboram diversos participantes com especialidades variadas, desde o cliente até o programador. Para que o processo seja eficiente, são necessárias interações entre eles. Contudo, os participantes, em geral, se localizam geograficamente distribuídos, ocasionando, assim, grandes custos para a realização de reuniões. Neste trabalho apresenta-se um ambiente de simulação que permite a colaboração entre os diversos participantes de um projeto por meio de uma rede. Para tanto, foi utilizada a linguagem Java, que possui mecanismos simples de programação distribuída (RMI) e é independente de plataforma. O ambiente apresentado, denominado GroupSim (Groupware para Simulação), não permite apenas a especificação do modelo, mas também sua execução e a geração dos relatórios associados. Para permitir a execução da simulação a partir da especificação produzida, define-se uma linguagem de modelagem baseada em ACD (Activity Cycle Diagram - uma linguagem visual de modelagem de sistemas discretos para simulação), por este ser de grande disseminação na comunidade de simulação. Esta linguagem é mapeada para um conjunto de classes orientado a objetos, que são utilizadas para construir automaticamente um programa de simulação, permitindo eliminar completamente a tarefa de programação. Abstract: The process of a discrete event simulation includes three distinct tasks: the study of the real-world system and its modelling, the implementation of the model using a visual programming environment or a programming language and the execution of the simulation followed by report generation. In general, several participants cooperate during the simulation process, each within his speciality, from the client to the programmer. In order to be efficient, the project involves many interactions between them, which result in high costs, since the participants are often geographically distributed. In this work a simulation environment that allows the cooperation between the participants using a computer network, is presented. Due to its portability and its simple parallel-programming tool (RMI), the Java programming language was used. The proposed environment, named GroupSim (Groupware for Simulation), supports both the model specification and model execution. In order to allow the simulation execution from the specification, a model specification language based on the ACD (Activity Cycle Diagram a visual language to model discrete systems for simulation) was defined. This language specification can be mapped onto an object-oriented framework and be used to automatically build a simulation program, eliminating the programming task.
1. INTRODUÇÃO 1.1. Objetivos Os objetivos gerais desse trabalho de iniciação científica consistem em transformar a ferramenta desenvolvida até então num produto final e permitir a interoperabilidade dos modelos construídos pela ferramenta. Para o cumprimento do primeiro objetivo, deve-se proceder a um estudo do campo da Engenharia de Software, onde as tarefas principais são: Levantar as funcionalidades adicionais que o usuário precisa para usar satisfatoriamente a ferramenta de simulação. Especificar os novos requisitos do programa. Projetar e implementar, segundo as diretrizes da Orientação a Objeto, os novos requisitos. Para satisfazer o segundo objetivo, devemos tornar possível que, a partir de uma simulação feita com o auxílio da ferramenta, fosse gerado automaticamente uma descrição do modelo que possa ser salva num padrão XML ainda a ser definido. O uso de XML se justifica por permitir a definição de qualquer estrutura de informações. O XML é hoje um padrão para representar dados estruturados. Os objetivos dessa funcionalidade são: Permitir a troca de modelos entre usuários e não usuários do sistema. Suportar a troca de informação com outros sistemas através da troca de arquivos XML. 2. FUNDAMENTAÇÃO TEÓRICA 2.1 Simulação Simulação computacional é uma técnica para imitar operações do mundo real através de modelos. Um modelo é uma representação apropriada de estruturas e processos em um mundo restrito. Um modelo precisa ser alimentado com dados da realidade quando pretende imitar um sistema físico já existente. Procede-se à codificação do modelo em um programa de computador que o interprete corretamente. A verificação do programa busca determinar se o programa implementado corresponde à especificação do modelo. A experimentação é a razão da construção de um modelo de simulação. Deve-se determinar o número de experimentos e como devem ser feitos. Os dados obtidos da experimentação são, então, analisados. Desta forma, existem diferentes paradigmas de modelagem. O paradigma focado neste trabalho é o chamado da simulação discreta. 2.3 Diagramas de Ciclo de Atividades O diagrama de ciclo de atividades (ACD) é uma ferramenta de modelagem bastante útil para se descrever sistemas segundo o paradigma da simulação discreta, especialmente aqueles baseados em filas. Neste tipo de diagrama, descreve-se o comportamento de cada tipo de entidade como um ciclo composto de estados conectados por arcos. A evolução da simulação se caracteriza pelo movimento das diversas entidades através desses estados. São dois os tipos de estados: ativos e mortos. Nos estados ativos adentram diferentes tipos de entidades para a realização de algum processamento. O tempo de permanência dessas entidades em um determinado estado ativo é conhecido a partir do momento em que o processamento se inicia. Nos estados mortos as entidades de um dado tipo aguardam para entrar em um estado ativo. O tempo de permanência de uma entidade em um estado morto é difícil de ser determinado e geralmente depende do estado do sistema. Um ciclo é formado por estados ativos conectados a estados mortos alternadamente.
A Figura 2.1 mostra um exemplo de um sistema de fila simples. Neste sistema, interagem dois tipos de entidades clientes (customer) e balconista (clerk). Clientes chegam ao sistema através do estado ativo Arrival, dirigem-se para a fila wait e aguardam até que haja um balconista presente em idle para, então, serem servidos no estado ativo Service. Terminado o serviço, os clientes vão para B e os balconistas adentram o estado morto idle. De B, os clientes deixam o sistema. Arrival wait customer B Service clerk Idle Figura 2.1: Exemplo do uso de um ACD para representar um sistema de fila simples. 2.4 A Notação XACDML A proposta básica da XACDML é possibilitar a representação de diagramas de ciclos de atividades, de uma forma padronizada, que possibilite a troca de dados e eventuais transformações entre aplicações de simulação discreta que utilizem ACD. Um ACD representado pela notação XACDML, será representado na notação ACD estendida, com os diagramas sendo compostos por atividades (Act), filas (Dead), geradores (Generate), destruidores (Destroy), roteadores (Router) e submodelos (Model), onde deveremos modelar os eventos, mantendo as premissas originais de forma a existir alternância entre estados ativos e mortos. Sendo XACDML uma aplicação XML, documentos XACDML deverão ser documentos XML bem-formados ou válidos. Um documento XACDML será validado por um DTD (Document Type Definition) ou por um schema XACDML. O DTD constitui uma parte opcional do prólogo de um documento XML, especificando as tags e as seqüências de tags válidas. O DTD pode conter regras internas ou externas, que podem ser definidas em um arquivo, com extensão dtd cuja localização pode ser especificada no prólogo do documento XML. O Apêndice 1 mostra o arquivo xacdml.dtd que valida os arquivos XACDML. 3. ATIVIDADES REALIZADAS Até o presente momento, quase todos os objetivos referentes ao desenvolvimento de uma ferramenta mais robusta para a modelagem e execução em Simulação foram cumpridos incluindo o levantamento dos requisitos. O objetivo a cumprir com relação ao desenvolvimento e que foi parcialmente cumprido é a tarefa de testes. 3.1 Requisitos Os requisitos levantados foram: Eliminar os erros presentes no sistema. Gerar uma documentação do projeto. Tornar a interface mais intuitiva, com um layout mais bonito e configurável.
Implementar uma política de segurança para o sistema, através do uso de Login/Senha, uma vez que todo sistema que funciona pela Internet é teoricamente acessível a partir de qualquer outra máquina. Permitir que o servidor comportasse mais de uma sala de edição. Isso quer dizer que pode haver quatro pessoas (digamos, A, B, C e D) conectadas no servidor de modo que A e B trabalhem em um modelo, e C e D trabalhem em outro modelo, sem que uma dupla saiba o que a outra está fazendo. Adicionar um chat à sala de edição, para que os usuários possam se comunicar durante a edição. Permitir o salvamento do modelo de simulação numa dada especificação XML, denominada XACDML. A seguir vamos ver em detalhes o que foi feito. 3.2 Documentação do projeto Disponível no site: http://www.geocities.com/groupsim2002/doc. Apesar de muito bem projetado no que diz respeito ao paradigma da Orientação a Objetos, o sistema, inicialmente, se encontrava pobremente documentado. Essa questão é essencial do ponto de vista da Engenharia de Software. A má documentação de um software compromete diretamente sua escalabilidade e manutenibilidade. A introdução do padrão JAVADOC nas linhas de comentário permitiu a geração automática da documentação, em formato HTML, e está disponível na Internet. Também foi utilizado a ferramenta Rational Rose, que possibilitou a construção de modelos gráficos do sistema, no padrão UML, e também a geração de uma página HTML contendo tais modelos gráficos, organizados de uma maneira intuitiva e fácil de navegar. Obviamente a documentação, assim como a eliminação dos erros, é um processo que continua indefinidamente durante o processo de desenvolvimento do sistema. A documentação atual está, portanto, sujeita a alterações. 3.3 Interface a) Configurabilidade: Na versão atual, o layout da interface é configurável. Isto é feito de duas formas: 1. Sistema de skins: Os fundos das janelas, todos os botões, os desenhos para cada tipo de estado e etc são figuras comprimidas num diretório específico do programa. Ao substituir esse diretório de figuras por outro, o resultado é uma impressão de uma interface completamente diferente, devido ao aspecto visual. 2. Arquivo de configuração: Cada tela do sistema possui componentes (e.g. um campo de texto) que assumem uma determinada disposição espacial na tela. A idéia é anotar as posições relativas de cada componente num arquivo texto, que é carregado e interpretado durante a execução. Deste modo é possível mudar a posição de um botão alterando o parâmetro correto no arquivo de configuração. A figura 3.1 mostra o ambiente de edição.
Figura 3.1: Interface do Editor de Modelos Cooperativo; versão atual. b) Usabilidade Os usuários interagem com o ambiente de simulação cooperativo através de uma interface gráfica, em que seus elementos correspondem à notação ACD. Além disso, cada tipo de estado aparece usando uma figura diferente. Todos os elementos são colocados sobre uma área de trabalho branca, como se fosse uma folha de rascunho em que os colaboradores editam o ACD representativo do sistema a ser modelado. A seleção do elemento a ser inserido é feita através de uma barra de botões, colocada à esquerda da área de trabalho, denominada Visual Objects Bar (Barra de Objetos Visuais). Feita a seleção, o elemento é posicionado em uma área desocupada da área de trabalho com o uso do mouse. No caso dos arcos, depois de feita a seleção da opção Arc, basta pressionar o botão do mouse (mousedown) sobre o componente de origem, arrastá-lo até o componente de destino e, então, soltar o botão do mouse (mouseup). A conexão só é efetuada se estiver de acordo com a semântica da notação ACD. No caso de uma atividade, para que se possa preservar os caminhos, a seqüência de operações deve ser a seguinte: mousedown em um estado morto de origem, mouseup na atividade, mousedown na atividade, para definir de que ponto se originará o novo arco, mouseup no estado morto de destino. Um menu popup, posicionado na horizontal, acima da área de trabalho, permite o controle da simulação, fornecendo comandos para a geração do programa de simulação, execução da simulação (que requer que o programa já tenha sido gerado), suspensão e retomada da simulação, salvamento e carga do modelo (em formato binário) no disco local, Caso o modo de operação for local, i.e. não cooperativo, ou no sistema de arquivos do host servidor, caso contrário. Para remover um elemento da área de trabalho ou editar suas propriedades, este deve estar selecionado, o que é feito clicando sobre o elemento em questão. O elemento selecionado é identificado por uma mudança na sua cor. Os botões para disparar essas ações encontram-se na barra Object Actions Bar (Barra de Ações sobre Objetos), localizada abaixo da Visual Objects Bar, bem como o botão Globals... (Globais...) para configurar as variáveis globais do modelo. Ao se remover um elemento da área de trabalho, todos os arcos a ele associados são também removidos. Desta forma, mantém-se a consistência do modelo ao longo de todo o processo de edição. Presente em todas as ações do usuário sobre o modelo está o mecanismo de colaboração. Esse mecanismo não é normalmente percebido pelo usuário. Ele irá percebê-lo apenas se ele editar o modelo enquanto outro já o estiver fazendo, ou ao observar a área de trabalho enquanto outro usuário edita o modelo. No primeiro caso, através da falha da ação pretendida, e no segundo, através do aparecimento espontâneo das alterações realizadas.
3.4 Chat Uma funcionalidade indispensável de uma ferramenta desta natureza é a de os cooperadores poderem conversar. Fez-se necessário um chat. Ao entrar no ambiente de edição, o usuário pode clicar no botão Chat, abrindo uma janela de chat convencional. Nesta janela é mostrado um chat comum. Há uma lista de usuários conectados, para os quais pode-se enviar uma mensagem reservada (deixando selecionado um usuário da lista enquanto pressiona o botão send), ou uma mensagem pública (não deixando nenhum usuário da lista selecionado). A opção AutoScroll quando ativada provoca um rolamento automático da barra de rolagem ao chegarem novas mensagens. Ao fechar e abrir novamente a janela de chat, o usuário não perde as mensagens que estavam lá. 3.5 Construção automática do modelo XACDML Uma característica desejável de um sistema desta natureza é a possibilidade de intercomunicação com outros sistemas. Para alcançar esse objetivo, a especificação XACDML foi desenvolvida. A qualquer momento, o usuário pode escolher a opção File -> Save XACDML, criando um arquivo que descreve o modelo no padrão XACDML. Este arquivo é gravado no sistema de arquivos do servidor caso o sistema esteja executando em modo cooperativo. Caso contrário ele é criado no sistema de arquivos local. O Apêndice 2 mostra o código xacdml correspondente ao modelo mostrado na figura 3.1. 4. COMENTÁRIOS E CONCLUSÕES O ambiente cooperativo para desenvolvimento de software de simulação GroupSim foi melhorado, documentado e continua em fase de aprimoramento. O ambiente desenvolvido não permite apenas a especificação do modelo, mas também sua execução. As funcionalidades adicionadas/melhoradas foram: eliminação dos erros, documentação, Interface com o usuário, segurança, múltiplas salas de edição e chat. Neste processo a principal dificuldade encontrada foi no que diz respeito à manutenibilidade do código, devido a uma documentação pobre. Uma limitação da ferramenta é a ausência de suporte a submodelos Isso dificulta a construção de sistemas mais complexos que, eventualmente, poderiam ser facilmente construídos se uma facilidade de composição hierárquica estivesse disponível. Referências bibliográficas [1] PIDD, M. Computer Simulation in Management Science. 3. Ed. John Willey & Sons, England 1992. [2] KREUTZER, W. System simulation: programming styles and languages. Addison-Wesley Publish Co. England, 1986. [3] BACON, J. Concurrent systems: an integrated approach to operating systems, database and distributed systems. Addison-Wesley Publish Co. England, 1992. [4] TANNENBAUM, A. S. Modern Operating Systems. Prentice Hall Inc. New Jersey, 1992. [5] WATKINS, K. Discrete event simulation in C. McGraw-Hill Book Company Europe. England, 1993. [6] ARNOLD, K, GOSLING, J. The Java Programming Language. Addison-Wesley Publishing Company. Massachusets, 1996. [7] FARLEY, J. Java Distributed Computing. O Reilly & Associates, Inc. California, 1998.
[8] DOWNING, T. B. Java RMI: Remote Method Invocation. IDG Books Worldwide, Inc. California, 1998. [9] LEA, D. Concurrent Programming in Java: Design Principles and Patterns. Addison-Wesley Longman, Inc.: Massachusets, 1997. [10] GEARY, D. Graphic Java: Mastering the JFC. Vol. 1: AWT. Ed. 3. Sun Microsystems Press, California, 1999. [11] STROUSTRUP, B. The C++ programming language. 2. ed. New Jersey: Addison-Wesley Publishing Company, 1991. [12] ECKEL, B. C++: guia do usuário. 1. São Paulo: Makron, McGraw-Hill, 1991. [13] APPEL, A. W. Modern Compiler Implementation in C: basic techniques. Cambridge University Press. Cambridge, 1997. [14] ORFALI, R. e HARKEY, D. Client/server programming with Java and CORBA. 2. Ed. John Wiley & Sons, 1998. [15] YANO, E. T. GroupPlaces: Uma arquitetura de groupware para a WWW. (Tese de Doutorado). São Paulo, 1998. [16] AZAMBUJA, L. F. A., KANNO, R. J. Y. Construção de um ambiente para desenvolvimento de simulação discreta. (Trabalho de graduação). São Paulo, 1997. [17] SARJOUGHIAN, H. S., ZEIGLER, B. P. DEVSJAVA: Basis for a DEVS-based Collaborative M&S Environment. Electrical & Computer Engineering Department, University of Arizona, 1999. Disponível: http://www.isima.fr/scs/wbms/d28/wmc98.html. Consultado em 05/01/1999. [18] ELLIS, C. A, GIBBS, S. J., REIN, G. Groupware: Some issue and experience, Comm. ACM, v. 34, n. 4, p. 38-58, jan. 1991. [19] HIRATA, C. M., PAUL, R. J. Object-Oriented Programming Architecture for Simulation Modeling, International Journal in Computer Simulation, v. 6, n. 2, p. 269-287, 1996. [20] HIRATA, C. M. Modelling and Programming Support for Parallel Discrete Event Simulation with Time Warp. (Tese de Doutorado). University of London. Londres, 1995. [21] HIRATA, C. M., YANO, E. T., ARAUJO, W. L. F. A Cooperative Simmulation Modelling Environment based on the WWW. In Proceedings of the 2000 International Conference on Web-Based Modelling & Simmulation, 2000. (aceito para publicação).
SIMULAÇÃO DE UMA DESCARGA DE RF PELO MÉTODO PIC/MCC, COM ARGÔNIO E MERCÚRIO Henrique Silva Pinto 1 (IC), Marisa Roberto 2 (PQ) 1 Divisão de Engenharia Eletrônica, ITA, CTA, 12228-900, São José dos Campos, SP, Brasil e-mail: henrique04@h8.ita.br 2 Divisão de Ensino Fundamental, ITA, CTA, 12228-900, São José dos Campos, SP, Brasil e-mail: marisar@fis.ita.br Resumo O objetivo principal deste trabalho é a simulação por software computacional, através do método PIC/MCC (Particle in Cell / Monte Carlo Collisions) de simulação de partículas, de um plasma a frio, onde se aplicou uma descarga de RF, contendo átomos de argônio e mercúrio, sob certas circunstâncias específicas de temperatura, pressão e tensão aplicada. Os plasmas são muito utilizados em diversos processos industriais, e a simulação deste em computador é uma poderosa ferramenta no estudo e conseqüente evolução destes processos, que ainda não são completamente entendidos pela ciência. Abstract The main objective of this work is the simulation by computational software, with the PIC/MCC particles simulation method, of cold plasma containing argon and mercury atoms. It was applied in an RF discharge, in specific conditions of temperature, pressure and applied voltage. Plasmas are largely utilized in many industrial processes, and its computational simulation is a powerful tool to the study and the evolution of these processes, which are not entirely understood by science. 1 INTRODUÇÃO O plasma fracamente ionizado em misturas gasosas tem sido estudado em vários campos da tecnologia, tais como lâmpadas de descarga, lasers gasosos, plasmas de processamento etc. Misturas de argônio e oxigênio, usando o método de simulação PIC (Particle in Cell), que tem muitas aplicações em processamento de plasmas, têm sido estudados por M. Roberto (1). A modelagem de descargas em misturas gasosas de mercúrio/argônio tem sido útil no entendimento dos parâmetros que influenciam na eficiência das lâmpadas fluorescentes. Uma lâmpada de mercúrio sob alta pressão típica sempre contém um pouco de argônio para facilitar a ignição (2,3). A radiação de ressonância do mercúrio nas linhas de 253.7 e 184.9 nm originada nos níveis 6 3 P 1 e 6 1 P 1 respectivamente, é responsável pela produção luminosa nas lâmpadas fluorescentes. Os níveis 6 3 P 0 e 6 3 P 2 são níveis metaestáveis do mercúrio, que tem grandes tempos de vida. Uma vez formados, as densidades de metaestáveis são geralmente significantes comparadas às dos átomos em estado neutro. Além disso, os átomos metaestáveis têm um importante papel no equilíbrio da ionização nas descargas em gás, por causa da importância dos processos de ionização. A influência da reação entre argônio metaestável (nível 1s 4 ) e átomos de mercúrio é aqui considerada para verificar seu efeito no perfil do argônio metaestável.