Dynamic Variability Management in Product Lines: An Approach Based on Architectural Contracts

Transcrição

1 Dynamic Variability Management in Product Lines: An Approach Based on Architectural Contracts Sergio T. Carvalho, Orlando Loques, Leonardo Murta Instituto de Computação - Universidade Federal Fluminense (UFF) Niterói - RJ - Brasil Instituto de Informática - Universidade Federal de Goiás (UFG) Goiânia - GO - Brasil {scarvalho, loques, leomurta}@ic.uff.br Resumo Linhas de produto de software capturam características comuns e variabilidades de produtos com o objetivo de facilitar o processo de desenvolvimento de novos produtos. No entanto, o gerenciamento de variabilidades é tradicionalmente feito apenas em tempo de desenvolvimento e implantação, não atendendo a classes de aplicações que demandam um alto grau de adaptabilidade tais como as aplicações ubíquas/pervasivas e sensíveis ao contexto. Este artigo apresenta uma abordagem para o gerenciamento de variabilidades em tempo de execução, considerando linhas de produto voltadas para aplicações sensíveis ao contexto. A abordagem está centrada na descrição da arquitetura da linha de produto de forma associada a contratos, usados para gerenciar as variabilidades dinâmicas. Em um contrato podem ser definidos serviços e regras de contexto em um nível alto de abstração. Serviços encapsulam variabilidades e são capazes de adaptar/reconfigurar a arquitetura de um produto dinamicamente, enquanto que as regras determinam um contexto no qual determinado serviço deve ser ativado. Essa abordagem foi aplicada em cenários envolvendo variabilidades dinâmicas de uma linha de produto voltada para aplicações de assistência domiciliar à saúde, nos quais foi possível observar a sua viabilidade. Abstract Software product lines capture commonalities and variabilities of products in order to facilitate the process development of new products. However, variability management is traditionally done just in development time and deployment time, not attending classes of applications that require a high degree of adaptability such as ubiquitous/pervasive and contextaware applications. This paper presents an approach for runtime variability management, considering product lines aimed at context-aware applications. The approach focuses on product line architecture description associated to contracts, which are used to manage dynamic variabilities. In a contract can be set services and context rules at a high level of abstraction. Services encapsulate variabilities and are capable of adapting/reconfiguring architecture of a product on dynamic way, while the rules determine a context which a particular service should be activated. This approach was applied in scenarios involving dynamic variabilities in a product line focused on home health care applications, where it was possible to observe its feasibility. I. INTRODUÇÃO De acordo com Northrop [1] o uso de técnicas de Linha de Produto de Software (LPS) tem como foco a concepção, desenvolvimento e evolução de uma família de produtos de software relacionados. Todos os produtos da linha compartilham um único conjunto de características e são diferenciados uns dos outros por um conjunto de variabilidades. A criação de um produto específico consiste em um processo denominado derivação, onde são selecionadas as variabilidades que devem estar presentes no produto em questão. Uma vez resolvidas as variabilidades, inclusive relacionadas aos componentes reutilizáveis que são necessários, o produto pode ser implantado e executado. Essa abordagem proporciona a redução do tempo de desenvolvimento e dos custos [2], assim como a melhoria da qualidade na criação de um produto de software [1]. Por exemplo, ao criar um produto de uma linha de produto voltada a aplicações de monitoramento de pacientes, uma variabilidade a ser resolvida pode ser referente à existência ou não de sensor do tipo botão de pânico nos produtos. Este equipamento, geralmente portado pelo próprio paciente, emite um alarme para a central de supervisão médica ao ser pressionado. Em muitas situações, entretanto, o seu uso pode ser desnecessário, ou mesmo inapropriado, de acordo com o cuidado e/ou tratamento daquele paciente. Desta forma, a derivação de produtos com ou sem esse equipamento é prevista e desejada em função do contexto de utilização. Linhas de produto têm se mostrado uma forma eficiente de lidar com as diferentes necessidades dos usuários [3], uma vez que é possível personalizar um produto de software por meio da seleção das variabilidades antes mesmo da sua implantação. No entanto, essa técnica na sua forma tradicional não é conveniente para produtos cujas arquiteturas precisem se adaptar em tempo de execução tais como as aplicações sensíveis ao contexto e/ou baseadas em computação ubíqua/pervasiva. Essas aplicações possuem variabilidades dinâmicas (resolvidas em tempo de execução), exigindo que a arquitetura da linha de produto tenha características de adaptação dinâmica e que mecanismos de monitoramento do contexto e controle das adaptações estejam disponíveis [4]. Em outras palavras, o processo de derivação que acontece tradicionalmente de forma completa em tempo de desenvolvimento passa a ocorrer parcialmente, produzindo um produto flexível (sub linha de produto), que permite adaptações posteriores em função de demandas só detectáveis em tempo de execução. As aplicações de monitoramento de pacientes em ambiente residencial, por exemplo, dependem da qualidade e da disponibilidade dos recursos usados (e.g., sensores, dispositivos, etc.), uma vez que esses recursos podem ser adicionados, removidos ou simplesmente falhar. Há ainda aspectos relacionados às 66

2 necessidades e preferências do paciente, as quais podem mudar de acordo com os seus problemas de saúde: um paciente com hipertensão, por exemplo, pode progredir para insuficiência cardíaca, exigindo novas prescrições médicas e sensores fisiológicos adequados. Neste exemplo, a presença dos sensores e dos dispositivos pode exigir variabilidades dinâmicas no software, uma vez que esses elementos são percebidos somente durante a execução da aplicação. Um produto, criado e personalizado com as características individuais de um paciente na sua residência, deve ter uma arquitetura capaz de se adaptar, em consequência do gerenciamento das variabilidades dinâmicas, de acordo com o contexto, o ambiente e os estados dos recursos [5]. Uma infraestrutura de suporte especializada deve estar disponível para verificar continuamente as informações do contexto, tanto do paciente (e.g., localização, estado de saúde, dados fisiológicos, atividades, etc.) quanto da residência (e.g., layout, distribuição dos sensores e dispositivos nos ambientes, dados ambientais, etc.), e para controlar as adaptações, gerando novas configurações arquiteturais para o produto em operação. Neste artigo apresentamos uma abordagem para o gerenciamento de variabilidades dinâmicas baseada em contratos arquiteturais, os quais especificam serviços que realizam a adaptação/reconfiguração da arquitetura dinamicamente conforme regras de contexto previamente especificadas. Contratos são associados à descrição da arquitetura da linha de produto e encapsulam as variabilidades dinâmicas. Além disso, contêm uma máquina de negociação que especifica os níveis desejados de qualidade e como devem ser impostos à arquitetura. Um framework de suporte realiza o monitoramento do contexto, a execução dos serviços e o controle da adaptação da arquitetura. Para demonstrar a viabilidade da abordagem, apresentamos dois cenários baseados em variabilidades dinâmicas observadas em uma linha de produto que está sendo desenvolvida no contexto de um projeto voltado para a aplicação da computação ubíqua/pervasiva em sistemas de assistência domiciliar à saúde. No primeiro cenário, é selecionada a tecnologia de comunicação usada para ligar a residência do paciente e a central de supervisão médica e, no segundo cenário, é selecionado um dispositivo na residência (e.g., TV, celular, etc.) para notificar o paciente lembrando-o de realizar suas prescrições médicas. Neste último, são descritas regras de contexto para selecionar o dispositivo que esteja mais próximo ao paciente e que tenha a sua preferência. O artigo está organizado da seguinte forma: a Seção II descreve conceitos relativos a linhas de produto e arquitetura de software, importantes para a contextualização deste trabalho; a Seção III apresenta uma linha de produtos para sistemas ubíquos/pervasivos de assistência domiciliar à saúde, focando as variabilidades dinâmicas e os requisitos de adaptação próprios dessa classe de aplicações; a Seção IV descreve a abordagem e os cenários baseados na linha de produto apresentada na Seção III; a Seção V menciona os trabalhos relacionados; e a Seção VI traz as conclusões. II. LINHA DE PRODUTO E ARQUITETURA DE SOFTWARE Muitas aplicações possuem conceitos e características similares, constituindo uma família de produtos de software relacionados. Esse aspecto aliado às necessidades de redução de custo e esforço no desenvolvimento de sistemas constituem os princípios das LPSs. O planejamento de uma LPS tem como objetivo a construção de produtos relacionados e que atendam às necessidades específicas de uma missão ou segmento de mercado [1]. As similaridades entre os produtos permitem que o desenvolvimento seja feito levando-se em conta um conjunto de artefatos básicos, os quais podem ser reutilizados. Para isso, uma LPS deve capturar, através de um modelo de características, as semelhanças e diferenças entre os produtos [2]. Em um modelo de características [6], as semelhanças entre os produtos da linha são denominadas características comuns (obrigatórias), e as diferenças são denominadas variabilidades, as quais são divididas em três tipos: opcionais, alternativas e alternativas opcionais. Uma característica opcional se refere àquela que pode ou não estar presente em um produto; uma alternativa se refere àquela que está presente, mas pode ser selecionada dentre um conjunto de alternativas; e uma alternativa opcional se refere a uma alternativa que pode ou não estar presente em um produto. O modelo de características é uma forma de representar um domínio, inter-relacionando as suas características comuns e as suas variabilidades. Além disso, ele possui um alto nível de abstração, orientando no gerenciamento de variabilidades a fim de derivar (criar) um produto específico (personalizado) da LPS. A Figura 2 mostra um modelo de características parcial de uma LPS voltada para o monitoramento remoto de pacientes em ambiente domiciliar (Seção III). Nesse modelo existem características obrigatórias (círculos pretos) tais como o alarme que deve ser enviado para uma central de supervisão e o mecanismo de notificação ao paciente, e características opcionais (círculos brancos) tais como os sensores fisiológicos que devem ser usados pelo paciente na sua casa. Durante a derivação de um produto específico, as duas primeiras características são necessariamente selecionadas, enquanto as opcionais (variabilidades) podem ou não ser selecionadas. A seleção pode ser por um sensor de pressão arterial, para o caso da derivação de um sistema personalizado para um paciente com hipertensão, ou por um sensor de frequência cardíaca, para um paciente com insuficiência cardíaca, ou ainda por ambos. Além do modelo de características, uma LPS é constituída basicamente de um conjunto de componentes reutilizáveis e de uma arquitetura de software [1]. Um produto é criado a partir da seleção das variabilidades e da configuração de componentes seguindo a descrição da arquitetura da LPS. Os componentes utilizados no produto são buscados junto a um repositório comum de componentes reutilizáveis. A arquitetura de uma LPS fornece abstrações para representar a estrutura e o comportamento dos produtos. De forma geral, uma arquitetura de software pode ser definida como um conjunto de componentes, um conjunto de conectores 67

3 (interconexões entre estes componentes), e a organização destes elementos (configuração) para um determinado sistema de software [7]. A especificação dos elementos da arquitetura de um sistema são feitas por meio de uma Linguagem de Descrição Arquitetural - Architectural Description Language (ADL). Diferentemente da arquitetura concebida para sistemas isolados (não relacionados), a arquitetura de uma LPS deve representar os elementos arquiteturais correspondentes às características comuns, e os elementos opcionais e alternativos correspondentes às variabilidades. Assim, a arquitetura de um produto específico pode ser derivada da arquitetura da LPS por meio da incorporação dos elementos comuns e da seleção dos elementos relativos às variabilidades que serão incluídas [8]. A seleção das variabilidades em uma LPS é feita apenas em tempo de desenvolvimento e de implantação de um produto [4]. Isso significa que, uma vez selecionadas as variabilidades e com o produto implantado, não é possível que estas mudem ou se adaptem durante a sua operação. No entanto, há classes de aplicações que demandam um alto grau de adaptabilidade tais como as aplicações ubíquas/pervasivas e sensíveis ao contexto. Em tais aplicações as variações no ambiente, na disponibilidade ou na qualidade dos recursos, ou ainda mudanças quanto às necessidades dos usuários, exigem respostas da aplicação no sentido de adaptar a sua arquitetura em tempo de execução. III. UMA LINHA DE PRODUTO COM VARIABILIDADES DINÂMICAS Uma classe de aplicações que exige um alto grau de adaptabilidade é a dos sistemas ubíquos/pervasivos de assistência domiciliar à saúde [9], [5], nos quais pacientes são monitorados remotamente. A Figura 1 mostra a estrutura geral de um sistema desta classe. Figura 1. Estrutura geral de um sistema de assistência domiciliar à saúde. Neste sistema, o paciente tem seus dados (fisiológicos e comportamentais) e dados do ambiente residencial coletados por sensores e processados por uma Central de Saúde Residencial (CSR). Os dados coletados são representados por variáveis fuzzy e analisados por meio de técnicas de inteligência artificial. A eventual identificação de uma situação anormal do paciente pode ativar um dispositivo local (uma TV, por exemplo), aumentar a frequência de monitoramento [10] ou ainda, dependendo da gravidade, enviar um alarme de emergência para uma Central de Supervisão Médica (CSM). Um plano de cuidados orienta o paciente quanto às medições que deve realizar (e.g., pressão arterial), aos medicamentos que deve tomar, e a outras recomendações personalizadas conforme o tratamento. Mais detalhes sobre este sistema estão disponíveis em [11], [12], [13]. Sistemas de assistência domiciliar à saúde têm sido propostos de forma especializada não levando em conta as diferenças entre os pacientes, especialmente quanto às suas preferências e necessidades, inclusive relacionadas à doença tratada [9]. Cada sistema deve ser personalizado tanto em relação ao paciente quanto em relação à residência (layout da casa, distribuição e tipo dos sensores e dispositivos, etc.). Neste contexto, a abordagem de linha de produto possibilita a personalização de sistemas e, ao mesmo tempo, com custo e esforço de desenvolvimento reduzidos. A Figura 2 mostra um modelo de características parcial de uma LPS para a assistência domiciliar à saúde (ADS). Este modelo foi gerado a partir da análise de diversos trabalhos relacionados à área de computação ubíqua/pervasiva na assistência domiciliar à saúde (e.g., [14], [15], [16]), do conhecimento obtido junto a especialistas da área de saúde, e da experiência adquirida no desenvolvimento de um protótipo voltado à contínua identificação da situação de saúde do paciente associada à definição de um plano de cuidados [13]. A partir deste modelo pode-se verificar que, para um determinado paciente em sua residência, seus requisitos de monitoramento e características de software necessárias ao seu suporte podem variar bastante. Tal variação pode ocorrer tanto durante a implantação de um sistema quanto durante a sua operação. Durante a implantação de um sistema personalizado na residência deve-se, em princípio, especificar um conjunto de regras médicas especializadas para determinada doença e um conjunto apropriado de sensores para coletar os dados fisiológicos e de contexto relevantes. Além disso, um plano de cuidados personalizado deve ser definido de acordo com recomendações médicas aplicadas ao paciente [17]. Durante a operação do sistema, por sua vez, mudanças nos problemas de saúde do paciente podem exigir modificações nos recursos previamente configurados (sensores, dispositivos médicos, etc.) ou no plano de cuidados, exigindo a reconfiguração (adaptação dinâmica) do sistema. Por exemplo, o médico ao perceber mudanças de saúde do paciente monitorado, pode indicar através do plano de cuidados que ele use um novo dispositivo para medir sua frequência cardíaca periodicamente. O sistema, inicialmente personalizado para um paciente com hipertensão, deve ter sua arquitetura reconfigurada dinamicamente para atender a essa nova demanda. É importante notar que em uma utilização tradicional de LPS, ao constatar a necessidade de monitoramento de um 68

4 Figura 2. Uma LPS para Assistência Domiciliar à Saúde (ADS). Os círculos brancos identificam as características opcionais e os círculos pretos identificam as características obrigatórias. Notação usada: Kang et al. [6]. determinado paciente, um produto seria derivado da LPS e implantado na residência do paciente. A arquitetura desse produto estaria totalmente acoplada às necessidades do paciente e às características da sua residência daquele momento no tempo. Se no futuro o quadro do paciente mudasse (e.g., quadro de hipertensão progredisse para insuficiência cardíaca) ou mesmo novos dispositivos fossem adicionados na sua residência, uma nova versão do produto teria que ser derivada e implantada. A demora envolvida nessa avaliação estática e necessidade de nova implantação poderia resultar em consequências graves para essa classe de sistema. Um elemento fundamental durante a operação do sistema é o plano de cuidados, uma vez que pode ser visto como uma sequência de tarefas similar a um fluxo e pode ser usado para a interação do sistema com o paciente. Por exemplo, o sistema pode lembrar o paciente, através da tela da TV ou do celular, que precisa tomar um medicamento em determinado horário. A escolha do dispositivo de interação pode ser feita durante a implantação do sistema, no entanto a casa pode dispor de diferentes dispositivos (TVs, monitor da CSR, etc.), assim como o próprio paciente (celular, PDA, etc.). Nessa situação, a escolha de qual dispositivo o paciente deve receber as mensagens do plano de cuidados pode ser postergada para a execução do sistema e realizada seguindo regras de contexto, como por exemplo, escolher o dispositivo mais próximo ao paciente e que seja o seu preferido (veja o cenário descrito na Subseção IV-B). A seleção da variabilidade em tempo de execução implica na adaptação dinâmica da arquitetura do sistema a fim de configurar o dispositivo escolhido. Requisitos de adaptação do sistema passam ainda pela sua capacidade de lidar com a disponibilidade dos recursos. Por exemplo, para prover mecanismos de tolerância a falhas para a comunicação entre a residência e a central, são necessárias adaptações dinâmicas da arquitetura a fim de selecionar a melhor dentre as tecnologias de comunicação alternativas, incluindo o caso de falhas entre elas (veja o cenário descrito na Subseção IV-A). A LPS para sistemas de assistência domiciliar à saúde (Figura 2) possui, portanto, variabilidades que são resolvidas em tempo de execução. Estas variabilidades são denominadas de variabilidades dinâmicas e exigem mecanismos para prover a adaptação/reconfiguração da arquitetura do produto durante a sua operação. A próxima seção apresenta a nossa abordagem de um mecanismo de adaptação baseado em contratos arquiteturais para o gerenciamento de variabilidades dinâmicas. IV. GERENCIAMENTO DE VARIABILIDADES DINÂMICAS COM CONTRATOS ARQUITETURAIS Nossa abordagem para o gerenciamento de variabilidades em tempo de execução está centrada na descrição da arquitetura da LPS de forma associada a contratos, usados para gerenciar as variabilidades. Em um contrato podem ser definidos serviços capazes de adaptar/reconfigurar a arquitetura de um produto dinamicamente, com base em regras de contexto. Os serviços podem encapsular variabilidades dinâmicas enquanto que as regras determinam um contexto no qual determinado serviço deve ser realizado. As características comuns e as variabilidades selecionadas em tempo de implantação de um produto são representadas diretamente como elementos arquiteturais. As variabilidades dinâmicas, por sua vez, são encapsuladas em contratos arquiteturais, os quais são instanciados durante a operação do produto. Por exemplo, pode-se derivar um produto cuja configuração da arquitetura tenha dois componentes interligados por um conector responsável por prover uma tecnologia de comunicação. Durante a operação do produto, um contrato 69

5 pode ser instanciado com o objetivo de tratar esta característica de comunicação, selecionando e configurando o conector mais adequado para, de acordo com a tecnologia de comunicação disponível, interligar os componentes. Os contratos são construídos com a linguagem de descrição de contratos CBabel [18] a qual permite descrever serviços de adaptação e regras de contexto. A semântica dos contratos é imposta em tempo de execução por um framework de suporte à configuração, desenvolvido em nosso grupo de pesquisa. Ele provê, dentre outros recursos, o monitoramento de contexto e o controle da adaptação, centrais em uma Linha de Produto de Software Dinâmica (LPSD) [4]. As principais funções do framework são: (i) interpretar as especificações descritas no contrato e armazená-las como informações de meta-nível associadas ao produto, (ii) prover mecanismos de reflexão e adaptação dinâmica, os quais permitem gerenciar e adaptar as configurações arquiteturais a fim de atender as demandas definidas nos contratos, e (iii) monitorar e gerenciar os contratos associados ao produto. Além disso, o framework integra serviços de contexto, monitoramento e descoberta de recursos. Mais detalhes dos componentes e do funcionamento do framework de suporte estão disponíveis em [19], [18], [20]. Um contrato possui os seguintes elementos: Categorias: descrevem, em um nível abstrato, propriedades associadas ao contexto no qual o produto executa (e.g., localização do paciente, localização de equipamentos tais como TV, celular, tipos de sensores, etc.). Categorias são associadas a entidades do framework de suporte que vão alocar e monitorar suas respectivas propriedades. Perfis: quantificam e valoram as propriedades de uma categoria. A quantificação restringe cada propriedade de acordo com a sua descrição, funcionando como uma instância de valores aceitáveis para determinada categoria. Serviços: definem restrições que devem ser aplicadas ao produto no nível da sua arquitetura. A aplicação destas restrições tem como consequência a configuração ou reconfiguração dinâmica da arquitetura do produto, realizada através da associação de um ou mais perfis aos seus elementos arquiteturais. Cada serviço define um possível estado de operação para o produto. Negociação: descreve uma política, definida por uma máquina de estados, que estabelece uma ordem arbitrária para a implantação dos serviços. De acordo com o descrito na cláusula de negociação, quando um serviço de maior preferência não puder mais ser mantido, o framework de suporte tentará implantar um serviço com menor preferência. O retorno para um serviço de maior preferência também pode ser descrito, permitindo que um serviço de melhor qualidade seja implantado se os perfis associados se tornarem válidos. Nas próximas duas subseções são apresentados dois cenários com o objetivo de ilustrar e tornar mais clara a abordagem. Os cenários estão relacionados com a LPS para sistemas de assistência domiciliar à saúde apresentada na Figura 2. O primeiro trata da comunicação entre a CSR (Central de Saúde Residencial) e a CSM (Central de Supervisão Médica), enquanto o segundo seleciona um dispositivo (TV, celular, etc.) mais próximo ao paciente e de sua preferência, com o objetivo de enviar mensagens lembrando-o de realizar as prescrições médicas. A. Cenário 1: Comunicação A transmissão de dados de emergência da CSR para a CSM pode sofrer descontinuidades, geralmente associadas à qualidade do serviço prestado pelos provedores de acesso, uma vez que primariamente a comunicação é feita através da Internet commodity. Neste sentido, pode-se prover características relacionadas à tolerância a falhas utilizando um canal alternativo via rede celular, ou mesmo via linha fixa. A Figura 3 mostra uma arquitetura e um contrato ilustrando a característica de comunicação. Figura 3. Arquitetura e contrato para comunicação. Os conectores pontilhados (Figura 3a) representam as alternativas desta característica, as quais são disponíveis como tecnologias de comunicação que podem ser selecionadas para a interconexão entre os componentes CSR e CSM. A Figura 3b apresenta a descrição simplificada da arquitetura, na qual são 70

6 definidos os componentes CSR e CSM (linhas 02-03) e a interconexão entre eles (linha 04). O conector entre os componentes deve ser dinamicamente estabelecido pelo contrato disponível na Figura 3c. A execução dessa configuração arquitetural associa o respectivo contrato à arquitetura. O contrato (Figura 3c) define três diferentes serviços, sendo que cada serviço encapsula uma alternativa de comunicação (linhas 07-10, e 15-18). O suporte necessário para cada serviço está encapsulado em um conector (construção link), seguindo a regra de contexto descrita no perfil, o qual é definido diretamente usando a propriedade Comunicacao.tecnologia. Para cada opção de canal há uma interface de comunicação e um sensor específico que detecta se o respectivo canal está disponível ou não. Para estabelecer o enlace de comunicação, o framework de suporte configura o respectivo conector e, durante a operação, tenta manter o enlace relativo ao canal preferencial. A cláusula de negociação (linhas 19-25) define que o serviço preferencial é sinternet e que, caso não esteja disponível, os serviços slinhafixa e scelular devem ser tentados. A linha 21 indica que o serviço sinternet deve ser executado assim que o enlace referente à Internet commodity se restabeleça. As transições entre os serviços dependem da disponibilidade desses serviços. Pode-se perceber com este cenário o emprego de contratos no tratamento de variabilidades relacionadas a aspectos não funcionais, neste caso a disponibilidade do recurso de comunicação. Outros aspectos não funcionais podem ser considerados nesta arquitetura, como por exemplo, a confiabilidade, associando um protocolo de comunicação confiável a um conector na arquitetura do produto. B. Cenário 2: Notificação Sensível ao Contexto O segundo cenário manipula características opcionais relacionadas a dispositivos tais como TV, monitor da CSR, celular, etc., os quais podem ser usados para notificar o paciente para realizar as prescrições médicas tais como tomar um medicamento, realizar uma medida com um sensor fisiológico (e.g., pressão arterial, frequência cardíaca, etc.) e outras recomendações personalizadas conforme o tratamento. O plano de cuidados mantém essas prescrições e deve interagir com o notificador, o qual envia as mensagens aos dispositivos disponíveis na casa do paciente. Os dispositivos são características da LPS e, neste cenário, são representados como variabilidades dinâmicas. Assim, a seleção de qual dispositivo usar para apresentar as mensagens ao paciente deve ser feita em tempo de execução e de acordo com regras de contexto. Para isso a arquitetura do produto deve ser estabelecida com instâncias dos componentes Plano de Cuidados e Notificador, por serem características comuns da LPS, e com um conector interligando-as (Figura 4a). As linhas descrevem a instanciação destes componentes e a linha 04 descreve a interligação (Figura 4b). A arquitetura estabelece ainda os componentes relativos ao celular (linha 05), à TV (linha 07) e ao monitor da CSR (linha 08), e a interconexão entre estes dispositivos e o notificador Figura 4. Arquitetura para a notificação ao paciente. (linha 09). Para que os dispositivos sejam selecionados em tempo de execução, parte desta arquitetura (linhas 07-09) deve ser associada a contratos que definem regras de contexto para a seleção. Neste cenário, a instanciação da TV está condicionada a uma situação de contexto: ela deve estar próxima ao paciente. A mesma regra de contexto se aplica ao monitor da CSR, enquanto que o celular não depende de qualquer regra de contexto e sempre é instanciado. A interconexão ao notificador, por sua vez, será feita a apenas um dos dispositivos (TV, monitor da CSR ou celular), de acordo com as preferências do paciente descritas no perfil. O paciente terá, portanto, a mensagem de notificação apresentada em um dispositivo da sua preferência, dentre aqueles localizados mais próximos a ele (no mesmo ambiente). Duas categorias foram definidas na Figura 5a, Paciente e Dispositivo, com as propriedades de contexto que devem ser avaliadas pelos serviços do contrato associado à arquitetura. Os valores a serem consultados junto ao serviço de contexto estão definidos em dois perfis, perfildispmaisprox e perfildisppref, apresentados na Figura 5b. Um contrato pode ser construído para selecionar os dispositivos (TV ou monitor da CSR) que estejam no mesmo ambiente do paciente (Figura 6). Ele descreve um serviço para selecionar as variabilidades (linhas 04-09), no qual somente os dispositivos que atendem ao perfil perfilmaisprox são instanciados. No exemplo, se nenhum dos dispositivos atender ao perfil ou se a TV estiver desligada ou não operacional, o 71

7 um dispositivo no mesmo ambiente do paciente. No exemplo, se o paciente estiver na sala, o serviço pode selecionar a TV e o monitor da CSR, supondo que ambos estejam também na sala. Portanto, além dessas informações de contexto, devem ser usadas as informações relacionadas à preferência do paciente, importantes quando se trata de pacientes em assistência domiciliar à saúde. O contrato apresentado na Figura 7, também associado à arquitetura do produto, interliga o notificador ao dispositivo preferido do paciente. Figura 5. a) Categorias Paciente e Dispositivo; b) Perfis perfildispmaisprox e perfildisppref. serviço servtodosdisp não iniciará sua execução, mas sim o serviço servcsr, de acordo com a cláusula de negociação definida nas linhas Além disso o contrato recebe, no momento de sua instanciação, duas variáveis de contexto numéricas, usadas respectivamente para identificar o paciente e o ambiente da casa no qual ele está (linhas 01-02). Um serviço de localização monitora estas variáveis e pode ser integrado ao framework de suporte [10], [21]. Figura 6. Contrato para selecionar o dispositivo mais próximo ao paciente. A instrução instantiate instancia (seleciona) o dispositivo apenas se o paciente localizado pelo serviço de localização (idpaciente na linha 01 do contrato) for o paciente registrado no sistema (Paciente.id na linha 10 do perfil perfildispmaisprox), e se o ambiente que ele está (localpaciente na linha 01 do contrato) for o mesmo do dispositivo que está sendo instanciado (Dispositivo.localizacao nas linhas do perfil perfildispmaisprox). Se estas regras das linhas do perfil não forem atendidas a instanciação (seleção) do dispositivo em questão não será realizada. O serviço do contrato da Figura 6 pode selecionar mais de Figura 7. próximos. Contrato para selecionar o dispositivo preferido dentre os mais A construção select (linhas 04-05) faz com que o framework de suporte localize as instâncias da classe Dispositivo (TV, monitorcsr, celular) correspondentes aos dispositivos mais próximos ao paciente e selecione, dentre estes dispositivos (Dispositivo@casa), o preferido pelo paciente conforme as regras definidas no perfil de seleção perfildisppref, nas suas linhas 15 e 16 (Figura 5b). O dispositivo selecionado (@disp) é então interligado ao notificador. Se o paciente estiver na sala as mensagens serão mostradas no seu dispositivo preferido, neste exemplo a TV, e caso esta não esteja ligada ou mesmo não esteja operacional, serão mostradas no monitor da CSR (linhas do contrato da Figura 6). O celular será escolhido se o paciente estiver em outro ambiente que não seja a sala. A partir da descrição da arquitetura, das categorias, dos perfis e dos contratos, o paciente receberá suas notificações por meio do dispositivo que esteja mais próximo a ele, respeitando suas preferências de uso. Mais detalhes sobre o mecanismo de descoberta e de ligação dinâmica de recursos estão disponíveis em [19], [21]. V. TRABALHOS RELACIONADOS Vários trabalhos em LPS abordam o gerenciamento de variabilidades de forma estática sem considerar as mudanças que podem ocorrer em tempo de execução [2], [1], [22]. Outros propõem o gerenciamento de variabilidades em tempo de execução empregando técnicas baseadas em parametrização e diretivas [23], [24]. Há ainda pesquisas em torno do modelo de características de LPS tais como [25] que propõe uma técnica para se desenvolver componentes dinamicamente reconfiguráveis, e [26] que propõe uma extensão ao modelo de características para representar informações de contexto. Estes trabalhos não adotam uma representação arquitetural, diferentemente da nossa abordagem que é centrada em arquiteturas e que trata componentes e conectores como entidades de primeira classe. 72

8 Há vários trabalhos que tratam de adaptação dinâmica baseada em modelos arquiteturais. Floch et al. [3] tratam as variabilidades dinâmicas como configurações, de forma semelhante à nossa abordagem. A reconfiguração é feita com base em funções utilidade, também adotadas no nosso mecanismo de reconfiguração [27]. O foco deles, no entanto, está restrito a aplicações móveis. Morin et al. [28] tratam a adaptação considerando quatro aspectos: variabilidades, ambiente e contexto do sistema, arquitetura do sistema e lógica de adaptação. Os autores usam técnicas de modelagem orientadas a aspectos para construir as configurações arquiteturais, enquanto que a nossa abordagem provê a separação de interesses por meio de outros mecanismos, visto que os contratos representam as variabilidades em um nível alto de abstração e podem ser descritos distintamente da arquitetura. Rainbown [29] usa invariantes coordenadas com estratégias de adaptação, às quais são semelhantes aos perfis e serviços empregados no contrato, e as adaptações são encapsuladas em procedimentos que implementam as ações de configuração. De forma diferente, as adaptações na nossa abordagem são governadas pelo contrato com base em uma ADL, o que permite a validação formal do procedimento de adaptação antes da implantação do produto de software [30]. Complementar à nossa pesquisa é a proposta descrita em [31]. Os autores dimensionam as variabilidades em duas: variabilidade de ambiente que define as condições sob as quais um sistema deve se adaptar, e variabilidade estrutural que define as configurações arquiteturais resultantes. A reconfiguração é feita por meio de um middleware baseado em componentes e utiliza uma máquina de estados para representar as configurações do sistema. Em relação ao domínio da assistência domiciliar à saúde, sistemas têm sidos propostos (e.g., [15], [16]), no entanto não abordam aspectos de personalização como argumentados na Seção III. Uma ideia semelhante à LPS mostrada na Figura 2 é apresentada em [32] com o objetivo de personalizar os sistemas. No entanto, os autores não tratam de diversas características tais como o uso de um serviço de contexto e a integração de informações fisiológicas e comportamentais do paciente, dentre outras. VI. CONCLUSÃO Este artigo apresentou uma abordagem para o gerenciamento de variabilidades dinâmicas em LPSs. As variabilidades são gerenciadas por contratos arquiteturais, os quais são instanciados por um framework de suporte responsável por monitorar o contexto e controlar a adaptação da arquitetura. Com o intuito de demonstrar a viabilidade da abordagem, foram descritos cenários envolvendo variabilidades dinâmicas de uma LPS. A principal contribuição do mecanismo proposto está na possibilidade de expressar as variabilidades dinâmicas em um nível alto de abstração. A linguagem de descrição de contratos permite representar tanto as ações de adaptação (serviços) que devem ser realizadas junto à arquitetura quanto as regras de contexto (perfis) usadas para guiar estas adaptações. Considerando ainda que a semântica do contrato é traduzida em ações junto ao framework de suporte, a construção do contrato pode ser vista como um padrão [33], facilitando a especificação das variabilidades dinâmicas da LPS. Além disso, a semântica dos contratos facilita a aplicação de procedimentos de verificação e de validação formal das suas especificações, antes mesmo da implantação do produto de software [30]. Outro aspecto é o fato dos contratos não fazerem parte da arquitetura da LPS, mas sim estarem associados a ela. Essa propriedade permite que as variabilidades dinâmicas sejam tratadas separadamente das características obrigatórias durante o processo de desenvolvimento de um produto. Isso traz benefícios em termos da separação de interesses, facilitando a reutilização dos componentes entre os produtos que compõem a linha. O domínio da assistência domiciliar à saúde tem orientado nossos esforços em torno da identificação de requisitos que exijam a aplicação de técnicas de adaptação dinâmica. Atualmente estamos investigando mecanismos que permitam adaptar os contratos em tempo de execução, ou mesmo criar e instanciar novos contratos, para que possam manipular variabilidades e requisitos não previstos em tempo de desenvolvimento, como argumentado em [34]. O objetivo é a concepção de uma linha de produto dinâmica que contemple suas diversas características, variabilidades e requisitos. AGRADECIMENTOS Os autores agradecem ao CNPq e à FAPERJ pelo financiamento parcial deste trabalho. REFERÊNCIAS [1] L. M. Northrop, Sei s software product line tenets, IEEE Software, vol. 19, pp , [2] G. Jilles van, J. Bosch, and M. Svahnberg, On the notion of variability in software product lines, in WICSA 01: Proceedings of the Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA: IEEE Computer Society, 2001, p. 45. [3] S. Hallsteinsen, E. Stav, A. Solberg, and J. Floch, Using product line techniques to build adaptive systems, in 10th Int. Conference on Software Product Line, Washington, DC, USA, 2006, pp [4] S. Hallsteinsen, M. Hinchey et al., Dynamic software product lines, Computer, vol. 41, no. 4, pp , [5] O. Loques and A. Sztajnberg, Adaptation issues in software architectures of remote health care systems, in 2nd Workshop on Software Engineering in Health Care - SEHC ACM/IEEE 32nd Int. Conference on Software Engineering, Cape Town, South Africa, may [6] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, Feature- Oriented Domain Analysis (FODA) Feasibility Study. Technical Report, CMU/SEI-90-TR-21, Software Engineering Institute (Carnegie Mellon), Pittsburgh, PA 15213, Tech. Rep., [7] N. Medvidovic and R. N. Taylor, A classification and comparison framework for software architecture description languages, IEEE Trans. Softw. Eng., vol. 26, no. 1, pp , [8] A. Garg, M. Critchlow, P. Chen, C. Van der Westhuizen, and A. Van der Hoek, An environment for managing evolving product line architectures, in Software Maintenance, ICSM Proceedings. International Conference on, 2003, pp

9 [9] M. Z. Eslami and M. J. van Sinderen, Flexible home care automation adapting to the personal and evolving needs and situations of the patient, in 3rd Int. Conference on Pervasive Computing Technologies for Healthcare, 2009, London, UK, Los Alamitos, CA, March 2009, pp [10] A. Sztajnberg, A. Rodrigues, L. Bezerra, O. Loques, A. Copetti, and S. T. Carvalho, Applying context-aware techniques to design remote assisted living applications, Int. Journal of Functional Informatics and Personalised Medicine, vol. 2, no. 4, pp , [11] A. Copetti, Monitoramento Inteligente e Sensível ao Contexto na Assistência Domiciliar Telemonitorada, Ph.D. dissertation, (em preparação) Instituto de Computação, Universidade Federal Fluminense, Niterói, RJ, Brasil, [12] A. Copetti, O. Loques, J. Leite, T. Barbosa, and A. da Nóbrega, Intelligent context-aware monitoring of hypertensive patients, in 1st Workshop for Situation Recognition and Medical Data Analysis. 3rd Int. Conference on Pervasive Computing Technologies for Healthcare, London, UK, [13] S. T. Carvalho, M. Erthal, D. Mareli, A. Sztajnberg, A. Copetti, and O. Loques, Monitoramento remoto de pacientes em ambiente domiciliar, in XXVIII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - Salão de Ferramentas, Gramado, RS, Brasil, may 2010, pp [14] C. Orwat, A. Graefe, and T. Faulwasser, Towards pervasive computing in health care A literature review, BMC Medical Informatics and Decision Making, vol. 8, p. 26, [15] M. ElHelw, J. Pansiot, McIlwraith et al., An integrated multi-sensing framework for pervasive healthcare monitoring, in 3rd Int. Conf. on Pervasive Comp. Technologies for Healthcare, april 2009, pp [16] P. Leijdekkers, V. Gay, and E. Lawrence, Smart homecare system for health tele-monitoring, in Digital Society, ICDS 07, jan. 2007, pp [17] S. T. Carvalho and O. Loques, Arquitetura de software para sistemas pervasivos de assistência domiciliar à saúde, in X Workshop de Informática Médica, XXX Congresso da Sociedade Brasileira de Computação, Belo Horizonte, MG, Brasil, jul 2010, pp [18] O. Loques, R. Cerqueira, A. Sztajnberg, and S. Ansaloni, A contractbased approach to describe and deploy non-functional adaptations in software architectures, Journal of the Brazilian Computer Society, vol. 10, no. 1, pp. 5 18, [19] L. Cardoso, A. Sztajnberg, and O. Loques, Self-adaptive applications using ADL contracts, Lecture Notes in Computer Science, vol. 3996, p. 87, [20] A. L. B. Rodrigues, L. N. Bezerra, A. Sztajnberg, and O. Loques, Self-adaptation of fault tolerance requirements using contracts, Computational Science and Engineering, IEEE International Conference on, vol. 2, pp , [21] L. X. T. Cardoso, Integração de serviços de monitoração e descoberta de recursos a um suporte para arquiteturas adaptáveis de software, Master s thesis, Instituto de Computação, Universidade Federal Fluminense, Niterói, RJ, Brasil, [22] C. Krueger, Variation management for software production lines, Software Product Lines, pp , [23] M. Goedicke, C. Köllmann, and U. Zdun, Designing runtime variation points in product line architectures: three cases, Science of Computer Programming, vol. 53, no. 3, pp , [24] M. Svahnberg, J. Van Gurp, and J. Bosch, A taxonomy of variability realization techniques, Software: Practice and Experience, vol. 35, no. 8, pp , [25] J. Lee and D. Muthig, Feature-oriented variability management in product line engineering, Communications of the ACM, vol. 49, no. 12, p. 59, [26] P. Fernandes, C. Werner, and L. Murta, Feature modeling for contextaware software product lines, in Twentieth International Conference on Software Engineering and Knowledge Engineering (SEKE 08), 2008, pp [27] D. A. S. Leal, Suportando a adaptação de aplicações pervasivas pelo uso de funções utilidade, Master s thesis, Instituto de Computação, Universidade Federal Fluminense, Niterói, RJ, Brasil, [28] B. Morin et al., Models at runtime to support dynamic adaptation, Computer, vol. 42, no. 10, pp , oct [29] D. Garlan, S. Cheng, A. Huang, B. Schmerl, and P. Steenkiste, Rainbow: Architecture-based self-adaptation with reusable infrastructure, Computer, vol. 37, no. 10, pp , [30] C. Braga, F. Chalub, and A. Sztajnberg, A formal semantics for a quality of service contract language, Electron. Notes Theor. Comput. Sci., vol. 203, no. 7, pp , [31] N. Bencomo, P. Sawyer, G. Blair, and P. Grace, Dynamically adaptive systems are product lines too: Using model-driven techniques to capture dynamic variability of adaptive systems, in 2nd Int. Workshop on Dynamic Software Product Lines, Limerick, Ireland, [32] M. Laguna, J. Finat, and J. González, Remote Health Monitoring: A Customizable Product Line Approach, Distributed Computing, Artificial Intelligence, Bioinformatics, Soft Computing, and Ambient Assisted Living, pp , [33] J. Lisbôa and O. Loques, Adaptação dinâmica guiada por contrato, in VII Latin American Conference on Pattern Languages of Programming - SugarLoafPloP 2008, [34] N. Bencomo, J. Whittle, P. Sawyer, A. Finkelstein, and E. Letier, Requirements reflection: Requirements as runtime entities, in International Conference on Software Engineering (ICSE), vol. 2, may 2010, pp