1
GERAÇÃO DE SISTEMAS HOSPITALARES EM TEMPO REAL
UTILIZANDO LINHAS DE PRODUTO DE SOFTWARE
Bruno Gomes Araújo12, Ricardo Alexsandro de Medeiros Valentim1, Tulio de Paiva Marques Carvalho13, Robinson Luís de Souza Alves1 e Heliana Bezerra Soares1
1
Programa de Pós-Graduação em Engenharia Elétrica e Computação, Laboratório de Inovação Tecnológica em Saúde do Hospital Universitário Onofre Lopes, Universidade Federal do Rio
Grande do Norte (UFRN), Natal, Brasil
2
Diretoria Acadêmica do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte, Câmpus Santa Cruz (IFRN), Santa Cruz, Brasil
3
Diretoria de Tecnologia da Informação do Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte (IFRN), Natal, Brasil
Resumo: Com o grande volume de informações envolvidas nos sistemas, novas práticas são adotadas para a automatização e simplificação do processo de geração de novos sistemas. É o caso das Linhas de Produto de Software (LPS), responsáveis pela geração de sistemas através da seleção de features. Apesar da facilidade da manipulação de sistemas comuns, os de Tempo Real, amplamente utilizados em ambientes hospitalares, apresentam restrições temporais que devem ser tratadas no momento da criação da Linha de Produto. Neste contexto, o presente trabalho realiza a implementação de uma LPS focada na geração de sistemas de Tempo Real, utilizando como estudo de caso um sistema de monitoramento de pacientes. Foi utilizada a ferramenta Captor, que disponibiliza formulários para o controle das variabilidades do sistema a ser gerado. Com o objetivo de validar a implementação realizada, dois sistemas foram gerados pela ferramenta através da seleção de uma combinação de características disponíveis.
Palavras-chave: Linhas de Produto de Software, Tempo Real, Monitoramento de Pacientes.
Abstract: Given the large volume of information involved in systems, new practices are adopted to automate and simplify the process of generating new systems. This is the case of Software Product Lines (SPL), responsible for generating systems through the selection of features. Despite of the easy manipulation of common systems, the Real-Time system, which is widely used in hospitals, has time constraints that must be dealt at the same moment of the Product Line creation. In this context, this paper shows the implementation of an LPS focused on generating real-time systems using as a case study a patient monitoring system. Captor tool was used, which provides the control forms for the variability of the system to be generated. In order to validate the implementation, two systems were generated from the tool by selecting a combination of features available. Keywords: Software Product Lines, Real Time, Patient Monitoring.
Introdução
Um fator recorrente na sociedade tem sido o aumento do número de informações nos processos de software. Fator este, que tem corroborado no aumento da complexidade no desenvolvimento de sistemas e gerenciamento dos dados. Existe uma variedade muito grande de sistemas, e uma das principais metas na criação de software é o desenvolvimento de alta qualidade, baixo custo e em curto espaço de tempo. Uma prática que vem ganhando destaque no desenvolvimento de sistemas é a reutilização de software, que permite o aproveitamento de conceitos ou produtos previamente adquiridos ou construídos em um novo desenvolvimento5-7. A reutilização facilita e agiliza novos desenvolvimentos e resoluções de problemas. Entre as técnicas utilizadas, estão os frameworks, componentes de software, entre outros. A evolução destas ideias levou a formulação do conceito de Linhas de Produto de Software (LPS), responsável pela produção de uma coleção de produtos pertencentes a uma “família”. O conceito de Família de Sistemas surgiu em virtude de softwares compartilharem um
2
conjunto de características comuns entre si, diferenciando uns dos outros apenas através de características variáveis, conhecidas como variabilidades2-5.
Mas algumas aplicações apresentam um grau maior de complexidade durante o seu desenvolvimento e na sua utilização para a criação de uma linha de produto de software, como os sistemas de tempo real, devido às necessidades de garantia no atendimento às restrições temporais. Devido a isso, são considerados sistemas críticos. Eles estão tornando-se cada vez mais comuns no mercado, e suas aplicabilidades vão desde controladores inteligentes embarcados em utilidades domésticas, até sistemas militares de defesa, de controle de tráfego aéreo e ferroviário1-4.
Sistemas de tempo real são muito utilizados em hospitais, principalmente nos setores que necessitam realizar monitoramento em pacientes internados. Estes sistemas são executados periodicamente, e devem seguir à risca determinadas restrições temporais.
Visando isso, o presente artigo tem como objetivo demonstrar como elaborar uma linha de produtos de software para sistemas de tempo real, utilizando algumas das práticas já existentes na literatura e citando os cuidados necessários para a geração dos sistemas diante da família que pertencem. É utilizada a ferramenta Captor para a elaboração da linha de produto e geração dos sistemas. Como estudo de caso, é utilizado um sistema de monitoramento de pacientes para a escolha das variabilidades e geração dos sistemas.
Linhas de Produto de Software para Sistemas de Monitoramento de Pacientes em Tempo Real
Linhas de Produto de Software podem ser aplicadas para sistemas de diversos domínios. A preocupação consiste em selecionar as features de cada sistema, identificando assim as características comuns e variáveis entre eles, e, desta forma, elaborar a linha de produto dos sistemas em questão.
Os sistemas que fazem parte do domínio de tempo real exigem uma maior preocupação na seleção das features relacionadas, pois além das funcionalidades comuns, devem ser levadas em conta as questões temporais do sistema, como parametrização temporal e concorrência de processos existentes no sistema.
A ferramenta Captor9 foi utilizada no desenvolvimento da Linha de Produto para Sistemas de Tempo Real por apresentar uma metodologia apropriada para a construção desses produtos. Ele facilita a criação dos sistemas de tempo real, pois permite uma total configuração de suas variabilidades, já que utiliza formulários para a criação e configuração do novo sistema. Outra facilidade do Captor está no mapeamento das variabilidades, que pode ser feita diretamente no código da aplicação, como também em arquivos externos a aplicação, através da configuração dos gabaritos e o componente de transformação de gabaritos XSL (EXtensible Stylesheet Language)11.
Visão Geral do Sistema
Para a criação do sistema, foi utilizado como estudo de caso um sistema de monitoramento de pacientes de um hospital. O sistema permite o acompanhamento dos sinais de temperatura e pressão de um determinado paciente, e, caso seja detectada alguma anormalidade nesses dados, um alerta é gerado e enviado ao profissional responsável.
O sistema pode ser gerado apenas para o monitoramento de um sinal, dependendo da necessidade do local que será implantado. Para o aviso do alerta, podem ser escolhidas três opções, exibição em tela, aviso sonoro ou mesmo envio para o dispositivo do médico.
E, finalmente, para o gerenciamento dos alertas gerados, o sistema disponibiliza a seleção de um mecanismo entre dois, um mais simples para hardwares com menor poder de
3
processamento, e um mais complexo para hardwares mais potentes. O primeiro consiste em uma lista de dados do tipo FIFO (First In First Out), que à medida que for recebendo novos alertas, vai enviando. O segundo consiste em uma lista por prioridades, que antes de enviar, verifica se existem outros alertas, e dependendo da prioridade do alerta, reordena a fila. A Figura 1 contém uma visão geral do funcionamento do sistema.
Figura 1: Visão Geral do Sistema.
Desta forma, foi utilizado o modelo de features, baseado no modelo de Czarnecki3, para uma melhor visualização do sistema que será gerado pela Linha de Produto de Software. Este modelo permite listar todas as features presentes no sistema, e suas respectivas dependências, como representa a Figura 2.
Figura 2: Modelo de Features do Estudo de Caso.
A primeira feature do sistema corresponde ao Monitoramento, responsável por consultar e analisar os dados de saúde de um paciente no hospital. Desta forma, ele contém duas features opcionais, a de Temperatura e Pressão. Na seleção de features do sistema, o usuário pode escolher por ter um monitoramento só da temperatura, só de pressão, ou mesmo as duas em paralelo.
A segunda feature corresponde ao gerenciamento dos alertas, que os armazena em uma fila através de escalonamento, e após isso os disponibiliza para o envio. Desta forma, existem dois tipos de escalonamentos, FIFO e por prioridade, que são do tipo alternativo, e o usuário deve obrigatoriamente selecionar somente uma das duas.
E, em relação à terceira feature, corresponde ao envio dos alertas, que pode ser feita para três equipamentos, um sonoro, a tela de um computador, ou mesmo um dispositivo móvel. As três opções correspondem às features opcionais, nas quais o usuário tem a liberdade de escolher qual dos envios irá usar.
Métodos: Elaboração do Sistema
A primeira preocupação consiste na elaboração de variabilidades que se baseiam na parametrização e quantidade de tarefas. Estas variabilidades podem produzir uma ou mais tarefas no sistema final, que podem ser variadas de acordo os seus parâmetros temporais. No estudo de caso, é o caso das features que representam a seleção do tipo de monitoramento, no
4
qual o usuário pode escolher temperatura ou pressão, e, logo em seguida, passar valores para a execução.
O Captor utiliza como forma de desenvolvimento do domínio uma Linguagem de Modelagem de Aplicações (LMA) baseada no preenchimento de formulários6-10.
A interface gráfica do Captor é configurada para apresentar os comportamentos variáveis dos sistemas que podem ser gerados, sendo salva em um arquivo XML (Extensible Markup Language). Inicialmente, são configurados um conjunto de arquivos responsáveis por transformar a especificação passada nos formulários nos artefatos de software, chamados de gabaritos. Esses gabaritos devem ser construídos utilizando a linguagem de gabaritos XSL (Extensible Stylesheet Language).
Para cada domínio, deve-se criar um arquivo de mapeamento de transformação de gabaritos, denominado MTL (Mapping Transformation Language), chamado também de templates. No código, é utilizada a linguagem de gabarito (XSTL - eXtensible Stylesheet Language Transformation) para a configuração e modificação das partes relacionadas aos domínios configurados. A preocupação na configuração do código é na geração dos processos correspondentes, modificando as variáveis que representam às restrições temporais, e gerando o código personalizado e pronto para o funcionamento.
No código, foram utilizados mecanismos da biblioteca de tempo real do RTSJ (Real-Time Specification for Java) para a sincronização de tarefas, na qual permite o bloqueio de recursos e funcionalidades quando é acessada por uma tarefa, liberando o acesso somente quando esta tarefa finaliza o processamento8.
Estes mecanismos de sincronização são importantes para serem utilizados em uma linha de produto, pois a quantidade de tarefas que será gerada e quantas delas irão executar em paralelo e acessar recursos em comum é indefinida, dependendo principalmente da seleção das features que o sistema conterá.
Logo em seguida, tem-se a fase de configuração dos formulários. A tela que irá ser exibida pelo Captor é mostrada na Figura 3.
Figura 3: Tela do Captor com a seleção de Features do sistema.
A primeira seleção de feature corresponde ao tipo de monitoramento que irá ser realizado. Nela é possível escolher entre a opção de realizar o monitoramento de temperatura ou de pressão, ou se os dois irão funcionar ao mesmo tempo.
Ao final, basta selecionar a opção de geração do sistema no Captor, que o mesmo estará pronto para ser executado no computador, com todas as features selecionadas e restrições elaboradas, funcionando corretamente.
Testes e Resultados
Foram feitos dois testes para a validação da ferramenta, o primeiro selecionando apenas algumas features do sistema, tais como: Monitoramento da temperatura, escalonador do tipo
5
Prioridade, e o alerta somente do tipo sonoro; e outro teste mais completo, selecionando várias features, aumentando, desta forma, o nível de concorrência no sistema. Foram selecionadas: Monitoramento da temperatura e pressão, escalonador do tipo FIFO, e todos os três sistemas de alertas. Os testes foram realizados no Sistema Operacional Linux Ubuntu 10.10, com a biblioteca Real-Time Specification for Java instalada.
Na Figura 4 (a) está representado o log do sistema resultante do primeiro teste em execução, e na Figura 4 (b) o log do sistema do segundo teste.
(a) (b)
Figura 4. Sistemas Resultantes dos dois Testes Realizados.
Discussão
Seguindo os passos citados no presente trabalho, um sistema simples de tempo real pode ser gerado através de uma linha de produto de software. Caso ele apresente uma maior complexidade, o projeto deve utilizar de novos mecanismos disponíveis pela máquina de tempo real ou mesmo a linguagem utilizada para a programação, como novos algoritmos de escalonamento, prioridades de tarefas, ou mesmo gerenciamento de memória compartilhada do computador.
A ferramenta Captor se mostrou eficiente para a elaboração da Linha de Produto para Sistemas de Tempo Real, pois atinge todas as fases de desenvolvimento, utiliza formulários na montagem e seleção das características do sistema (estruturas essas presentes no cotidiano dos usuários que irão utilizar o sistema), e também por fornecer todos os mecanismos para a geração de sistemas. As restrições temporais e demais conceitos relacionados puderam ser tratados facilmente pela ferramenta. As restrições temporais e demais conceitos relacionados puderam ser tratados facilmente pela ferramenta.
Conclusão
O presente trabalho possibilitou a elaboração e geração de uma Linha de Produto de Software para sistemas de tempo real na prática, permitindo a análise e resultados experimentais a cerca do domínio utilizado.
A elaboração da LPS facilitou o desenvolvimento de sistemas para o ambiente hospitalar, já que abstrai esta fase inicial e permite que um profissional da área da saúde, agora desempenhando o papel de montador de sistemas, gere novos sistemas através da seleção de características desejadas. Isto é muito importante, já que profissionais desta área têm poucos conhecimentos relacionados ao desenvolvimento de sistemas, podendo agora gerar novos sistemas em um tempo muito menor do que desenvolvedores levariam para desenvolver novas versões do mesmo.
Como trabalhos futuros, utilizar outras ferramentas para a criação de linhas de produto de software que suporte sistemas de tempo real, e realizar testes comparativos entre elas, como
6
também, durante a elaboração da linha de produto de software, utilizar Redes de Petri para validação dos possíveis produtos gerados, trabalhando também com a geração de sistemas de tempo real para softwares embarcados. Pretende-se também testar o sistema em ambiente real por profissionais da área da saúde e, logo em seguida, aplicar questionários sobre o atendimento ou não das suas necessidades por parte da LPS criada.
Agradecimentos
Ao Laboratório de Inovação Tecnológica em Saúde (LAIS), Hospital Universitário Onofre Lopes (HUOL), Universidade Federal do Rio Grande do Norte (UFRN), que proveu a infraestrutura necessária para o desenvolvimento da pesquisa discutida.
Referências
[1] Brandt S A, Banachowski S, Caixue L, Bisson T. Dynamic integrated scheduling of hard real-time, soft real-time, and non-real-time processes. In RTSS 2003: 24th IEEE Real-Time Systems Symposium. Cancun, Mexic; 2003.
[2] Clements P, Northrop L. Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley Longman Publishing; 2001.
[3] Czarnecki K. Generative Programming: Principles and Techniques of Software Engineering Based on Automated Configuration and Fragment-Based Component Models. Technical University of Ilmenau; 1998.
[4] Farines J, Fraga J S, Oliveira R S O. Sistemas de Tempo Real. In: 12ª Escola de Computação, IME-USP, São Paulo-SP; 2000.
[5] Gurp J V, Bosch J, Svahnberg M. On the Notion of Variability in Software Product Lines”. In WICSA '01: Proceedings of the Working IEEE/IFIP Conference on Software Architecture. Amsterdam, Netherlands; 2001.
[6] Pereira Junior C A F, Braga R T V, Masieiro P C. Captor-ao: Gerador de aplicações apoiado pela programação orientada a aspectos. In: Anais da Seção de Ferramentas do II Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS’2008), Porto Alegre, Brasil; 2008. p.1–8.
[7] Prieto-Diaz R. Classification of reusable modules, in Software Reusability: Concepts and Models, T.J. Biggerstaff and A.J. Perlis, Editors. Addison-Wesley Pub. Co.: New York, NY; 1989. p.99-123.
[8] RTSJ. Real Time Specification for Java. [citado 2012 jun 02]. Disponível em: http://www.rtsj.org/
[9] Shimabukuro E K. Um Gerador de aplicações configurável. Dissertação de Mestrado, ICMC/USP, São Carlos, SP; 2006.
[10] Shimabukuro E K, Masiero P, Braga R. Captor: um gerador de aplicações configurável. In: XX Simpósio Brasileiro de Engenharia de Software. Florianópolis, SC, Brasil; 2006. [11] W3C. The Extensible Stylesheet Language Family (XSL). [citado 2012 mai 10].
Disponível em: http://www.w3.org/Style/XSL.
Contato
Bruno Gomes de Araújo é Professor de Sistemas de Informação do IFRN - Câmpus Santa Cruz, Doutorando em Engenharia Elétrica e da Computação pela UFRN, Editor da Revista Brasileira de Inovação Tecnológica
em Saúde (R-BITS), Responsável pela Tele-educação do Portal Telessaúde Brasil (RN). Endereço Profissional: IFRN, Câmpus Santa Cruz, Rua São Braz, n.º 304, Paraíso, 59200-000 - Santa Cruz, RN – Brasil.
Telefone: (84) 3291-4700.
