Simpósio de Informática. INForum Coletânea de comunicações do 5 o Simpósio de Informática

Tamanho: px
Começar a partir da página:

Download "Simpósio de Informática. INForum 2013. Coletânea de comunicações do 5 o Simpósio de Informática"

Transcrição

1 Simpósio de Informática INForum 2013 Coletânea de comunicações do 5 o Simpósio de Informática 5 e 6 de Setembro de 2013 Universidade de Évora Portugal Editores Beatriz Sousa Santos, Universidade de Aveiro João Cachopo, Instituto Superior Técnico

2

3 Prefácio Este volume contém as comunicações incluídas no programa da 5 a edição do Simpósio de Informática, INForum 2013, que se realizou na Universidade de Évora, nos dias 5 e 6 de setembro de O INForum encontra-se estruturado em várias sessões temáticas, que atraíram, no total, a submissão de 108 trabalhos que foram analisados pelas respectivas comissões científicas. Dos 108 trabalhos submetidos, foram selecionados 40 artigos completos, que estão incluídos nas atas da conferência, e 28 comunicações, que se encontram coligidas neste volume. O programa do INForum2013 incluiu, além destes trabalhos, duas sessões convidadas, cujos resumos estão nas atas do evento, e uma sessão dedicada aos Desafios da Indústria de Informática em Portugal cujas comunicações são também incluídas neste volume. Aveiro e Lisboa, Setembro de 2013 Beatriz Sousa Santos e João Cachopo iii

4 iv

5 Organização Presidentes da Comissão de Programa Beatriz Sousa Santos João Cachopo Universidade de Aveiro & IEETA Instituto Superior Técnico & INESC-ID Comissões de Programa das Sessões Temáticas Bioinformática Alexandre Francisco Ana Teresa Freitas Arlindo Oliveira Armando Pinho Claudine Chaouiya Francisco Couto José Luís Oliveira Luís Russo Mário Silva Miguel Rocha Pedro Tiago Monteiro Rui Camacho Rui Mendes Sara Madeira Vítor Costa Instituto Superior Técnico & INESC-ID Instituto Superior Técnico & INESC-ID Instituto Superior Técnico & INESC-ID Universidade de Aveiro Instituto Gulbenkian de Ciência Universidade de Lisboa Universidade de Aveiro Instituto Superior Técnico & INESC-ID (coordenador) Instituto Superior Técnico & INESC-ID Universidade do Minho INESC-ID (coordenador) Universidade do Porto Universidade do Minho Instituto Superior Técnico & INESC-ID Universidade do Porto Ciência e Engenharia de Software (SOFT-PT) Alberto Silva Ana Paula Tomás Antónia Lopes António P. Guerreiro Oliveira António Rito Silva Instituto Superior Técnico & INESC-ID Universidade do Porto Universidade de Lisboa Portugal Telecom Instituto Superior Técnico & INESC-ID v

6 João Cachopo João Costa Seco João Pascoal Faria João Paulo Fernandes José Nuno de Oliveira Luís Barbosa Luís Caires Luís Lopes Marco Vieira Nestor Catano Nuno Silva Rui Maranhão Salvador Abreu Simão Melo de Sousa Tiago L. Alves Vasco Vasconcelos Instituto Superior Técnico & INESC-ID Universidade Nova de Lisboa Universidade do Porto Universidade da Beira Interior Universidade do Minho Universidade do Minho Universidade Nova de Lisboa Universidade do Porto Universidade de Coimbra Universidade da Madeira Critical Software Universidade do Porto Universidade de Évora Universidade da Beira Interior (coordenador) OutSystems Universidade de Lisboa Computação Gráfica Abel Gomes Adérito Marcos Adriano Lopes Ana Paula Cláudio António Augusto Sousa António Fernando Coelho António Ramires Fernandes Fernando Birra Francisco Morgado Frutuoso Silva João Madeiras Pereira Joaquim Madeira Luís Gonzaga Magalhães Luís Marcelino Luís Paulo Santos Manuel João Fonseca Maria Beatriz Carmo Maximino Bessa Miguel Leitão Paulo Dias Pedro Moreira Teresa Chambel Universidade da Beira Interior Universidade Aberta Universidade Nova de Lisboa Universidade de Lisboa (coordenador) Universidade do Porto Universidade do Porto & INESC TEC (coordenador) Universidade do Minho Universidade Nova de Lisboa Instituto Politécnico de Viseu Universidade da Beira Interior (coordenador) Instituto Superior Técnico & INESC-ID Universidade de Aveiro Universidade de Trás-os-Montes e Alto Douro Instituto Politécnico de Leiria Universidade do Minho Instituto Superior Técnico & INESC-ID Universidade de Lisboa Universidade de Trás-os-Montes e Alto Douro Instituto Superior de Engenharia do Porto IEETA & Universidade de Aveiro Instituto Politécnico de Viana do Castelo Universidade de Lisboa Computação Móvel e Ubíqua Adriano Moreira Universidade do Minho vi

7 Ana Aguiar Ana Paula Afonso António Coelho Carlos Baquero Filipe Pacheco Helena Rodrigues Hugo Miranda João Barreto Jorge Sá Silva Nuno Preguiça Paulo Ferreira Ricardo Morla Rui José Sérgio Duarte Susana Sargento Teresa Romão Universidade do Porto Universidade de Lisboa Universidade do Porto Universidade do Minho Instituto Superior de Engenharia do Porto Universidade do Minho (coordenador) Universidade de Lisboa Instituto Superior Técnico & INESC-ID Universidade de Coimbra Universidade Nova de Lisboa Instituto Superior Técnico & INESC-ID Universidade do Porto Universidade do Minho Universidade Nova de Lisboa Universidade de Aveiro Universidade Nova de Lisboa Computação Paralela, Distribuída e de Larga Escala (CPDLA) Alysson Bessani António Sousa Filipe Araújo Hervé Paulino Hugo Miranda Jorge Gomes João Lourenço João Paulo Carvalho José Orlando Pereira Lúcio Ferrão Luís Rodrigues Luís Veiga Manuel Barata Mário David Paula Prata Pedro Furtado Ricardo Fonseca Vitor Duarte Universidade de Lisboa (coordenador) Universidade do Minho Universidade de Coimbra Universidade Nova de Lisboa Universidade de Lisboa Laboratório de Instrumentação e Física Experimental de Partículas Universidade Nova de Lisboa Instituto Superior Técnico & INESC-ID Universidade do Minho OutSystems Instituto Superior Técnico & INESC-ID Instituto Superior Técnico & INESC-ID (coordenador) Instituto Superior de Engenharia de Lisboa Laboratório de Instrumentação e Física Experimental de Partículas Universidade da Beira Interior Universidade de Coimbra ISCTE Instituto Universitário de Lisboa Universidade Nova de Lisboa Gestão de Dados e Conhecimento Alberto Simões António Lucas Soares Universidade do Minho Universidade do Porto vii

8 Bruno Martins David Matos Diana Santos Fernando Batista Francisco Couto Helena Galhardas Hugo Gonçalo Oliveira Irene Rodrigues João Dias Pereira João Paulo Cordeiro João Pedro Silva Luísa Coheur Miguel Grade Nuno Mamede Nuno Silva Paulo Gomes Paulo Maio Paulo Novais Paulo Oliveira Paulo Quaresma Pável Calado Ricardo Daniel Ribeiro Instituto Superior Técnico & INESC-ID (coordenador) Instituto Superior Técnico & INESC-ID Universidade de Oslo ISCTE Instituto Universitário de Lisboa & INESC-ID (coordenador) Universidade de Lisboa Instituto Superior Técnico & INESC-ID Universidade de Coimbra Universidade de Évora Instituto Superior Técnico & INESC-ID Universidade da Beira-Interior Tebe SA Instituto Superior Técnico & INESC-ID Maisis Lda Instituto Superior Técnico & INESC-ID Instituto Superior de Engenharia do Porto Universidade de Coimbra Instituto Superior de Engenharia do Porto (coordenador) Universidade do Minho Instituto Superior de Engenharia do Porto Universidade de Évora Instituto Superior Técnico & INESC-ID ISCTE Instituto Universitário de Lisboa Segurança de Sistemas de Computadores e Comunicações Alysson Bessani Carlos Serrão Edmundo Monteiro Henrique Domingos José Alegria José Manuel Valença Manuel Barbosa Miguel Correia Mário Freire Mário Zenha Rela Nuno Neves Paul Andrew Crocker Pedro Adão Ricardo Chaves Universidade de Lisboa / LASIGE ISCTE Instituto Universitário de Lisboa Universidade de Coimbra / CISUC Universidade Nova de Lisboa Portugal Telecom Universidade do Minho Universidade do Minho Instituto Superior Técnico & INESC-ID Universidade da Beira Interior Universidade de Coimbra / CISUC Universidade de Lisboa / LASIGE Universidade da Beira Interior Instituto Superior Técnico & SQIG-IT (coordenador) Instituto Superior Técnico & INESC-ID (coordenador) Sistemas Embebidos e de Tempo-Real Carlos Almeida Instituto Superior Técnico viii

9 Helder Silva João Cunha João M. P. Cardoso Joaquim Ferreira Jorge Sousa Pinto José Metrôlho José Miguel Faria José Rufino Leonel Sousa Luís Almeida Luís Ferreira Luís Gomes Luís Miguel Pinho Luís Osório Mário Calha Nelma Moreira Nelson Blanco Nuno Silva Paulo Bartolomeu Paulo Pedreiras Ricardo Machado EDISOFT Instituto Superior de Engenharia de Coimbra Universidade do Porto Universidade de Aveiro Universidade do Minho (coordenador) Escola Superior de Tecnologia do Instituto Politécnico de Castelo Branco Educed Lda Universidade de Lisboa Instituto Superior Técnico & INESC-ID Universidade do Porto Instituto Superior de Engenharia do Porto / CISTER Universidade Nova de Lisboa Instituto Superior de Engenharia do Porto / CISTER Instituto Superior de Engenharia de Lisboa Universidade de Lisboa Universidade do Porto PDM&FC Critical Software, S.A. Micro I/O Universidade de Aveiro Universidade do Minho Sistemas Inteligentes António Abelha César Analide Goreti Marreiros Helder Coelho João Balsa José Cascalho José Machado José Neves Luis Macedo Manuel F. Santos Paulo Moura Oliveira Paulo Novais Paulo Trigo Paulo Urbano Pedro Mariano Ricardo Costa Rosaldo Rosseti Universidade do Minho Universidade do Minho (coordenador) Instituto Superior de Engenharia do Porto Universidade de Lisboa Universidade de Lisboa (coordenador) Universidade dos Açores Universidade do Minho Universidade do Minho Universidade de Coimbra Universidade do Minho Universidade de Trás-os-Montes e Alto Douro Universidade do Minho Instituto Superior de Engenharia de Lisboa Universidade de Lisboa Universidade de Lisboa Escola Superior de Tecnologia e Gestão de Felgueiras Universidade do Porto ix

10 Comissão Organizadora José Luís Faria José Saias Luís Rato Paulo Quaresma Teresa Gonçalves Vasco Pedro Vitor Nogueira Universidade do Minho (webmaster) Universidade de Évora (patrocínios e publicidade) Universidade de Évora (organizador local) Universidade de Évora (organizador local) Universidade de Évora (organizador local) Universidade de Évora (tesouraria) Universidade de Évora (logística local) Comissão Coordenadora Ana Moreira Antónia Lopes António Casimiro José Orlando Pereira Luís Caires Luís Rodrigues Luís S. Barbosa Miguel P. Correia Raúl Barbosa Rui Oliveira Simão Sousa Teresa Gonçalves Universidade Nova de Lisboa (presidente) Universidade de Lisboa Universidade de Lisboa Universidade do Minho Universidade Nova de Lisboa Instituto Superior Técnico & INESC-ID Universidade do Minho Instituto Superior Técnico & INESC-ID Universidade de Coimbra Universidade do Minho Universidade da Beira Interior Universidade de Évora x

11 Revisores Adicionais A Almeida, José Bacelar Arrais, Joel Arriaga, Afonso B Broda, Sabine C Cogo, Vinicius V. Craveiro, João Pedro Crocker, Paul Cruz, Nuno Cunha, Jácome D Domingues, Miguel F Ferreira, Anibal Fonte, Victor Francisco, Alexandre G Garcia, Miguel Germano, José Gonçalves, Tiago L Leitão, João Lima, Rui Lourenço, Luís Miguel M Martins, Francisco Martins, Pedro Mendes, Nuno Monteiro, Edmundo N Neves, Samuel Nogueira, André Nunes, José Luís P Pedro, Jose Pereira, David Pereira, Manuela Pereira, Mário Pinheiro, Nuno Pinto, Ricardo C. Pombinho, Paulo Portela, Bernardo R Ramos, Miguel S Santos, André Santos, Bernardo Sousa, Joao V Vieira, Barbara xi

12 xii

13 Índice Prefácio Organização Revisores Adicionais iii v xi Desafios da Indústria de Informática em Portugal 1 2 Quality Assurance Challenges in the OutSystems Platform Tiago L. Alves 5 GeoSOL: Plataforma de análise, registo e acompanhamento de instalações solares José Alexandre Correia, Vasco Pinheiro, and Miguel Feliz 6 Voo em Formação e Controlo Cooperativo Francisco Costa, Rui Lopes and Nuno Silva Bioinformática 8 9 Risk aware Data Management in Metagenomics Filipe Ferreira, Miguel Coimbra, Ricardo Vieira, Diogo Proença, Ana Freitas, Luís Russo and José Borbinha 21 EpiLog: a novel tool for the qualitative modelling of epithelial patterning Pedro L. Varela, Nuno D. Mendes, Pedro T. Monteiro, Adrien Fauré and Claudine Chaouiya Ciência e Engenharia de Software Suporte a Testes Automáticos em Aplicações Web geradas com a OutSystems Platform Ricardo Neto, Tiago L. Alves and Fernando Carvalho 39 Localização de Elementos na Interface Gráfica com Base no Código Fonte Sérgio Silveira and André Santos 51 Prevenção de Violações de Atomicidade usando Contractos Diogo G. Sousa, Carla Ferreira and João Lourenço Computação Gráfica Ambientes Urbanos Virtuais para a Web Joana Barbosa, António Coelho and Carlos Rebelo 76 Interactive visualization of 3D models in WebGL Ricardo Pesqueira and Frutuoso Silva Computação Móvel e Ubíqua Planeador colaborativo de deslocações de bicicleta em meio urbano Nelson Nunes and João Barreto xiii

14 94 Application Synchronisation on Public Displays based on PubSubHubbub Manuel Pereira, Maria João Nicolau and Helena Rodrigues Computação Paralela, Distribuída e de Larga Escala Task allocation in Transactional Memory with Thread Level Speculation Ricardo Filipe and João Barreto 112 Estimativa da Divergência de Réplicas em Sistemas Geo-replicados Andy Gonçalves, Valter Balegas, Sérgio Duarte, Rodrigo Rodrigues and Nuno Preguiça 120 Replicação Multi-nível de Bases de Dados em Memória Helder R. Laximi Martins, João Soares, João Lourenço and Nuno Preguiça Gestão de Dados e Conhecimento Conceção de um Data Warehouse Espácio-Temporal para Análise de Trajetórias Humanas Vitor Oliveira, Ana P. Afonso and André O. Falcão Segurança de Sistemas de Computadores e Comunicações Improving Intrusion Detection Systems by means of Knowledge Sharing based on Social Networks Amir Azhdari and Edmundo Monteiro 155 Biometric and Behavioral Identification of Users in Intrusion Scenarios Henrique Martins, Ricardo Azevedo, Paulo Novais and Ângelo Costa 167 Secure Password Management With Smart Cards Nuno Pinheiro, Ricardo Chaves and Carlos Ribeiro Sistemas Embebidos e de Tempo-Real Fault Detection in Time- and Space-Partitioned Systems Kleomar Almeida, Ricardo Correia Pinto and José Rufino 187 SPARK-BMC: Checking SPARK Code for Bugs Cláudio Belo Lourenço, Victor Cacciari Miraldo, Maria João Frade and Jorge Sousa Pinto 199 Requirements for Real-Time Embedded Systems: A study on semi-automated verification Nuno Silva, Rui Lopes and Francisco Costa 211 Wireless Platform to Acquire Biosignals for Human Stress Detection Paulo Simões, Margarida Urbano and José Fonseca Índice de Autores 223 xiv

15 Desafios da Indústria de Informática em Portugal 1

16 Quality Assurance Challenges in the OutSystems Platform Tiago L. Alves OutSystems, Linda-a-Velha, Portugal OutSystems Platform is a software product to rapidly create and maintain industrial-grade web and mobile applications. The product consists of 5 main components that usually are jointly released in a one-year cycle. On the desktop there are 2 main components: Service Studio (integrated development environment) and Integration Studio (tool to extend the platform with custom, traditional code and integrate with existent applications/databases). On the server, there are 3 components: Service Center (operations management console), Lifetime (application lifecycle management tool), and Platform Server (services and libraries that are the backbone of the server components). The key differentiator of the OutSystems Platform is that all tasks can be accomplished visually with simple user interactions. As example the addition of an if clause in a business logic block, the creation of database table or web page, and the deployment of a full environment of applications must all be equally easy to perform by a non-expert user. The visual simplicity is the top-priority concern when developing any new feature. Hence, a large part of the design and development phases deal in making the user-visible part intuitive and the main tasks easy to understand and accomplish. The Service Studio 1-CP (1 Click Publish) functionality, for example, is visible to the user as a single button that makes an application ready to use. Internally, this involves the following: (1) serializing the model of a web application and sending it to Service Center to automatically make revisions of it; (2) the Service Center then orchestrates its code generation (either in C# or Java code) and its compilation (by calling the standard C# or Java compilers, respectively); (3) generation and execution of Data Description Language (DDL) scripts (to modify/create the necessary database structures); and, (4) deployment of the application into a web application server such as the Oracle WebLogic server. As further examples, the compilation itself makes use of data-flow analysis to ensure the output code is optimized and only the parts of the model that were affected by change are sent to the compiler. Not only the components internal of the OutSystems Platform are highly sophisticated, but also there is a myriad of sophisticated technology that helps developing and maintaining such components. For instance, the model that holds the details of a web application is shared among the Service Studio IDE and the OutSystems Compiler (a sub-component of the Platform Server). The definition of this model (meta-model) is stored in a file serving as input to OutSystems internal tools 2

17 to automatically generate specific optimized versions of this model for Service Studio and for the code generator, and to automatically generate parts of the IDE itself. The sophistication of the OutSystems Platform and its internal components pose many challenges to their quality assurance both at functional and nonfunctional levels. Thousands of tests were developed to automatically ensure each of these components work as specified with the introduction of new changes. These tests run for several supported versions of the OutSystems Platform, spanning different configurations of operating systems, databases, and web application servers. The current test infrastructure makes use of over one hundred machines that support building, testing (regression for different configurations, installer, and performance tests) and other quality assurance related tasks. Because of the focus on the user, most tests were created taking into account how the user interacts with the system. This natural process of thinking led to the creation of many system-level tests that have small differences between them and that have a high maintenance cost. Estimates within the company have pointed that around 30% of the total engineering time is spent just maintaining those tests. Based on the literature and good practices we are identifying ways to attack those problems. By looking to our own test issues we laid out three provocative challenges for which we believe there is no appropriate scientific insight: (1) capture the essence of a test; (2) identify the ROI of a test; and (3) eliminate the overhead of the co-evolution of code and tests. With respect to the first challenge, capturing the essence of a test, literature approaches it by introducing levels of testing. Focusing on functional testing, the most known levels of testing are unit testing, integration testing, and system testing. Although these levels are well known, identifying the testing level is not that clear from the moment that the underlying code depends of some library. The situation is even worse, when considering functional, acceptance or regression tests, which in practice are concepts hard to match with the code under test. Creating tests for each level is recommended to address well-known risks. Unit tests address that the individual functionality works, integration tests address the interoperability of two or more components, and system tests address the functionality of the overall scenarios. However, creating and maintaining suites for each type of tests is a daunting task leading in many cases to not creating tests at all or creating tests at the wrong levels. With respect to the second challenge, the ROI of a test, literature approaches it using test coverage adequacy criteria. The most well known criteria are statement and branch coverage, falling under the category of structural testing. Other categories exist such as fault-based testing or error-based testing. In theory all of these criteria could be implemented, possibly, to the extent of test creation budget to be a magnitude higher than creating the code itself. The decision of which criterion to apply can be based on some notion of risk (more scientific) or good sense (not scientific), yet none of them provide a clear indication about the value of creating a new test or adding a new test to the current test suite. Finally, with respect to the third challenge, eliminate the overhead of the co-evolution 3

18 of code and tests, this is addressed by putting the tests as close as possible to the code under test. In unit tests there are good practices to help achieving this such as, in Java, mimicking the package and class structure, and using in test method s name the method under test name. For integration or system tests it is more difficult to apply these good practices. Additionally, mimicking the code structure only solves part of the overall problem, since code changes can require the effort of maintaining the tests. In this presentation, we will introduce the OutSystems Platform, and present a brief overview of the current quality assurance challenges. We will present a brief overview of the solutions we are putting in place to overcome those challenges. Based on those solutions we introduce three future challenges: (1) capture the essence of a test; (2) identify the ROI of a test; and (3) eliminate the overhead of the co-evolution of code and tests. For each future challenge we present the industrial motivation behind it and foster the discussion to find new research directions. 4

19 GeoSOL: Plataforma de análise, registo e acompanhamento de instalações solares José Alexandre Correia, Safira Vasco Pinheiro, Focus-BC Miguel Feliz, ADENE Em finais de 2012, um consórcio constituído pela Safira, ADENE, Focus-BC, Closer e FCT submeteram ao QREN um projeto ambicioso para o desenvolvimento de uma plataforma de análise, registo e acompanhamento de instalações solares denominado GeoSOL. O GeoSOL pretende ser uma plataforma multiorganização, multi-país, multi-lingua, multi-moeda com as seguintes funcionalidades: Carregamento de dados geográficos em diferentes formatos para descrição de modelos 3D de bairros, cidades, regiões e países; Modelação e cálculo de algoritmos para análise do potencial solar de cada espaço urbano (e.g. telhados) ou áreas rurais; Disponibilização de um portal com mapas para qualquer utilizador avaliar a capacidade solar da sua casa, do seu prédio ou do seu escritório; Registo e carregamento de informação relativa a oferta comercial a nível de sistemas de energia solar (térmica e fotovoltaica); Registo e carregamento das diversas instalações solares existentes (e.g. em Portugal seria a base de dados das Renováveis na Hora ); Possibilidade da recolha efetiva da energia produzida nas diversas instalações solares existentes; Realimentação dos valores de energia efetiva no cálculo do potencial solar; Cálculo analítico da previsibilidade de produção de energia solar futura. Apesar destes requisitos serem já muito ambiciosos para o projeto, existe um caminho de novas funcionalidades que o consórcio está já a pensar. Este projeto apresenta diversos desafios do ponto de vista computacional. A nível de SIG temos a diversidade de modelos de dados geográficos que existem, de como os importar e trabalhar, e como conseguir o produto final de modelos 3D. Na componente computacional temos os grandes volumes de informação geográfica e de como aplicar algoritmos para cálculo do potencial solar, algo que apenas se consegue recorrendo a paradigmas de alocação de recursos dinâmicos conseguidos através da Cloud. A possibilidade de recriar silos de plataformas GeoSOL para diferentes entidades ou países, mais uma vez recorrendo à computação Cloud. Na componente de dados de consumo existem desafios a nível de BigData dado o grande volume de informação e no seu tratamento para realimentação de modelos, bem como no cálculo analítico de previsibilidade futura. A apresentação irá focar o âmbito e desafios do projeto, bem como fazer uma breve demonstração do que já se encontra implementado. 5

20 Voo em Formação e Controlo Cooperativo Francisco Costa, Rui Lopes, and Nuno Silva Critical Software SA Parque Industrial de Taveiro, Lote 48, Coimbra, Portugal {fm-costa, rmlopes, A Exploração Espacial teve início há cerca de 50/60 anos. Este período caracteriza-se por um total domínio das agências governamentais (e.g., NASA, ROSCOSMOS, ESA, JAXA) no sector, com motivações políticas, estando reservado para a Indústria um papel secundário, de subcontratados, sem grande envolvimento na definição das missões ou objectivos a longo prazo. No entanto, actualmente observa-se uma mudança de paradigma. Com a queda do peso político da Exploração Espacial e com cortes orçamentais nos países mais desenvolvidos, tem-se observado um menor investimento governamental nas Agências Espaciais, tornando a sua acção e envolvimento mais limitado. Um dos exemplos da mudança de paradigma foi a decisão de cancelar o programa dos Vaivéns Espaciais por parte da NASA, entregando toda a responsabilidade do desenvolvimento de veículos espaciais para a Indústria. Com o maior envolvimento da Indústria, diversas novas empresas lançaram-se no sector, criando um dinamismo até agora nunca observado. Trata-se efectivamente, de uma nova Era na Exploração Espacial. Uma das mudanças mais visíveis da nova liderança da Indústria no sector é a obsessão pela redução de custos. Tendo sido o custo algo secundário durante a primeira Era da Exploração Espacial, este factor é essencial numa Era onde se espera grande competição entre diversas empresas. Esta abordagem de redução de custos é particularmente visível no interesse das empresas espaciais nos chamados Nano-satélites. A redução da complexidade dos satélites e a tentativa de normalização dos mesmos, traz enormes ganhos em termos de custo, quer no facto de se conseguir uma optimização dos custos de produção (i.e. produção em escala) como na redução de custos de lançamento. Além disto, permite um desenvolvimento incremental de uma determinada missão, facilitando também as necessidades de financiamento, e provando a viabilidade da missão ao efectuar colocações em órbita faseadas. Um dos grandes desafios que se coloca no desenvolvimento de constelações de nano-satélites é a necessidade de um controlo de voo e missão cooperativo entre os diversos satélites que constituem a constelação. Enquanto a abordagem anterior permitia colocar toda a inteligência e instrumentos em apenas um único satélite, a interacção entre os diversos nano-satélites é essencial para o cumprimento da missão, dado que os diversos instrumentos poderão estar dispersos pelos diversos satélites. 6

21 O desenvolvimento de teorias de Controlo Cooperativo aplicados ao sector Espacial é neste momento de enorme interesse tendo em conta aquilo que se perspectiva para a nova Era da Exploração Espacial. Trata-se de uma matéria onde as Universidades Portuguesas podem rapidamente desenvolver trabalho relevante e de grande aplicação prática na Indústria. Este trabalho deverá ser efectuado com estreita colaboração com a Indústria Portuguesa, aproveitando todo a sua experiência no sector mediante a criação de grupos de pesquisa/clusters de investigação, programas de doutoramento, entre outros. Tendo em consideração a evolução do sector da Exploração Espacial, tratase de um momento chave para a cooperação entre Universidades e Indústria Portuguesa. O know-how de desenvolvimento técnico que diversas empresas portuguesas já possuem permite-lhes colocarem-se numa posição privilegiada para o desenvolvimento de nano-satélites. A cooperação com as Universidades Portuguesas poderá trazer a resolução dos desafios que permanecem por resolver, contribuindo para o desenvolvimento económico num sector do qual se espera considerável expansão no futuro próximo. 7

22 Bioinformática 8

23 Risk aware Data Management in Metagenomics Filipe Ferreira, Miguel E. Coimbra, Ricardo Vieira, Diogo Proença, Ana T. Freitas, Luís M. S. Russo, José Borbinha INESC-ID / IST, Universidade de Lisboa, Portugal Abstract. The concept of e-science applies to science that, increasingly, is executed through distributed global collaborations where extensive data collections are processed by large scale computing resources through scientific workflows. These data can be heterogeneous, with multiple provenances, created and transformed according to different data schemas, and the processing can be distributed by multiple locations. This emerging reality brings new challenges, like the preservation of these data workflows. To address specific concerns with Data Management (DM), the concept of Data Management Plan (DMP) was established. However, we claim actual guidelines for DMP ignore achievements by the digital preservation community indicating DM should be mainly a Risk Management (RM) activity. Therefore, we propose to reanalyze the concept of DMP considering the best practices of RM, and claim the concept should be complemented by a Risk Management Plan. The motivation, requirements and validation of this proposal is the project MetaGenFRAME, focused in Metagenomics. Keywords: Risk Management, Digital Preservation, E-Science, Data Management Plan, Bioengineering, Metagenomics. 1 Introduction The term e-science usually applies to science that, increasingly, is being carried out through distributed global collaborations, comprising the processing of extensive data sets, and the usage of large scale computing resources [15]. The e-science paradigm leads to new challenges, such as sharing information through distributed locations and the usage of processes that generate large data sets requiring large storage capacity. As a consequence, the concept of Data Management Plan (DMP) has been defined, intended to support the governance, in the context of a specific project, of the data to be created, stored, and shared. However, we can claim actual guidelines for DMP do not include important lessons and guidelines from the Digital Preservation (DP) community, especially those indicating DP should be mainly a Risk Management (RM) activity. Furthermore, there is no process defined on how to apply RM to an e-science project and based on the outcome how to define the corresponding DMP. Therefore, this article focus on determine a methodology for 9

24 defining a DMP using RM based processes. We believe that this method, initially developed and validated under the motivation of the MetaGenFRAME project [18], can be generalized for the field of Bioengineering, which is a heterogeneous area, comprising biology, medicine, bioinformatics, etc. In this sense, we understand MetaGenFRAME as an e-science biology project, focused on the definition of workflows for Metagenomics, which focuses on sequence analysis and genome annotation. This paper is structured as follows: Section 2 outlines the principles of e-science, scientific workflows, Data Management (DM) and DMP. Section 3 introduces the concepts of DP, RM and Risk Management Plan (RMP). Section 4 identifies a set of typical components of a DMP, according to the actual sate of the art, and a respective generic risk analysis. Section 5 describes the MetaGenFRAME project, as well as its specific risk analysis. Section 6 presents hypothesis for the alignment of a DMP and a RMP. Section 7 presents some conclusions and future work. 2 Data Management in e-science E-Science is defined as a global collaboration in key areas of science and the next generation of infrastructure that enables it, being characterized by aspects that deliver added value to the scientific enterprise [7], namely allowing researcher s collaboration, increase use of interconnected computers, enabling high performance visualization of data and the electronic distribution and publication of findings. 2.1 Scientific workflows Scientific workflows are crucial to e-science, being the means by which scientists execute, reconfigure and rerun their analysis in a repeatable and verifiable way [12]. These workflows typically involve many steps, and access to large amounts of data [13]. Each workflow lifecycle has phases for (i) generation, where the analysis is defined; (ii) planning, where the resources are selected; (iii) execution, where the computations are run; (iv) the result, metadata, and provenance storing [13]. 2.2 Data Management DM is an integral part of e-science. It involves cooperative work, data security and archiving. It allows researchers to produce higher quality data, increase the exposure for their research, and protect data from being lost or misused [17]. The scientific community has increasingly perceived concerns about DM, especially with the issues characteristic of e-science, namely data s provenance, sharing, access and archival [17]. As a result of these concerns, research funders have been increasingly requesting the inclusion of a DMP as part of the project s proposals. A typical DMP describes what and how data will be created, stored, and shared, with two major purposes [17]: (i) guide researchers to reuse data; (ii) record the project s DM decisions. 10

25 3 Digital Preservation as a Risk Management Approach DP aims to keep digital objects accessible over long periods of time [10]. For that, it is imperative to be able to verify, at any time that these digital objects are what they claim to be. Hence data must be trustworthy, guaranteeing the content is integral and authentic. Information provenance must be assured to guarantee data s traceability. DP environments might require scalability to face technology s evolution achieved through replacement of technological components, thus implying heterogeneity [8]. RM identifies, assesses and mitigates risks to an acceptable level. It manages risks i.e. the uncertainty associated with events which can affect assets [1] [8]. A risk can be positive (opportunity), or negative (vulnerability) that can be explored by threats. 3.1 Risk Management standards Standards, methods and tools for RM, vary with the market sector, type of business or organizational activities [11]. However, there are also standards that focus on defining the generic terminology, process, principles, methods and techniques such as: Risk management Vocabulary. ISO Guide 73:2009. Geneva, Switzerland : ISO [1]; Risk Management - Principles and guidelines. ISO FDIS 31000:2009. Geneva, Switzerland : ISO [2]; Risk management - Risk assessment techniques. ISO IEC 31010:2009. Geneva, Switzerland : ISO [3]; There are other relevant standards that need to be mentioned in the RM area spread throughout several fields. These are represented in Table 1: Table 1. - RM Standards Area Standard ISO/IEC [4] Risk IT Framework [5] Security Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) [6] NIST, Risk Management Guide for Information Technology Systems [9] Banking Value-at-Risk (VaR) [26] Digital Repository Audit Method Based on Risk Assessment DP (DRAMBORA) [27] AIRMIC, ALARM, IRM (AAIRM) [28] Enterprise Management of Risk (M_o_R) [14] frameworks Committee of Sponsoring Organizations of the Treadway Commission Enterprise Risk Management (COSO ERM) [16] 11

26 3.2 The Risk Management process according to ISO - FDIS The ISO proposes a reference process to execute RM properly [2] (Fig. 1). Fig. 1. ISO RM Process That process proposes that first the context, strategic objectives and the risk criteria of RM must be defined [8]. The next step is Risk Assessment, which is composed by three distinct phases: risk identification, which generates the list of risks [8]; risk analysis, that considers the impacts and probabilities to determine the risk level; and risk evaluation, to determine what risks need treatment or can be only controlled. The next step is risk treatment, where one or more options are selected to treat risks. Communication and review take place in all previous stages. 3.3 Risk Management Plan A RMP defines the scope and process for the identification, assessment and treatment of risks. The objective of this plan is to define the strategy to manage risks of an organization or project with the minimal impact on cost and schedule, as well as operational performance. The RMP is considered a living document, being updated as needed. A typical RMP comprises the following steps: (i) Planning, (ii) Risk Assessment, (iii) Risk Treatment, (iv) Risk Control and Monitor; 4 Risk aware Data Management The policies that are described in a DMP are specific to the performed research. Researchers might have diverse purposes, resulting in different instances of DMP. However, some issues are common allowing the definition of general DMP guidelines. Table 2 shows a comparative analysis of DMP guidelines, namely the Digital Curation Center (DCC), the Australian National University (ANU) and the 12

27 National Science Foundation (NSF) for the fields of Engineering and Biology. In that table we already point where we belive a RMP can be relevant. Table 2. Comparison of DMP Guidelines (present(x), not present (-)) Organizations DCC ANU NSF (Eng) Typical Sections in a DMP NSF (Bio) Ethics and Privacy X - - X X Resourcing (Budget) X X - - X Data Dissemination, Sharing and To delegate to a RMP X X X X X Licensing Data Storage, Preservation and Security X X X X X Data Owners and Stakeholders - X X X - Responsibilities - X X X - Data Formats and Metadata X X X X X Products of Research and Documentation - X X X X These sections and their relation with a potential RMP refer to the follwing: Ethics and Privacy: Ethical requirements apply particularly when the research involves animal subjects. These include the purpose and nature of the research, the nature of consent needed and what data must be safeguarded and destroyed. This raises risks that need to be attended, and therefore a RMP should be useful to do so. Examples of ethical risks of the use of genomes can be found in [21]; Resourcing: Appropriate funds should be allocated to DM, namely in time allocations, management of technical aspects, training requirements, storage and backup, etc. In case of lack of funding, DP risks will arise 1, namely, the entire research might not be developed due to lack of the appropriated infrastructures or personal, and the data generated might no longer be stored and maintained. Data Dissemination and Licensing: Requirements for dissemination of the research results, which involves licensing measures; Dissemination incurs risks that must be dealt with a cost-benefit analysis to determine if the value outweighs the liabilities. A RMP would be appropriate to perform such a task. Examples of risks associated with data sharing can be found in [22, 23]; Data Storage, Preservation and Security: Requirements for storing data, in a short or long term as well as maintaining the data secure from intentional or nonintentional attacks. RM would be helpful through a RMP; Examples of risks associated with data storing and security can be found in [23]; Data Owners and Stakeholders: List of the owners and stakeholders of the data; Responsibilities: Lists who will be responsible for ensuring each item in the DMP, as well as, who is responsible for reviewing and modifying it; 1 13

28 Data Formats and Metadata: Describe the file formats used, as well as, the metadata form used in the project. RM would be helpful in achieving these goals through a RMP. Examples of risks associated with metadata can be found in [24]; Products of Research and Documentation: Determines all data collected, how and the amount. Indicates what needs to be documented, when and how. RM would be helpful through a RMP. Examples of risks associated with lack of documentation, namely data provenance, can be found in [25]; Associated with the former sections, namely those who were delegated to a RMP, there are some typical risks and challenges of e-science and its workflows regarding the typical DP vulnerabilities and threats [8,23,24]: Workflow s traceability: Scientists need to know how a workflow was executed and what produced. The dependencies among tasks in a workflow must also be known. The workflow s input parameters must be saved so it can be rerun. Users and workflows must interpret information produced by unfamiliar workflows. Data reuse: Collaboration between systems that are controlled by different entities, leads to the need for a unique means of data s representation and communication. In e-science, if a field of study is relatively new, it may be plagued by a lack of standards, which makes data reuse much more challenging. Intentional attacks: Unauthorized access can lead to stolen or modified data. In e- Science workflows that allow the automatic configuration of script-invoked software, the applications may communicate data to remote locations. Financial changes: Lack of financial resources to store and maintain all the data or bankruptcy of the organization responsible for managing the data. Organizational changes: Political or management changes in the entities responsible for data preservation can disturb data storage, sharing and reuse. Web content erosion: Online reference s small life spans, due to failed or broken links, turn this data s storage and dissemination for future reuse, more dificult. Data sharing: In e-science sharing data raises several challenges: Integrity of data: Scientific data must be used and reused retaining its characteristics and content. Data confidentiality: Sharing personal and confidential data can compromise privacy. The gravity varies between processing an individual's personal information or a collective entity's activity details. Intellectual property: Scientists can take the credit for other s research. Data management: Sharing data in a distributed environment hardens its physical management causing difficulties identifying the data set s location. Data set s size: Applications can generate petabyte-size data sets. Lack of storage space can be catastrophic, since some experiments can only be executed once. Data obsolescence: It s necessary to access what data becomes outdated. It s also vital to address how or who should delete this information. Infrastructure obsolescence: The software and hardware supporting workflows can become outdated. Legacy infrastructures may not have metadata support. Natural disasters: Data must survive events like earthquakes, floods or fires. Human errors: Data can be unintentionally deleted or modified. 14

29 Infrastructure faults: Hardware, software or network faults can compromise the storage, communication or analysis of data and the workflow s execution. DP techniques [8] can be applied to mitigate the former risks shielding digital objects, which represents the main goal of RM, meaning RM should be used to help attend the former risks. With this in mind, an alignment between DP, RM and e- Science is needed, from which DP represents a main concern [20]. As DP is a concern in a DMP, and, as stated before, DP can be seen as a RM problem, RM principles already identified in DP should be used to help define a DMP. 5 A case in Bioengineering: The MetaGenFRAME Project The MetaGenFRAME project is presented as a use case. It is a Metagenomics project whose description and workflow are detailed next, along with several specific risks associated with it, consisting of an initial risk analysis of the use case. 5.1 Bioengineering and Metagenomics Metagenomics enables the study of populations of microorganisms, namely metagenomes (samples containing the DNAs obtained from uncultured microorganisms) [19]. The MetaGenFRAME project is focused in the study of relatively-controlled environments (possibly composed by several types of different bacteria, with each type being present in different quantities), whose chemical reactions may be influenced and enhanced. The project has a particular focus on prokaryotic organisms. The origin of a metagenome typically consists of a closed environment (for example, a sample containing human gut bacteria) or an open environment (like the open ocean). The tools used for task s execution are preselected via script. The project s main tasks are shown in Fig. 2. in more detail. Fig. 2. The MetaGenFRAME workflow. 15

30 The following points describe each task in more detail: Data Quality Control: Before a data set is processed, the information needs to respect certain quality thresholds. This step is executed using NGS QC Toolkit. It s a local task. The inputs are composed of a text file with the sequences that are going to be analyzed, a string with the format used, a variable to filter the OTUs (Operational Taxonomic Units) by identity percentage and, a variable to filter sequences by size. The output is a filtered data set and the removed sequences; Analysis of Taxonomy: Determine the sample s microbial diversity, to determine the different organisms that are present and, if possible, their resolution levels (species, kingdom, etc). The tool used is MetaPhlAn, being a local task. The input is the filtered data set produced previously and the output consists of several lists of organisms present in the sample, with respective resolutions and identity percentages (converted to query format); Remote WS: A sequence of web service invocations that use the National Center for Biological Information (NCBI) data base. A first WS uses as input the lists obtained in the former step and returns a set of corresponding IDs. A second WS then consults the NCBI using as input the former IDs returning a list of reference sequences associated to the existing taxonomic results, in.fasta format; Alignment: Establishment of an order between the studied sequences by comparison with reference sequences. This step uses the TAPyR tool and is performed locally. It receives as input the former list of sequences and generates as outputs a set of aligned sequences in.sam format, a set of non-aligned sequences in a.fasta file, a set of aligned sequences also in a.fasta file and also another.fasta file with consensus sequences; Functional Annotation: The set of consensus sequences are submitted to a functional annotation procedure. It is a remote task. The tool used is Blast2GO; De novo assembly: Sample identification by reconstruction. The tool that supports this task is not determined, but the main contenders are Newbler and MetaVelvet. It s a remote task. As input, it receives the set of non-aligned sequences and as output it returns a set of contigs, which represent junctions of several sequences; Gene structure prevision: Used to obtain some information about the sample's associated genes and to find if genetic structures are present. One tool that can execute this step is BG7. It is a local task. As input, it receives the set of contigs generated in the de novo task and the output is not yet defined; Metabolic Reconstruction: One of the aims will be to produce results associated with the metabolism of the initial input. This will use the gene information produced, comparing it against several databases (KEGG as an example). At this stage, genes are mapped against metabolic pathways present in a number of databases like KEGG. All tasks have a log file saved locally, and the view in which each task presents its results (using Taverna 2 ) is customizable to the operator s needs

31 5.2 Specific risks in the focus project The MetaGenFRAME project extrapolates several types of information from the data set it receives as input, such as the composition of the organism community present in the sample. It also aims to produce information pertaining the metabolism and main chemical reactions present in the sample. With a particular focus on prokaryotic organisms, this raises important issues associated with the secrecy and storage of data, as it will potentially convey information that is important to the client or entity's activity. An example of such an activity is the process of analyzing and enhancing biomass decomposition, fuel refinement, crude extraction, among others. Such processes are trade secrets, and their study must undertake the precautions mentioned earlier. The project also uses remote web services, so ensuring that the information and services available remotely will remain active is a key-necessity for biologists and other professionals. A preliminary risk analysis of this Metagenomics project produced the following list of specific risks: Accidental alteration or deletion of digital objects or the potential insertion of wrong input values: Lead to workflow s erroneous execution and worthless data sets. Caused by human errors. One example is the introduction of the wrong value in variables that indicate the percentage of a sequence's nucleotides that must be of quality regarding the total length of the sequences which are filtered in the data quality control task, therefore influencing all the following results. Purposeful alteration or deletion of digital objects: Caused by intentional (internal or external) attacks. For example, an attack with alteration or deletion of the external WS, NCBI or local PC used. Network or communication failures or weak security measures in the data bases or the local PC can be exploited. Loss of data: Media faults, caused by failures in the storage systems. This vulnerability can occour in the NCBI and in the local PC used. PCs and external HD are useful for short term storage, but inadequate for long term storage due to high failure rate. This risk is enhanced with the lack of a long term storage policy. Legislative changes in legal requirements, like the minimum time a digital object is required by law to be stored, can lead to data loss. Economic or organizational breakdowns can also influence the organization running the NCBI, causing it s termination. Natural disasters can also endanger the data sets stored in the NCBI. Workflow execution failures: The remote WS or the NCBI can be unavailable for technical reasons, like communication and network failures. The Scientific Workflow Management System (SWMS) used is Taverna, along with several software tools that execute the tasks represented in Fig 2. Software and hardware failure or obsolesce, in the NCBI or local PC, can lead to this risk. In the case of failure, it s problematic if the SWMS doesn t provide debugging capabilities that show the failure cause. For example, if the WS fails and no information is provided the user is left wondering whether the service failed locally or remotely. Data traceability loss: Lack of documentation endangers data s recreation. In this project, log file s loss comprises the workflow s recreation, with the same inputs. Data sharing: It is essential to select carefully what data can be reused by the scientific communities or the one that must be kept confidential. 17

32 6 Alignment of a DMP and a RMP As a result of our analysis, we propose that sections of a typical DMP should be delegated to a RMP to be defined using RM principles and good practices. The RMP would serve as a complement to the DMP, therefore producing a more complete and robust DMP. This means these sections should be complemented through the application of RM principles instantiated by the RMP. The defintion of a RMP for Bioengineering and its application requires a specific method, which will be defined in our future research. The use case presented is going to be used to evaluate that method. Evaluation metrics are also going to be applied to the obtained results. These metrics must correspond to the successful achievement of the four main steps that compose this method: (i) Identification of 70 to 90% of the risks, (ii) Successful analysis of the risks, with a quantitative level attributed to each risk, (iii) Successful risk evaluation with the determination of which risks need treatment, through the level of risk, (iv) Successful determination of risk treatment measures for each risk that needs it; 7 Conclusions and future work RM has applications in different areas, organizations and projects. In e-science, collaboration and DM are crucial. New challenges and risks are raised and must be assessed, so the project s data can be preserved and reused. To answer to these dilemmas, DMP are developed before a research project takes place. The problem we identified resides in the fact that these DMP don t take in consideration that DM is a RM activity, making them potentially incomplete and immature. In order to assess that, the need for a method for developing a DMP using the good practices of RM is proposed. This method will serve as a starting point to identify a more generic method that can be applied in most e-science projects in the field of Bioengineering. We have identified a number of risks from the MetaGenFRAME use case. This identification step correspondes to the first stage of a RM analysis. In future work, the analysis on the same case will continue with the analysis, evaluation and treatment of the identified risks. We expect that from that the proposal for a generic method for RM will emerge. Acknowledgments. This work was supported by national funds through FCT (Fundação para a Ciência e a Tecnologia), under projects PEst-OE/EEI/LA0021/2013, TAGS PTDC/EIA-EIA/112283/2009, and DataStorm EXCL/EEI-ESS/0257/2012, and by the project TIMBUS, co-funded by the European Commission under the 7th Framework Programme for research and technological development and demonstration activities (FP7/ ) under grant agreement no

33 References 1. ISO (2009) Risk management Vocabulary. ISO Guide 73:2009. Geneva, Switzerland. 2. ISO (2009) Risk Management - Principles and guidelines. ISO FDIS 31000:2009. Geneva, Switzerland. 3. ISO (2009) Risk management - Risk assessment techniques. ISO IEC 31010:2009. Geneva, Switzerland. 4. ISO/IEC (2011) Information technology. Security technologies Information security risk management. ISO/IEC 27005:2011. Geneva, Switzerland. 5. The Risk IT Framework (Exposure Draft), IT Governance Institute (2009). 6. Caralli, R. A., Stevens, J. F., Young, L. R., Wilson, W. R. (2007) OCTAVE Allegro: Improving the Information Security Risk Assessment Process, Software Engineering Institute at Carnegie Mellon University, Jankowski, N. W. (2007) Exploring e-science: An Introduction, Journal of Computer- Mediated Communication. 8. Barateiro, J., Antunes, G., Freitas, F., Borbinha, J. (2010) Designing digital preservation solutions: a Risk Management based approach. The International Journal of Digital Curation, Issue 1, Vol. 5, NIST Special Publication (Revision 1): Risk Management Guide for IT Systems, Lipkis, T., Morabito, S., Reich, V., Robertson, T., Rosenthal, D. S. H. (2005) Requirements for Digital Preservation Systems: A Bottom-Up Approach, D-Lib Magazine, Number 11, Vol. 11, Ramirez, D. (2008) Risk Management Standards: The Bigger Picture Information Systems Control Journal, Vol. 4, Braga, R. S. (2007) Automatic capture and efficient storage of e-science experiment provenance, Wiley InterScience. 13. Deelman, E., Chervenak, A. (2008) Data Management Challenges of Data-Intensive Scientific Workflows, USC Information Sciences Institute. 14. Office of Government Commerce (OGC) (2007) Management of Risk: Guidance for Practitioners (M_o_R), United Kingdom, Paul A. David, Spence M. (2003) Towards institutional infrastructures for e-science: the scope of the challenge, Oxford Internet Institute. 16. Committee of Sponsoring Organizations of the Treadway Commission (COSO) (2004) Enterprise Risk Management Integrated Framework, Jersey City, NJ: AICPA, Fernandes, D., Bakhshandeh, M., Borbinha, J. (2012) Survey of data management plans in the scope of scientific research, Inesc-ID, Timbus Timeless Business. 18. Coimbra, M. (2012) Metagenomic Frameworks, Project Report, Universidade Técnica de Lisboa, Instituto Superior Técnico. 19. Wooley J. C., Godzik, A., Friedberg, I., (2010) A Primer on Metagenomics, University of California San Diego. 20. Barateiro, J., (2012) A Risk Management Framework Applied to Digital Preservation, PhD Dissertation, Universidade Técnica de Lisboa, Instituto Superior Técnico. 21. Kaye, J., Boddington, P., Vries, J., Hawkins, N., Melham, K. (2010) Ethical implications of the use of whole genome methods in medical research, Europe Journal of Human Genetics. 22. Bimholtz, J. P., Bietz, M., J. (2003) Data at Work: Supporting Sharing in Science and Engineering, GROUP '03 Proceedings of the 2003 international ACM SIGGROUP conference. 19

34 23. Schmitt, C., P., Burchinal, M., (2011) Data management practices for collaborative research, Frontiers in Psychiatry. 24. Day, M. (2004) Preservation metadata initiatives: practically, sustainability, and interoperability, University of Bath. 25. Miles, S., Deelman, Ewa, Groth, P., Vahi, K., Mehta, K., Moreau, L. (2007) Connecting Scientific Data to Scientific Experiments with Provenance, e-science and Grid Computing, IEEE International Conference. 26. Holton, G. (2003) Value-at-Risk: Theory and Practice, Academic Press, McHugh, A., Ruusalepp, R. Ross, S. & Hofman, H. (2007). The Digital Repository Audit Method Based on Risk Assessment (DRAMBORA). DCC and DPE, Edinburgh Association of Insurance and Risk Managers (AIRMIC), ALARM (National Forum for Risk Management in the Public Sector), Institute of Risk Management (IRM) (2002) A Risk Management Standard, London,

35 EpiLog: a novel tool for the qualitative modelling of epithelial patterning P. L. Varela 1, N. D. Mendes 1, P. T. Monteiro 1,2, A. Fauré 3, and C. Chaouiya 1 1 Instituto Gulbenkian de Ciência, Oeiras Portugal, 2 INESC-ID, Lisbon Portugal 3 Yamaguchi University, Japan Abstract. The development of specific computational approaches is needed to analyse the complex regulatory networks that control crucial cellular processes. The complexity of these systems increases even more when cell-cell communication is involved, which is the case in most developmental processes such as epithelial pattern formation. We present Epi- Log, a Java software for qualitative simulations of epithelial patterning that combines logical modelling, as implemented in the software GINsim (www.ginsim.org) and cellular automata. Thanks to a user-friendly interface, the modeller loads a single cell model, defines the rules governing inter-cellular signalling and defines the initial conditions. Then, the simulation can be launched and the consecutive steps towards the final pattern are displayed. With EpiLog it is possible, beyond the study of the wild type situation, to perform in silico perturbation experiments (mutations and clonal analyses). The capabilities of Epilog are demonstrated through the case of the segment-polarity module involved in the segmentation of the early Drosophila embryo. 1 Introduction An increasing amount of data is currently available regarding the control of essential cellular processes such as cell proliferation, differentiation or death. This control is orchestrated by a wide variety of interacting molecular components, defining complex regulatory networks. The complexity of these networks increases even more when cell-cell communication plays a role in the process. This is indeed often the case in developmental processes, such as epithelial pattern formation. Here, we combine the logical formalism, as implemented in the software GINsim (www.ginsim.org) [8] and cellular automata, thus defining a convenient framework for the qualitative modelling of epithelium pattern formation. This framework is implemented in EpiLog, a Java software for qualitative simulations of Epithelium Logical models. The tool is freely available at together with a user manual. The logical formalism we rely on was initially introduced by R. Thomas [11]. Basically, in a logical regulatory graph, nodes embody regulatory components (genes, proteins, etc.), that are associated to discrete functional levels (of expression or activity), and edges represent the regulatory interactions (activations or inhibitions). The evolution of each component level is defined by a logical function depending on its regulators. 21

36 We have recently formalised the notion of Logical Regulatory Modules (LRMs), where components of the regulatory network that are subject to regulatory effects from other components are called proper components, and components that are not regulated are called input components and represent external influences. These external influences can be either environmental cues, e.g. morphogenetic gradients (environment inputs), or signals from neighbouring cells (integration inputs) (see [7]). Fig. 1 illustrates a simple LRM. K 1 (v) = 1 if v 2 = 0 v 0 = 1 K 2 (v) = 1 if v 3 = 1 K 3 (v) = 1 if v 1 = 1 Fig. 1: A simple Logical Regulatory Module (LRM): (left) the regulatory graph where g 0 is an input (maintained constant to value 0 or 1) and g 1, g 2 and g 3 are proper components; g 1 is activated by g 0 and inhibited by g 2, while g 2 (resp. g 3 ) is activated by g 3 (resp. g 1 ); (right) logical rules governing the evolution of the variables v i associates to the components g i (v = (v 0, v 1, v 2, v 3 ) denotes the state of the system). Building upon this framework, we present epithelial models as defined in EpiLog. Such cellular automata (CA) have long been considered to modelling biological processes, particularly pattern formation [4]. Here, we consider monolayer epithelia made of hexagonal cells, whose neighbourhoods do not change along time (i.e. non-proliferating epithelia). As a matter of fact, cells tend to adopt hexagonal shape, due to cell mechanics features that are not fully understood (e.g. [6]). The novelty of the work presented here is that the rules that determine the dynamics of the cell states derive from the corresponding LRM. We then describe the different simulation settings (boundaries, initial configurations, updating of the CA and perturbations). Finally, we illustrate the functionalities of this tool with the well-known segment-polarity regulatory module involved in the segmentation of the early embryo of the Drosophila. To this end, we rely on the model defined by Sánchez et al [9]. 2 Epithelial models Through EpiLog s main panel (see Fig. 4), the user defines an epithelial model by specifying the dimension of the regular lattice of hexagonal 22

37 cells, the Logical Regulatory Module (LRM) encompassed by all the cells and the behaviours of the input components. The LRM is previously defined using e.g. GINsim [3,8] and stored in the standard format SBML-qual [2]. At any time, a model can be saved in the form of a ZIP file containing the original SBML file (the LRM), a text file with the configurations (initial conditions, integration functions, grid dimensions, component colours, etc.) and the composed model in the form of an SBML file (when available, see below). Grid dimensions and boundaries: EpiLog represents the epithelium as a 2D grid of hexagonal cells, whose dimensions are specified by the user. It is further possible to specify two boundary conditions: fixed as a rectangle or periodic as a cylinder (the left border adjacent to the right one or the top border adjacent to the bottom one). This is done with the No Roll-Over and Roll-Over (horizontal or vertical) options. Input specifications: In a LRM, input components are tagged as such. However, when defining the epithelial model, the user must specify the type of these inputs: the level of an environmental input must be set for each cell, while the level of an integration input evolves depending on its corresponding integration function (see Fig. 2). More precisely, environmental inputs account for (constant) external clues and integration inputs are meant to integrate the signals originating from neighbouring cells. The integration function specification follows a grammar designed for this purpose, described as any combination of logical connectors representing disjunction ( ), conjunction (&) or negation (!) of atoms of the following form: G(t, m, M) G(t, m, M, d) G(t, m, M, d:d) Each atom is a proposition over the required value(s) of a component across the neighbours at specified distances of each cell. G is the component name, t is the threshold level of the component, m and M are, respectively, the minimum and maximum number of neighbours meeting the threshold requirement, and d (resp. D) is the minimum (resp. maximum) distance from the current position at which a cell is considered to be a neighbour. The distance parameters are optional; when they are not specified, only immediate neighbours (at distance 1) are considered. The D parameter is also optional, in which case only neighbours at exactly distance d are considered. If both d and D are specified, all cells at a distance within the range are considered. Parameters m and M are specified either by exact numbers or by the symbol (underscore character), which is replaced by the actual number of neighbours, considering the distance parameters. The t parameter may also be specified as, which denotes the maximum level of the component. The complexity of the logical function generated from this specification is proportional to Πi=1`Mi n m i for a worst-case scenario of the disjunction 23

38 G 0(1,1,4,1) at least 1 and at most 4 neighbours at distance 1 have G 0 at least at level 1 G 0(1,1,,1) at least 1 neighbour at distance 1 has G 0 at least at level 1 G 0(1,1,,1) G 0(2,3,,1) at least 1 neighbour at distance 1 has G 0 at least at level 1 OR at least 3 neighbours at distance 1 have G 0 at least at level 2 G 0(,1,,2:3) at least 1 neighbour at distance 2 or 3 has G 0 at its maximum level Fig. 2: Specification of integration functions: (left) the corresponding EpiLog s panel; (right) examples of integration function specifications and their meaning. of n atoms, each specifying a minimum (resp. maximum) number of neighbours m i (resp. M i). This is because all combinations of neighbours meeting the criteria have to be generated. Then, EpiLog deals with two types of models: either a cellular automaton (CA) where each cell carries its rules (i.e. its LRM) and is updated accordingly; or a monolithic logical model obtained by composing all the LRMs [7]. Since integration inputs are meant to calculate the resulting input signal and do not represent actual molecular components, they are specifically updated. In the case of a CA, at each time step, a first round of updates is performed that concerns the sole integration inputs. Then, proper components of the cells are considered for update (see further detail on updating schemes below). A composed model does not include any integration inputs; these are reduced in the course of the composition operation [7]. Finally, recall that the proper composition operation may be far too costly for integration functions that involve too many combinations. In this case, a warning indicates that the user should proceed with the CA version of the model. 3 Simulations settings for epithelial models Initial states: Before launching a simulation, an initial configuration must be specified. Such an initialisation is made by defining the levels of the proper components, in each cell. The levels of environmental inputs must also be assigned to their (constant) levels. The graphical user interface aims at facilitating these settings. A set of different initial configurations can be defined and stored together with the model. Updating schemes: Generally CA (and often logical models) are simulated in a synchronous fashion: all components are simultaneously updated. We have already indicated that this is not the case for integration inputs that are (synchronously) updated first. Similarly, it it possible to define synchronous priority classes, which specify a timing relation 24

39 between components [5]. For instance, (G 0, G 3) < (G 1, G 2) means that G 0 together with G 3 are faster than (i.e. are updated before) G 1 and G 2. Only if G 0 and G 3 cannot be updated (because they are stable in the current state), will the other components be updated, following the priority order. All cells evolve according to this rule. One can even differently consider transitions increasing and decreasing the level of a component, since corresponding molecular mechanisms often relate to different time scales. EpiLog allows to easily define, select and store such priority classes. Perturbations: In this discrete framework, it is easy to specify perturbations such as a knock-out (resp. an ectopic expression); enough to block the corresponding variables to 0 (resp. maximum value), overcoming the logical rule driving the evolution of these variables. EpiLog allows to define perturbations by constraining the value of a (set of) component(s) in all or in a subset of cells. This thus permits the simulation of mutant or clonal in silico experiments. Similarly to initial conditions and priority classes, EpiLog supports the definition, selection (for the simulation) and storage of perturbations. Simulation: The simulation can be done step-by-step, hence visualising each transient pattern, or run until a stable pattern (with no successors) is reached, or for a (parametrisable) number of steps N, with the possibility to proceed iteratively with N additional steps. Assessing component values: Each proper component and environment input is assigned with a colour and, if the component is multi-valued, the colour brightness depends on its level. In the main panel, the user selects the components that are to be displayed on the grid, and cells are painted with the colour resulting from the combination of all selected components. At any time, by selecting or passing the ouse over a cell, a panel displays the levels of all the components in that cell (see Fig. 4). 4 Application to the Segment-Polarity module The core control of the segmentation of early embryos of the Drosophila (fruit fly) is driven by three regulatory modules, organized in a temporal hierarchy: the gap genes, the pair-rule genes and finally the segmentpolarity genes (see e.g. [10]). The segment-polarity module consolidates parasegmental boundaries that are defined by the juxtaposition of two types of cells: those expressing engrailed (En) and those expressing wingless (Wg). This module gave rise to a number of modelling work, including the delineation of logical models [1,9]. Here, we rely on the model defined by Sánchez et al. [9]. The LRM defining the intra-cellular regulatory network encompasses a dozen of proper components, and two inputs that account for the cell-cell communication by hedgehog (Hh) and Wg diffusion (see Fig. 3). We consider a grid defined as cells representing four iterations in the horizontal direction of the six cells 25

40 Fig. 3: The segment-polarity logical regulatory module as defined in [9], with 12 proper components and 2 input components. Green arrows denote activations, whereas blunt, red arrows denote inhibitions. This model is defined in GINsim, then exported in SBML qual to be loaded in EpiLog. representing the three classes of regions within the putative parasegment [9]. Figure 4 illustrates the initial expression pattern, defined by the action of the pair-rule module (see [9]). It also displays the final configuration of the grid obtained in the wild-type situation, which recovers the expected expression pattern. Interestingly, the reachability of this expression pattern is achieved by specifying priority classes similar to those used in the original study [9]: the high priority class encompasses updates corresponding to protein modification events (Ci-act, Ci-rep, Fz, Dsh and Pka), while the low priority class includes gene expression processes (Ci, Wg, Nkd, En, Slp, Hh and Ptc). However, in contrast to Sánchez et al, here component updates within a class are made synchronously. Despite this restriction, the model is able to reproduce the expected behaviour, which could demonstrate the robustness of this regulatory module [1]. Proceeding with the analysis of the series of perturbations as specified in [9], the simulation in EpiLog reproduces the results for single loss-offunction of Wg, En, Hh and Ci, ectopic expression of Nkd and ectopic expression of Wg together with a loss-of-function of Slp. However, remaining perturbations (e.g. Ptc loss-of-function) lead to expression patterns different from those expected. This might be due to the synchronous updating scheme, and needs further investigation. 26

41 Fig. 4: EpiLog view of the segment-polarity model over an epithelium of cells, with the final, wild-type, expression pattern as described by Sánchez et al. [9]. Bottom-right panel displays the initial pattern as specified by the pair-rule module. 5 Conclusions and prospects EpiLog, the software tool presented in this paper, nicely complements the functionalities of GINsim, our software dedicated to the definition and analysis of logical models of regulatory networks [8]. It allows to simulate epithelial models defined as cellular automata, where each cell encompasses a logical regulatory network. The user-friendly interface facilitates the tedious setting-up of epithelial models. In the future, we plan to further improve the user interface; in particular, we want to endow EpiLog with a set of proper error messages to be handled in the course of model specification (e.g. specification of integration functions). Importantly, the possibility to define priority classes allows to somewhat overcome the problems related to a purely synchronous dynamics [5]. Due to a combinatorial explosion, asynchronous updating scheme, as considered in GINsim where all potential trajectories are considered, is certainly not feasible here. However we could, for example, randomly select one of these trajectories, by selecting (randomly) one component to be updated in each cell and performing a simultaneous update of all the cells. Having a composed model allows to rely on an existing GINsim s functionality to compute all existing stable states [8]. This remains to be made available in EpiLog, as well as a proper graphical interface to display these expression patterns. Finally, in EpiLog, an epithelium configuration is fixed, meaning that cells have an hexagonal shape and do not move (their neighbouring re- 27

42 lationships are maintained constant), do not die nor multiply. Future extensions of the tool will progressively relax some of these restrictions. Acknowledgments. We acknowledge support from FCT (Project Grant PTDC/EIA-CCO/099229/2008). References 1. R. Albert and H. G. Othmer. The topology of the regulatory interactions predicts the expression pattern of the segment polarity genes in drosophila melanogaster. J. Theor. Biol., 223(1):1 18, C. Chaouiya, S. Keeting, D. Berenguier, A. Naldi, D. Thieffry, T. Helikar, and M.P. van Iersel. Qualitative models, Version 1 Release 1. Available from COMBINE. level-3.version-1.qual.version-1.release-1, C. Chaouiya, A. Naldi, and D. Thieffry. Logical modelling of gene regulatory networks with ginsim. Methods Mol. Biol., 804:463 79, A. Deutsch and S. Dormann. Cellular automaton modeling of biological pattern formation: characterization, applications, and analysis. Modeling and simulation in science, engineering and technology. Birkhauser, Boston, A. Fauré, A. Naldi, C. Chaouiya, and D. Thieffry. Dynamical analysis of a generic Boolean model for the control of the mammalian cell cycle. Bioinformatics, 22:124 31, Thomas Lecuit. Adhesion remodeling underlying tissue morphogenesis. Trends Cell Biol, 15(1):34 42, Jan N.D. Mendes, F. Lang, Y-S. Le Cornec, R. Mateescu, G. Batt, and C. Chaouiya. Composition and abstraction of logical regulatory modules: application to multicellular systems. Bioinformatics, A. Naldi, D. Berenguier, A. Fauré, F. Lopez, D. Thieffry, and C. Chaouiya. Logical modelling of regulatory networks with GINsim 2.3. Biosystems, 97(2):134 9, Aug L. Sánchez, C. Chaouiya, and D. Thieffry. Segmenting the fly embryo: a logical analysis of the segment polarity cross-regulatory module. Int. J. Dev. Biol., 52(8): , D. Thieffry and L. Sánchez. Qualitative analysis of gene networks: Qualitative analysis of gene networks: Towards the delineation of trans-regulatory modules. In G. Schlosser and G. Wagner, editors, Modularity in Development Modularity in Development and Evolution, pages University of Chicago Press, R. Thomas. Regulatory networks seen as asynchronous automata: a logical description. Journal of Theoretical Biology, 153(1):1 23,

43 Ciência e Engenharia de Software 29

44 Suporte a Testes Automáticos em Aplicações Web geradas com a OutSystems Platform Ricardo Neto 1, Fernando M. Carvalho 2 and Tiago L. Alves 3 1 Instituto Superior de Engenharia de Lisboa, Lisboa, PT, 2 Instituto Superior de Engenharia de Lisboa, Lisboa, PT, 3 OutSystems S.A., Linda-a-Velha, PT, Resumo A necessidade de adaptação rápida das aplicações web aos requisitos dos seus consumidores exige um acompanhamento imediato na validação das alterações introduzidas. As tecnologias actuais para teste de aplicações web oferecem apenas APIs de baixo nível que se baseiam na interacção directa com os elementos HTML dificultando a rápida criação e manutenção dos testes necessários. Este artigo propõe uma solução para a geração automática de uma framework de teste tirando partido de um modelo de uma aplicação web definida com a OutSystems Platform. Keywords: teste de software, aplicações web, qualidade de software, geração de código 1 Introdução A necessidade de alterações frequentes às aplicações aumenta o risco de introdução de falhas [1], realçando a importância de testes capazes de detectá-las em fases iniciais do ciclo de desenvolvimento. Assim, evita-se a sua propagação, diminuindo-se consideravelmente o custo associado à sua correcção [3] e, por consequência, reduzindo o custo de desenvolvimento das aplicações. A execução de testes funcionais em aplicações web passa pela interacção com as suas páginas de forma a verificar que uma determinada funcionalidade está de acordo com a sua especificação. Tradicionalmente, o uso de frameworks de teste web (e.g. Selenium WebDriver) implica a criação de dependências com a estrutura das páginas da aplicação. A forma como pretendemos resolver este problema é dar suporte automático à definição de testes funcionais para aplicações web permitindo que estes estejam num domínio mais próximo do contexto das aplicações e sejam robustos à estrutura HTML usada. A abordagem a este problema inclui tirar partido da OutSystems Platform. 30

45 Figura 1. Páginas envolvidas na realização da história de utilização e respectivos inputs A OutSystems Platform é uma plataforma de desenvolvimento rápido que viabiliza o desenvolvimento de aplicações web no ambiente de desenvolvimento ServiceStudio, disponibilizando uma linguagem de modelação visual para definição do modelo da aplicação. Este modelo é utilizado no processo de compilação e geração automática de código, dando origem a diferentes artefactos como código Java ou.net e páginas HTML. Do modelo da aplicação fazem parte WebScreens e WebBlocks, que representam a interface de utilização, constituídos por widgets como inputs, tabelas ou combo boxes, dando origem, no processo de geração automática de código, às páginas da aplicação e aos elementos HTML que as constituem. Tirando partido do modelo da aplicação definido no ServiceStudio introduzimos os princípios para a geração automática de uma framework que mapeie os conceitos alto-nível de uma aplicação web definida na OutSystems Platform nos elementos HTML necessários e assim facilitar a criação de testes. A utilização desta framework permitirá abstracção sobre a estrutura HTML das páginas e seus elementos, facilitando a criação e manutenção de testes funcionais. 2 Motivação Com o objectivo de demonstrar os problemas na criação de testes com recurso a ferramentas utilizadas na indústria, considere-se a seguinte história de utilização obtida da aplicação Directory 4 que permite a gestão centralizada de colaboradores: Como colaboradora, a Alice precisa de saber quem é o colega responsável pelo website, para que consiga dar a conhecer uma anomalia. A Figura 1 apresenta as páginas da aplicação, e respectivos inputs, necessárias à verificação da história de utilização proposta, entre as quais: (1) Login - Autenticação do utilizador tendo como entradas o nome de utilizador alice.andrews e a password aa123 ; (2) Lista de Áreas - Selecção da área Online Operations no ecrã principal; (3) Dados do Colaborador - Verificar que na apresentação de dados de colaborador Larry R. Logan a sua posição é Online Operations Manager

46 Na listagem 1.1 é mostrada a implementação da história de utilização apresentada utilizando a framework Selenium WebDriver. Listing 1.1. Implementação de teste funcional para consulta de dados relativos a gestor de área organizacional com recurso a Selenium WebDriver 2 public void searchforonlineoperationsmanager ( ) { 3 WebDriver d r i v e r = new F i r e f o x D r i v e r ( ) ; 4 d r i v e r. get ( http : / / l o c a l h o s t / D i r e c t o r y ) ; 5 dologin ( d r i v e r, a l i c e. andrews, aa123 ) ; 6 assertemployeeareaandposition ( d r i v e r, Larry R. Logan, Online Operations, Online Operations Manager ) ; 7 } 8 9 private void dologin ( WebDriver d r i v e r, S t r i n g username, S t r i n g password ) { 10 WebElement inputusername = d r i v e r. findelement (By. i d ( wtusernameinput ) ) ; 11 inputusername. sendkeys ( username ) ; 12 WebElement inputpassword = d r i v e r. findelement (By. id ( wtpasswordinput ) ) ; 13 inputpassword. sendkeys ( password ) ; 14 WebElement buttonlogin = d r i v e r. findelement (By. c s s S e l e c t o r ( input [ value = Login ] ) ) ; 15 buttonlogin. c l i c k ( ) ; 16 } private void assertemployeeareaandposition ( WebDriver d r i v e r, S t r i n g name, S t r i n g area, S t r i n g p o s i t i o n ) { 19 // S e l e c ç ã o de área da organização 20 d r i v e r. findelement (By. linktext ( area ) ). c l i c k ( ) ; 21 // Apresentação de dados do c o l a b o r a d o r 22 a s s e r t E q u a l s ( area, d r i v e r. findelement (By. c s s S e l e c t o r ( div. BreadcrumbText a span ) ). gettext ( ) ) ; 23 a s s e r t E q u a l s (name, d r i v e r. findelement (By. i d ( wtemptbl ctl04 wtempname ) ). gettext ( ) ) ; 24 a s s e r t E q u a l s ( p o s i t i o n, d r i v e r. findelement (By. id ( wtemptbl ctl04 wtemppos ) ). gettext ( ) ) ; 25 } O teste que valida a história de utilização definida anteriormente segue três etapas. Na primeira etapa, linha 3, inicializa-se o browser Firefox e, na linha 4, faz-se o pedido da página inicial a testar. Na segunda etapa faz-se a autenticação, invocando na linha 5 o método dologin com os argumentos adequados. A linha 10 faz a pesquisa do elemento HTML de input do nome de utilizador e a linha 11 introduz o valor utilizado no teste. As linhas 12 e 13 repetem estes passos para a password. Na linha 14 é feita a pesquisa do elemento que representa o botão de 32

47 Login e na linha 15 é invocado o evento de click sobre este elemento. Na terceira etapa do teste é seleccionada a área organizacional e verificam-se os dados apresentados, invocando na linha 6 o método assertemployeeareaandposition. Na linha 20 selecciona-se a área da organização a que corresponde o teste verificandose por fim, nas linhas 22 a 24, os dados do colaborador apresentado na página com os valores utilizados no teste. O problema desta aborgadem, também identificado em outras frameworks de teste (e.g. HttpUnit 5 e Cucumber 6 ), é a dependência explícita a elementos específicos de HTML. Esta dependência não só dificulta a criação dos testes (utilizando identificadores ou navegando directamente na estrutura HTML) como também dificulta a manutenção decorrente de mudanças ao nível da estrutura na página. Considere-se, no exemplo apresentado, o valor dos identificadores dos elementos que recebem o nome de utilizador e password na página de Login. Modificando na aplicação o seu valor, de wtusernameinput e wtpasswordinput para txtusername e txtpassword respectivamente, provocaria falhas na execução dos testes com dependências para os mesmos, exigindo esforço na sua adaptação e reduzindo a visibilidade sobre o impacto das alterações na funcionalidade. 3 Abordagem Proposta Com este trabalho pretende-se retirar dos testes referências directas à estrutura das páginas da aplicação em teste, fazendo com que alterações à aplicação não tenham impacto nos testes mas sim na framework de testes, que pode ser gerada automaticamente a partir do modelo da aplicação definido no ServiceStudio. A Figura 2 apresenta a arquitectura da solução proposta, da qual fazem parte os seguintes elementos: (1) o modelo da aplicação definido no ServiceStudio; (2) o processo de geração da framework, a ser definido no presente trabalho; (3) a framework de testes gerada a partir do modelo da aplicação; (4) o core da framework de testes; (5) a framework de automação; e (6) os testes. De seguida detalham-se cada um dos elementos referenciados quanto ao seu papel na arquitectura da solução proposta. 1 - Modelo da Aplicação O modelo da aplicação, definido no ServiceStudio com recurso à linguagem visual da OutSystems Platform, contém a definição das camadas de apresentação, lógica aplicacional e acesso a dados. É utilizado pelo PlatformServer no processo automático de compilação e geração de código que dá origem à aplicação web, podendo ser alterado, sendo re-utilizado nesse processo para a geração automática de uma nova versão da aplicação. O seu contributo é fundamental na geração da framework de testes por nele se encontrarem descritos, com todo o detalhe, elementos como as páginas na aplicação, os comportamentos que expõem e as

48 Figura 2. Arquitectura da solução onde se identificam: (1) o modelo da aplicação em ServiceStudio; (2) o processo de geração da framework; (3) a framework de testes obtida do modelo da aplicação; (4) o core da framework de testes; (5) a framework de automação e; (6) os testes wigets que as constituem, que dão origem ao HTML com o qual o utilizador pode interagir. 2 - Processo de geração da framework O conjunto de regras que especificam a forma como o modelo da aplicação se mapeia nos objectos a serem utilizados na criação de testes constitui o processo de geração da framework de testes. Tem como input o modelo da aplicação de onde obtém dados como as suas páginas, os elementos que as compõem ou valores de atributos que viabilizam localização de elementos na página, utilizados para dar origem à camada aplicacional que os representa na criação de testes. O seu objectivo principal é reflectir na framework de testes, e por consequência nos testes, alterações feitas à aplicação. 3 - Application Test Framework A Application Test Framework é a camada da OutSystems Web-Application Test Framework que é específica da aplicação sendo obtida do processo de geração, representando em API própria o modelo da aplicação definido no ServiceStudio. A sua função é a de facilitar a criação de testes, disponibilizando uma API composta por objectos que representam a aplicação, as suas páginas e os elementos com os quais os utilizadores podem interagir. Por se basear no modelo da aplicação, é na Application Test Framework que são guardadas as referências para o HTML das páginas da aplicação (e.g. widgets, localizadores), sendo actualizadas sempre que é gerada uma nova versão da aplicação. Assim, o problema da dependência dos testes com o HTML das páginas da aplicação deixa de existir, uma vez que referências ao mesmo serão aqui centralizadas. A API 34

49 Figura 3. Estrutura interna de Framework Core onde são mostrados os packages que a compõem disponibilizada facilita não só a criação de testes, mas também a sua legibilidade, disponibilizando estruturas que representam entidades do domínio da aplicação. 4 - Framework Core A Framework Core é a camada que dá suporte à Application Test Framework. A sua função é disponibilizar definições para os objectos que representam a aplicação, as páginas e as widgets, independentemente da aplicação. A Figura 3 dá uma visão simplificada do conteúdo desta camada mostrando os packages que a compõem, onde estão definidas as interface e implementações genéricas de objectos que serão utilizados e cujo comportamento pode ser estendido. 5 - Automation Framework A Automation Framework é a camada responsável por garantir a interacção dos testes com a aplicação através da manipulação de uma instância de um browser, tendo-se optado pela utilização da framework Selenium WebDriver. Esta camada dá suporte à Framework Core e à Application Test Framework, permitindo a manipulação de diferentes browsers e localização e manipulação de elementos expostos pelas páginas da aplicação através de uma API rica. É nesta camada que existem mecanismos, específicos da framework Selenium WebDriver, capazes de lidar com aspectos relativos à introdução de tempos de espera no carregamento de páginas ou de conteúdo dinâmico que as compõem (no caso de pedidos AJAX) e execução de JavaScript. 6 - Testes Os testes são criados manualmente e fazem uso da OutSystems Web-Application Test Framework referenciando-a como uma biblioteca externa. Na sua implementação serão utilizadas instâncias de objectos que representam o modelo da aplicação, utilizando uma API que viabiliza a obtenção e alteração de estado 35

50 de elementos que compõem as páginas da aplicação sem ser necessário conhecimento acerca da sua representação. A listagem 1.2 mostra uma proposta de implementação de um teste que faz referência a um protótipo da framework de testes criado manualmente. Listing 1.2. Teste de consulta de dados com recurso a protótipo da framework de testes 2 public void searchforonlineoperationsmanager ( ) { 3 D i r e c t o r y app = new D i r e c t o r y ( ) ; 4 dologin ( app, a l i c e. andrews, aa123 ) ; 5 assertemployeeareaandposition ( app, Larry R. Logan, Online Operations, Online Operations Manager ) ; 6 } 7 8 private void dologin ( D i r e c t o r y app, S t r i n g username, S t r i n g password ) { 9 LoginPage loginpage = app. getloginpage ( ) ; 10 loginpage. setusername ( username ) ; 11 loginpage. setpassword ( password ) ; 12 loginpage. c l i c k L o g i n ( ) ; 13 } private void assertemployeeareaandposition ( D i r e c t o r y app, S t r i n g name, S t r i n g area, S t r i n g p o s i t i o n ) { 16 MainPage main = app. getmainpage ( ) ; 17 main. clickdepartment ( Online Operations ) ; 18 a s s e r t E q u a l s ( main. getemployeebyname ( Larry R. Logan ). l e n g t h ( ), 1) ; 19 a s s e r t E q u a l s ( main. getemployeebyposition ( Online Operations Manager ). l e n g t h ( ), 1) ; 20 } Na linha 3 é instanciado o objecto que representa a aplicação que implementa IApplication. A autenticação é feita pela invocação do método dologin na linha 4. Na linha 9 é invocado um método do objecto Application que devolve uma instância de um objecto do tipo LoginPage, que representa a página de Login. Nas linhas 10 e 11 é feito o acesso aos elementos de input do nome de utilizador e password, expostos aqui sobre a forma de métodos. Na linha 12 é chamado o método que representa a operação de login, exposta na página da aplicação através de um botão. A selecção da área organizacional e verificação dos dados apresentados é feita no método assertemployeeareaandposition, invocado na linha 5. Nas linhas 16 e 17 é obtido o objecto que representa a página principal da aplicação e invocado o método clickdepartment, que invocará o evento de click sobre um dos objectos de domínio expostos na página. Por fim verificam-se, linhas 18 e 19, os dados do colaborador apresentado na página com os valores 36

51 utilizados no teste. O objecto do tipo IApplication, instanciado na linha 3, é responsável pela instanciação do browser a ser utilizado no teste, bem como do driver que o irá manipular, retirando do código de teste referências à framework de automação. Na geração de objectos deste tipo pretende-se tirar partido da informação presente no modelo de navegação da aplicação com o objectivo de retornar instâncias de objectos que representam as páginas da aplicação, objectos estes do tipo IPage- Object, centralizando o acesso às páginas no objecto Application, retirando do código de teste referências a caminhos da aplicação. Na solução proposta tira-se partido do padrão PageObject, identificado em [2]. A sua utilização tem como objectivo minimizar o esforço de manutenção envolvido na adaptação dos testes a alterações à aplicação, reduzindo a duplicação de código, centralizando num objecto os comportamentos expostos e elementos presentes na interface de utilização. Os testes passam a invocar métodos expostos pelo objecto PageObject como forma de interagir com a interface de utilização ou executar acções disponiveis na pagina. Nas linhas 10 e 11 são invocados métodos que representam os elementos de input da página que guardam o nome de utilizador e password. Estes métodos, além de viabilizarem a alteração e obtenção de estado dos elementos na página, permitem a validação dos inputs na framework de testes, uma vez que o tipo de dados recebido, ou devolvido, corresponde ao tipo de dados definido no modelo da aplicação no ServiceStudio (e.g. inteiro, decimal). A utilização de conceitos relacionados com o domínio da aplicação, como é o caso de Departamento e Colaborador, facilita a legibilidade do teste. Desta forma, pretende-se incluir na geração da framework métodos capazes de tratar entidades, individualmente ou em grupo, como é o caso de getemployeebyname na linha 17, facilitando a criação de testes por facilmente permitir a identificação dessas entidades nas páginas da aplicação. Nas linhas 18 e 19 exemplifica-se o uso de métodos de entidades de domínio capazes de aceder a uma lista de entidades com mapeamento directo no HTML da página da aplicação. 4 Conclusões e trabalho futuro A solução proposta permite remover dos testes dependências com o HTML das páginas da aplicação, facilitando de uma forma geral a manutenção da test suite. A extensão do mecanismo de geração automática de código, baseado no modelo da aplicação definido no ServiceStudio, irá permitir que a API da framework de testes, também gerada automaticamente, se mantenha consistente com o código da aplicação, facilitando a criação de novos testes ou a alteração de testes já existentes. Do ponto de vista da visibilidade sobre alterações à aplicação, a quebra de compatibilidade entre testes e aplicação é possível de ser verificada em tempo de compilação, evitando tempo gasto num ciclo de verificação. 37

52 Os próximos passos envolvidos no desenvolvimento deste trabalho consistem essencialmente em explorar a linguagem da OutSystems Platform, identificando a forma como os elementos que compõem a aplicação se mapeiam na framework de testes. Após a definição da API com que cada elemento irá mapear, será possível codificar o gerador automático da framework, que permitirá aplicar a solução proposta a aplicações empresariais reais. Pretende-se também investigar formas de tirar partido da linguagem visual oferecida pela OutSystems Platform, permitindo a criação de testes no ServiceStudio. Referências 1. Glenford J. Myers and Corey Sandler, The Art of Software Testing, John Wiley & Sons, Selenium Browser Automation Framework, Selenium browser automation framework, https://code.google.com/p/selenium/. 3. Gregory Tassey, The Economic Impacts of Inadequate Infrastructure for Software Testing, Diane Pub Co,

53 Localização de Elementos na Interface Gráfica com Base no Código Fonte Sérgio R. Silveira, André L. Santos Instituto Universitário de Lisboa (ISCTE-IUL), Av. das Forças Armadas, Lisboa, Portugal Resumo Exploração de código é uma atividade importante para efeitos de manutenção de software, a qual por vezes se revela dispendiosa. Este artigo apresenta um mecanismo de exploração inovador que permite localizar elementos na interface gráfica com base no código fonte. Desta forma, é permitido a um programador indicar uma variável no código (sendo o seu tipo um elemento gráfico), e obter marcações visuais nos elementos gráficos do programa em execução que correspondem à variável indicada. O mecanismo é concretizado por via de instrumentação do programa, interligando-o com o ambiente de desenvolvimento. Foi desenvolvida uma prova de conceito para Java / SWT, utilizando o Eclipse como o ambiente de desenvolvimento que permite ativar o mecanismo. Keywords: Compreensão de programas, interfaces gráficas, instrumentação, rastreamento 1 Introdução Ao contrário dos artefactos físicos, uma grande parte dos aspetos do software desenvolvido tem uma natureza abstrata, e logo, invisível. Devido a esta característica intrínseca, surgiram diversas formas de visualização que permitem aos programadores e analistas compreender e explorar programas de forma mais eficiente. As formas de visualização são tipicamente especializadas para partes ou problemas específicos em engenharia de software, tais como lógica de negócio, concorrência, modularização, qualidade, etc. Apesar de muitos aspetos do software não terem uma forma natural de visualização e manipulação, há um aspeto do software que é tangível a interface gráfica com o utilizador (Graphical User Interface, GUI). Através do ecrã, os utilizadores e os programadores podem ver e tocar nos artefactos que dizem respeito à GUI do programa. No âmbito da abordagem proposta neste artigo, somos da opinião que esta particularidade em relação a outros aspetos do software é subaproveitada pelas tecnologias atuais, nomeadamente pelos ambientes de desenvolvimento integrados (Integrated Development Environment, IDE). 39

54 Ao explorar o código fonte de um programa, um programador pode ser confrontado com pedaços de código ou componentes da GUI sobre os quais não compreende o seu papel no programa em execução. Estas situações serão mais frequentes quando um programador é integrado numa equipa a cargo do desenvolvimento de programas com alguma maturidade ou em casos de manutenção de sistemas legados. Estudos realizados revelam que os programadores gastam proporções consideráveis de tempo nas tarefas de manutenção, a explorar e estabelecer relações entre os elementos do código fonte e os objetivos de uma tarefa (>30%) [3], sendo que parte significativa desse tempo é despendido a inspecionar código irrelevante para a tarefa em questão [2]. Por exemplo, perante uma variável utilizada no âmbito da instanciação de um formulário complexo da interface gráfica, um programador pode questionarse onde está este elemento no formulário do programa em execução? Mesmo tendo a certeza que o pedaço do código fonte em questão é responsável pelo formulário, a incerteza sobre determinado elemento tipicamente leva a processos de tentativa-erro onde pequenas alterações são efetuadas para averiguar se a intuição está certa. As alterações funcionam apenas como pequenas marcas para o programador estabelecer a ponte entre o código e o que vê no ecrã. Outro exemplo prende-se com a possibilidade da concretização de um sistema incluir classes que definem componentes gráficos específicos. Ao encontrar tais classes no código fonte, um programador pode questionar-se onde é que este elemento é utilizado?. Embora uma procura com base em análise estática através de um IDE possa localizar onde é que o elemento é instanciado no código, o programador pode não perceber como é que isso que se traduz na aplicação em execução, especialmente se as partes do código fonte indicadas não lhe forem familiares. Tipicamente, com base em intuições derivadas da implementação do componente ou do código que o instancia, o programador irá explorar a aplicação em busca de pistas para perceber onde é que o componente é utilizado. Neste artigo apresentamos um mecanismo de exploração de código fonte que permite localizar elementos na interface gráfica a partir de elementos do código fonte. Desta forma, um programador tem a possibilidade de indicar variáveis ou classes no código fonte que sejam de um tipo de elemento gráfico, obtendo marcas visuais que localizam esses elementos na GUI do programa. As marcas consistem em mudar a cor de fundo dos elementos gráficos para cores pretendidas, sendo possível manter várias marcações em simultâneo. Foi desenvolvida uma prova de conceito da abordagem proposta para Java 1, no âmbito da biblioteca gráfica SWT 2 e do IDE Eclipse 3. O mecanismo é concretizado através da instrumentação de programas, com recurso a programação por aspetos (Aspect-Oriented Programming, AOP) em AspectJ. Durante a execução é mantido em memória um registo dos elementos gráficos ativos e a relação com a sua localização no código. Por sua vez, os programas são adaptados para poderem receber pedidos do IDE (via sockets) para que o mecanismo seja ati- 1 Código fonte disponível em https://code.google.com/a/eclipselabs.org/p/guita

55 vado. A sobrecarga de memória e CPU causada pela instrumentação foi medida, obtendo proporções aceitáveis que permitem que a abordagem escale para programas não-triviais. Este artigo está estruturado da seguinte forma. A Secção 2 apresenta ferramentas com a abordagem proposta. A Secção 3 descreve o mecanismo proposto, ao passo que na Secção 4 são abordados aspetos de concretização. A Secção 5 contém os resultados da avaliação da performance do mecanismo proposto em termos de sobrecarga causada pela instrumentação. Por fim, a Secção 6 apresenta conclusões e trabalho futuro. 2 Trabalho Relacionado Existem ferramentas de código aberto que nos permitem distinguir os diferentes elementos da GUI de um programa através da marcação desses elementos com cores distintas. A existência das ferramentas que descrevemos de seguida evidencia de certa forma a presença do problema de identificação de elementos da GUI na indústria de software. Num artigo recente [1], é apresentada uma visão geral das ferramentas existentes para localização de funcionalidades no código fonte, o qual não menciona quaisquer abordagens específicas para elementos da GUI. A ferramenta YARI [6] é um pacote de utilitários para o Eclipse que permite inspecionar em detalhe aspetos de aplicações cuja GUI é baseada em SWT. Por exemplo, é permitida a análise das relações pai-filho dos elementos da GUI numa estrutura em árvore. Entre outras opções encontra-se uma que permite alterar as cores de fundo de todos os elementos gráficos de uma vez, tanto do Eclipse como também aplicações RCP (Rich Client Platform), ficando os limites dos mesmos facilmente observáveis. Esta funcionalidade, embora simples, é útil para depuração de layouts, permitindo muito rapidamente identificar todos os elementos visíveis que compõem a GUI, e caso seja detetada alguma incoerência haver a possibilidade de localizá-la e corrigi-la mais facilmente. Picasso [5] é outra ferramenta que também contém a funcionalidade que permite alterar a cor de fundo de todos os elementos gráficos de uma interface em simultâneo. Tal como a ferramenta YARI apenas tem a capacidade de alterar as cores de todos os elementos gráficos e é usada essencialmente em problemas de depuração de layouts, tal como ajeitar margens, problemas de pixeis, espaços em branco, etc. A funcionalidade descrita é ilustrada na Figura 1, a qual contém uma captura de ecrã de uma aplicação instrumentada com o Picasso. Num trabalho desenvolvido anteriormente [4], foi proposto um mecanismo de localização de código a partir de elementos da GUI de um programa. A concretização do mecanismo recorre à instrumentação de programas (utilizando AOP), mantendo adicionalmente na memória dos programas um registo da localização no código fonte dos elementos da interface ativos. Com base nesta informação, é permitido aos programadores selecionar um elemento da interface e navegar para as linhas de código correspondentes, desde que o elemento é criado até à última operação invocada no mesmo. 41

56 Figura 1. Funcionalidade de instrumentação oferecida pelo Picasso. O trabalho apresentado neste artigo vem no seguimento de [4], propondo o mecanismo inverso. Ou seja, pretende-se permitir navegar de elementos do código fonte para elementos da GUI de um programa em execução. O principal benefício que o mecanismo proposto tem em relação às ferramentas YARI e Picasso reside na capacidade de deixar escolher quais os componentes a pintar interagindo apenas com o código fonte, ao invés de pintar todos os elementos gráficos em simultâneo. Para além disso, este trabalho permite que sejam pintados elementos que se encontrem em GUI s de aplicações executadas pelo IDE Eclipse, enquanto que as duas ferramentas anteriormente referidas apenas pintam os elementos da workbench do Eclipse ou aplicações RCP. O objetivo final é obter ganhos em termos de tempo despendido em atividades de exploração no âmbito da manutenção de software. 3 Conceito Esta secção descreve o mecanismo proposto do ponto de vista de um programador que o utiliza. A ideia principal deste mecanismo é o programador poder obter uma rápida distinção dos elementos gráficos que compõem a GUI de um programa, selecionando uma variável no código fonte referente a um dos elementos gráficos existentes, com vista a solicitar uma marca visual na interface gráfica da aplicação a explorar que permita identificar facilmente o(s) elemento(s) gráfico(s) em questão. A utilização do mecanismo proposto não requer quaisquer adaptações ao código fonte. O mecanismo é útil para auxiliar programadores com questões de construção ou modificação de GUI, ou para tarefas longas de exploração levadas a cabo por programadores que não estejam familiarizados com as partes do código fonte envolvidas. 42

57 A Figura 2 ilustra a forma como um programador pode utilizar o mecanismo de localização de elementos gráficos com base no código fonte. As imagens capturadas são do protótipo desenvolvido, envolvendo a biblioteca SWT para desenvolvimento de GUI e o IDE Eclipse. Pormenores relativos à concretização do protótipo são apresentados posteriormente na Secção 4. O programa utilizado é um dos exemplos oficiais de SWT, denominado Control Example, onde são ilustrados todos os tipos de elementos gráficos, envolvendo a criação de mais de mil elementos distribuídos por vários separadores (tabs). Após o início do programa sob instrumentação (1), o programador pode selecionar no seu código fonte uma variável cujo tipo descenda direta ou indiretamente da classe Control (SWT) (2), e aceder a um menu de contexto com opções para adicionar uma marca visual ao(s) elemento(s) correspondente(s) a essa variável (3). Ao ser escolhida, caso o elemento esteja visível na GUI nesse instante, então aparecerá com a cor de fundo alterada de acordo com a opção escolhida no passo anterior (4). Este elemento é também mostrado numa vista do Eclipse que contém uma tabela com várias informações sobre o elemento selecionado (5). Em alternativa à seleção de uma variável, pode ser selecionada uma classe com tipo de elemento gráfico, implicando que serão marcados no programa todos os elementos gráficos pertencentes a essa classe. A vista no Eclipse mantém uma lista dos pedidos de marcação, indicando o nome da variável, o seu tipo, o ficheiro onde está localizada, a cor selecionada, e o número de elementos no programa em execução que foram pintados. Ao efetuar um pedido de marcação, existem três tipos de relações possíveis entre as variáveis no código fonte e os elementos visíveis na GUI: (a) 1-0 uma variável para zero elementos visíveis (b) 1-1 uma variável para um elemento visível (c) 1-* uma variável para múltiplos elementos visíveis A relação 1-0 é referente aos casos onde a variável selecionada não tem correspondência para nenhum elemento gráfico visível no estado em que o programa em execução se encontra. Nestes casos, o pedido fica numa lista de espera, implicando que os elementos da GUI que forem aparecendo durante a execução do programa irão ser marcados com a cor selecionada. Esta funcionalidade é especialmente útil quando um programador está perante um pedaço de código e não consegue perceber onde é que o mesmo se reflete no programa em execução. Este caso é ilustrado no exemplo da figura com a marcação da variável shell a amarelo, e com zero elementos pintados. A relação 1-1 é referente aos casos onde apenas um elemento gráfico é marcado no programa, significando que no estado atual do programa só existe um objeto que corresponde à variável selecionada. Pode ocorrer a situação de o elemento não ser visível, mas na verdade estar ativo e marcado. Este caso é ilustrado no exemplo figura com a marcação da variável checkbutton a verde. Por último, a relação 1-* é referente aos casos onde a variável selecionada corresponde a vários elementos da GUI ativos. Esta situação ocorre tipicamente quando elementos da GUI são instanciados de forma repetitiva, por exemplo num ciclo, ou mediante uma ação despoletada interativamente em que seja permitida 43

58 Figura 2. Ilustração do funcionamento do mecanismo proposto: (1) programa em execução (instrumentado); (2) seleção de uma variável no código fonte; (3) opção de marcação dos objetos e as várias cores possíveis; (4) o elemento gráfico correspondente à variável selecionada fica com a cor de fundo alterada; (5) vista do Eclipse que contém uma tabela onde são geridos os elementos selecionados para marcação. 44

59 a sua execução várias vezes. Este caso, mais concretamente com uma relação de um para dois, é ilustrado no exemplo da figura com a marcação da variável currentshell a vermelho. A lista de pedidos de marcação de elementos gráficos é mantida caso o programador termine o programa. Ao executar novamente o programa, os elementos da lista aparecem de novo com as cores de fundo alteradas, podendo estas ser removidas a partir da tabela que se encontra na vista do Eclipse. 4 Concretização Foi desenvolvido um protótipo como prova de conceito do mecanismo proposto para Java e SWT, uma tecnologia de GUI multi-plataforma utilizada pela comunidade do Eclipse. O IDE utilizado para integrar o mecanismo foi também o Eclipse, através do desenvolvimento de plugins (ver Figura 3). A instrumentação é feita recorrendo à programação orientada por aspectos com AspectJ. Para poder utilizar o mecanismo é necessário que o programa que se pretende explorar seja compilado com um aspeto que o irá instrumentar. Não são feitos pressupostos sobre a estrutura do programa, e não é necessário efetuar quaisquer modificações ao mesmo. Assim sendo, ao serem executadas os programas com a instrumentação ativa, o mecanismo pode ser utilizado. Os tipos de elementos que compõem a GUI estão estruturados numa hierarquia, sendo Control uma das classes mais abstratas nessa hierarquia. À medida que as instruções do programa instrumentado são executadas, todos os componentes gráficos descendentes de Control que são instanciados ou invocados são capturados pelo aspeto de instrumentação. Na Figura 4 apresentamos um pequeno excerto do código de instrumentação (simplificado), que contém um advice que interceta todas as instruções que criam objetos compatíveis com Control com vista a guardar uma associação entre a localização e o objeto. A informação é guardada numa tabela que associa localizações no código fonte a objetos de elementos ativos da GUI. Assim que os elementos gráficos são desativados (disposed), a entrada correspondente é descartada, libertando memória. Desta forma, o número de entradas na tabela está diretamente relacionado com o número de elementos gráficos ativos. O programador pode em qualquer altura fazer um pedido de marcação de um elemento gráfico selecionando uma variável correspondente a um elemento gráfico do tipo Control. A comunicação entre a aplicação instrumentada e o mecanismo proposto é realizada recorrendo a sockets que processam pedidos feitos pelo componente integrado no IDE. Estes pedidos são constituídos essencialmente por: (a) localização no código fonte (ficheiro / linha) (b) a cor pretendida para a marcação (c) o tipo de elemento gráfico (d) o número variáveis do mesmo tipo na mesma linha (e) o número de ocorrências da variável na mesma linha 45

60 Figura 3. Concretização. a f t e r ( ) r e t u r n i n g ( C o n t r o l g ) : c a l l ( C o n t r o l +.new (.. ) ) { S o u r c e L o c a t i o n l o c = t h i s J o i n P o i n t. g e t S o u r c e L o c a t i o n ( ) ; S t r i n g key = l o c. getfilename ( ) + " : " + l o c. g e t L i n e ( ) ; L i s t <C o n t r o l > l i s t = t a b l e. g e t ( key ) ; l i s t. add ( g ) ; } Figura 4. Excerto do código de instrumentação em AspectJ (simplificado). Após a receção do pedido é feita uma verificação se o elemento se encontra na tabela e por consequência pronto a ser pintado, caso este não se encontre presente na tabela é porque a instrução correspondente ainda não foi executada, sendo o pedido adicionado a uma lista de pedidos pendentes. Sempre que forem capturados novos elementos gráficos quando são executadas instruções, é feita uma verificação na lista de pedidos pendentes de forma a verificar se existe algum elemento gráfico que já se encontra visível de momento para ser pintado de imediato. Após cada adição ou remoção de marcação, o programa comunica com o IDE com vista a atualizar na vista os dados relativos ao número de objetos marcados para cada variável. Os elementos (c), (d), e (e) do pedido são obtidos através de análise estática do código fonte. A sua utilidade é permitir desambiguar a informação contida na tabela em memória, dado que a instrumentação com AspectJ apenas permite obter informação relativa às linhas, não incluindo as posições de caracteres nessas linhas. O estado atual do protótipo ainda não permite a marcação de algumas variáveis que ocorrem em determinados tipos de instruções no código fonte, nomeadamente os que envolvem acessos a vetores, ou em casos mais atípicos onde uma linha contém mais do que uma instrução. 46

61 5 Desempenho Os programas instrumentados com vista à utilização do mecanismo proposto requerem um consumo de memória adicional, dado que é guardada informação adicional na memória do programa. Para medir a sobrecarga em termos de memória e CPU causada pela instrumentação proposta, fizemos uma experiência usando um programa oficial de exemplos SWT (o mesmo que é utilizado na Figura 2). Este programa é constituído somente por GUI e demonstra cada tipo de elemento gráfico existente em SWT, criando mais de mil elementos distribuídos por 24 separadores. Foi feito efetuado um profiling do programa através da ferramenta YourKit 4, capturando instantes de utilização da memória e CPU (snapshots). A experiência foi realizada num computador com o sistema operativo Windows 7 Profissional, com um processador Intel Core i GHz e com 6Gb de RAM. Foi modificado o programa original de forma a que a criação dos 24 separadores fosse feita de modo incremental em 6 iterações que adicionam 4 separadores de cada vez, com um tempo de intervalo entre cada iteração. A cada nova iteração foi capturado um snapshot. Desta forma, obtivemos vários snapshots periódicos que diferem no número de elementos criados no programa, o qual sofria um aumento considerável após cada iteração (mais de cem novos elementos a cada iteração). Foram feitas capturas de snapshots tanto para o programa em execução normal (sem estar instrumentado) como para o programa instrumentado. Tirando o facto de possuir um elevado número de elementos gráficos, este programa foi escolhido porque somente contém GUI. Dado que o nosso mecanismo apenas instrumenta a GUI, a sobrecarga deve ser quantificada no que diz respeito ao número e interações com elementos de uma GUI. Medindo a sobrecarga num programa que apenas consiste em GUI, as proporções de sobrecarga obtidas podem ser generalizadas como uma aproximação expectável ao instrumentar outros programas. Os resultados das medições são apresentados na Figura 5, em termos de sobrecarga de memória (a) e de utilização de CPU (b), as quais foram obtidas através dos mesmos snapshots utilizados para as medições de memória. 5(a). A primeira coluna deste gráfico corresponde ao snapshot do programa sem nenhum elemento, apenas com a shell principal. Mesmo não existindo elementos gráficos, pode-se observar uma sobrecarga significativa devido ao uso do AspectJ. Subsequentemente, são apresentados 6 snapshots de memória capturados depois de cada iteração de 4 separadores, sendo que o número total de elementos vai aumentado a cada iteração. Os valores de memória são baseados em objetos alcançáveis, i.e. objetos acessíveis através do garbage collector por referências fortes. Quando se compara a memória da execução do programa normal e o instrumentado, pode-se observar uma sobrecarga na ordem dos 15-25%. No entanto é importante realçar que uma parte significativa da sobrecarga não é devido à informação introduzida pela instrumentação, dado o valor registado no primeiro 4 47

62 Memória (Mb) Sobrecarga memória Normal Instrumentação Elementos Normal Instrum. Sobrecarga # (Mb) (Mb) % % % % % % % (a) Sobrecarga de memória. Sobrecarga CPU CPU (ms) Normal Instrumentação Elementos Normal Instrum. Sobrecarga # (ms) (ms) % % % % % % % (b) Sobrecarga 48 de CPU. Figura 5. Sobrecarga causada pela instrumentação.

63 snapshot. Assim sendo, se for retirado o valor constante da sobrecarga (14%), podemos concluir que a informação adicional apenas causa uma sobrecarga na memória na ordem dos 5-10%, considerando apenas a inicialização dos elementos gráficos. À medida que os utilizadores interagem com o programa, mais informação é guardada, e consequentemente, é necessária mais memória. Não foram realizadas experiências para avaliar o impacto da instrumentação em execuções de programas de longa duração. No entanto como é referido na Secção 4, foi assegurado que não se desperdiça memória descartando o registo de elementos que vão sendo removidos ao longo da execução do programa. O número de elementos que são capturados e armazenados no registo é sempre igual ao número de elementos que se encontram ativos num determinado estado do programa, implicando que haja sempre uma recuperação de memória quando estes são removidos. 5(b). Pode observar-se que a sobrecarga de CPU regista proporções aceitáveis, sendo de notar que os valores mais elevados foram registados nas primeiras iterações, possivelmente devido ao carregamento das classes do AspectJ e dos próprios aspetos. Nas restantes iterações pode-se observar valores na ordem dos 10-25%, os quais que consideramos negligenciáveis dado o benefício de utilização do mecanismo proposto. 6 Conclusões Neste artigo foi proposto um mecanismo inovador de localização de elementos gráficos a partir do código fonte. A principal inovação vem da possibilidade do programador poder escolher quais os elementos gráficos que deseja localizar com base em variáveis no código. Por comparação à exploração e análise manual, especialmente em programas com uma GUI complexa, acreditamos que o mecanismo proposto tem potencial para contribuir para uma maior eficiência nas tarefas de manutenção que envolvem GUI. Como prova de conceito, o mecanismo proposto foi concretizado para a tecnologia Java/SWT e integrado no Eclipse. No futuro pretende-se planear e realizar um estudo com utilizadores que consiga avaliar empiricamente o mecanismo proposto. Este estudo basear-se-á na medição e comparação do desempenho de tarefas de manutenção, levadas a cabo por um grupo experimental de utilizadores. Espera-se que os resultados demonstrem que à medida que os programas se tornam mais complexos, se torne cada dez mais difícil localizar determinados elementos visuais manualmente, apenas com base no código fonte. Por outro lado com o mecanismo proposto espera-se obter uma redução significativa de tempo dispendido ao determinar que elementos gráficos correspondem a determinadas instruções. Referências 1. Bogdan Dit, Meghan Revelle, Malcom Gethers, and Denys Poshyvanyk. Feature location in source code: a taxonomy and survey. Journal of Software: Evolution and Process, 25(1):53 95,

64 2. Andrew J. Ko, Htet Aung, and Brad A. Myers. Eliciting design requirements for maintenance-oriented ides: a detailed study of corrective and perfective maintenance tasks. In Proceedings of the 27th international conference on Software engineering, ICSE 05, pages , New York, NY, USA, ACM. 3. Andrew J. Ko, Brad A. Myers, Michael J. Coblenz, and Htet Htet Aung. An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks. IEEE Trans. Softw. Eng., 32: , December André L. Santos. GUI-driven code tracing. In VL/HCC: IEEE Symposium on Visual Languages and Human-Centric Computing, Innsbruck, Austria, September Picasso toolkit. acedido a 1 de Agosto de YARI toolkit. acedido a 1 de Agosto de

65 Prevenção de Violações de Atomicidade usando Contratos Diogo G. Sousa, Carla Ferreira e João M. Lourenço CITI Departamento de Informática, Universidade Nova de Lisboa, Portugal Resumo A programação concorrente obriga o programador a sincronizar os acessos concorrentes a regiões de memória partilhada, contudo esta abordagem não é suficiente para evitar todas as anomalias que podem ocorrer num cenário concorrente. Executar uma sequência de operações atómicas pode causar violações de atomicidade se existir uma correlação entre essas operações, devendo o programador garantir que toda a sequência de operações é executada atomicamente. Este problema é especialmente comum quando se usam operações de pacotes ou módulos de terceiros, pois o programador pode identificar incorretamente o âmbito das regiões de código que precisam de ser atómicas para garantir o correto comportamento do programa. Para evitar este problema o programador do módulo pode criar um contrato que especifica quais as sequências de operações do módulo que devem ser sempre executadas de forma atómica. Este trabalho apresenta uma análise estática para verificação destes contratos. Keywords: Verificação de Protocolos, Concorrência, Violações de Atomicidade, Programação por Contrato, Thread Safety, Análise Estática, Verificação de Software 1 Introdução O encapsulamento do funcionamento interno da implementação de um módulo de software oferece fortes vantagens no desenvolvimento de software, pois permite a sua reutilização e facilita a manutenção de código. No entanto esta transparência de utilização pode levar a utilizações incorretas de um módulo devido ao programador não estar consciente dos detalhes de implementação. Um dos requisitos para o correto comportamento de um módulo é respeitar o seu protocolo, que determina quais as sequências de invocações a métodos que são legítimas. Por exemplo, um módulo que ofereça uma abstração para lidar com ficheiros tipicamente exige que o programador comece por chamar o método Este trabalho foi parcialmente financiado pela Fundação para a Ciência e Tecnologia (FCT/MCTES), no contexto do projecto de investigação PTDC/EIA- EIA/113613/

66 void schedule() { Task t=taskqueue.next(); } if (t.isready()) t.run(); Figura 1: Programa com uma violação de atomicidade. open(), seguido de um número arbitrário de read()s ou write()s, e por fim de close(). Um programa que não cumpra este protocolo está incorreto e deve ser corrigido. Uma solução é usar a metodologia de programação por contrato [19], onde o programador do módulo especifica qual o seu protocolo de utilização. Este contrato, para além de servir como documentação do módulo, pode ser verificado automaticamente, assegurando que um programa cumpre o contrato do módulo [7, 14]. A programação concorrente levanta novos desafios em relação ao protocolo de um módulo. Não só é importante respeitar o protocolo do módulo como é necessário garantir a execução atómica de determinadas sequências de chamadas suscetíveis de causarem violações de atomicidade. Estas violações de atomicidade são possíveis mesmo se os métodos do módulo empregarem mecanismos de controlo de concorrência. Tomemos como exemplo o programa apresentado na Figura 1. Este programa está encarregado de escalonar tarefas. O método schedule() obtém uma tarefa e executa-a se esta está pronta para tal. Este programa contem uma potencial violação de atomicidade, pois o método pode executar uma tarefa que não está pronta devido a um thread concorrente ter executado a mesma tarefa. Neste caso os métodos isready() e run() devem ser executados no mesmo contexto atómico para evitar violações de atomicidade. As violações de atomicidade são um problema comum em programação concorrente [18] e são particularmente propensas a serem introduzidas quando se compõem chamadas a um módulo, por o programador poder não estar consciente da implementação e estado interno do módulo. Neste artigo propomos estender os protocolos de utilização de módulos com uma especificação das sequências de chamadas ao módulo que devem ser executadas atomicamente, de forma a evitar violações de atomicidade. As contribuições deste trabalho são: 1. Uma análise estática para extrair o comportamento de um programa relativamente às sequências de chamadas que pode executar; 2. Uma análise estática para verificar a atomicidade de sequências de chamadas a um módulo por parte do programa cliente. Na Secção 2 definimos a especificação do contrato e a sua semântica. A Secção 3 contem a metodologia geral da análise. A Secção 4 apresenta a fase da análise que extrai o comportamento do programa cliente e a Secção 5 demonstra como verificar o contrato. Segue-se a Secção 6 com a demonstração experimental do nosso trabalho. O trabalho relacionado é apresentado na Secção 7 e terminamos com as conclusões na Secção 8. 52

67 2 Especificação do Contrato O contrato de um módulo determina quais as sequências de chamadas aos seus métodos públicos que devem ser executadas atomicamente pelo programa cliente de forma a evitar violações de atomicidade. O programador do módulo deve ser responsável por identificar estas sequências de chamadas e definir o contrato. Definição 1 (Contrato). A especificação do contrato de um módulo com os métodos públicos m 1,, m n tem a forma, 1. e 1. k. e k. Cada cláusula i do contrato é descrita por e i, uma expressão regular sem fecho de Kleene sobre o alfabeto {m 1,, m n }. Expressões regulares sem fecho de Kleene são expressões regulares que não usam a estrela de Kleene, tendo apenas os operadores de alternativa ( ) e concatenação (omisso). Cada sequência definida em e i tem de ser executada atomicamente pelo programa cliente do módulo, caso contrário isso representa uma violação do contrato. O contrato especifica um número finito de sequências de chamadas, por ser uma união de linguagens livres de estrela. Por isso é possível ter a mesma expressividade enumerando explicitamente todas as sequências de chamadas, i.e. evitando a utilização do operador de alternativa. Escolhemos oferecer o operador de alternativa para que se possa agrupar na mesma cláusula várias sequências que sejam similares. É um pré-requisito da análise apresentada que o contrato defina um número finito de sequências de chamadas. Exemplo Consideremos a implementação de arrays oferecida pela biblioteca standard de Java, java.util.arraylist. O seguinte contrato define duas das possíveis cláusulas desta classe. 1. contains indexof 2. indexof (set remove get) A cláusula 1 do contrato da ArrayList indica que a execução do método contains() seguido de indexof() deve ser feita de maneira atómica, caso contrário um programa cliente pode confirmar a existência de um objeto no array mas falhar ao obter o seu índice devido a uma modificação concorrente. A cláusula 2 representa um cenário semelhante onde adicionalmente se modifica essa posição do objeto obtido. 3 Metodologia A análise proposta verifica estaticamente se um programa cliente cumpre o contrato de um dado módulo como definido na Secção 2. Para isto verificamos que 53

68 cada thread que o programa possa lançar executa sempre de forma atómica todas das sequências de chamadas definidas pelas cláusulas do contrato. Esta análise é composta pelas seguintes fases: 1. Determinar os métodos de entrada de cada thread que o programa pode executar. 2. Determinar quais os métodos do programa que são executados atomicamente. Dizemos que um método é executado atomicamente se este for atómico 1 ou se for sempre chamado por métodos executados atomicamente. 3. Extrair o comportamento de utilização do módulo sob análise de cada thread do programa. 4. Para cada thread, verificar que a sua utilização do módulo respeita sempre o contrato, como definido na Secção 2. Na Secção 4 apresentamos o algoritmo de extração do comportamento do programa cliente relativamente à utilização do módulo. Na Secção 5 definimos a análise que verifica se o comportamento extraído cumpre o contrato. 4 Extração do Comportamento do Programa O comportamento do programa relativamente à sua utilização de um módulo pode ser visto como o comportamento individual de cada thread que o programa possa executar. A utilização de um módulo por um thread do programa pode ser descrita por uma linguagem L onde cada palavra w L representa um sequência de chamadas do programa a métodos do módulo. Esta fase da análise gera uma gramática livre de contexto que representa esta linguagem L a partir de um thread t do programa cliente, representado pelo seu control flow graph (CFG) [1]. O CFG do thread t representa todas os possíveis caminhos que o control flow pode tomar na sua execução. Em concreto a análise gera uma gramática G t tal que, se for possível alguma execução de t correr a sequência de chamadas m 1,, m n, então m 1 m n L(G t ). (L(G) denota a linguagem representada pela gramática G.) Definição 2 (Gramática do Comportamento de um Thread do Programa). A gramática G t = (N, Σ, P, S) é criada a partir do CFG do thread t do programa cliente. Definimos, N, o conjunto de não-terminais, como o conjunto de nós do CFG mais um conjunto de não-terminais que representam cada um dos método do programa cliente (representados em fonte caligráfica); Σ, o conjunto de terminais, como o conjunto dos identificadores dos métodos públicos do módulo sob análise (representado a negrito); P, o conjunto das produções, como descrito em baixo, pelas as Regras 1 5. S, o símbolo inicial da gramática, como o não-terminal que representa o método de entrada do thread t. 1 Um método atómico é um método onde explicitamente se aplica algum mecanismo de controlo de concorrência que lhe garante atomicidade. 54

69 Para cada método f(), potencialmente usado pelo thread t, que representamos por F, adicionamos a P as produções que respeitam as restrições das Regras 1 5. Denotamos um nó do CFG por α : v, onde α é o não-terminal que representa o nó e v o seu tipo. Distinguimos os seguintes tipos de nó: entry, o nó de entrada do método F; module.h(), uma chamada ao método h() do módulo sob análise; g(), uma chamada a um outro método do programa cliente; e return, o ponto de retorno do método F. A função succ : N P(N) é usada para obter os sucessores de um dado nó do CFG. se α : entry, {F α} {α β β succ(α)} P (1) se α : module.h(), {α h β β succ(α)} P (2) se α : g(), {α G β β succ(α)} P onde G representa g() (3) se α : return, {α ɛ} P (4) se α : c.c., {α β β succ(α)} P (5) Mais nenhuma produção pertence a P. As Regras 1 5 capturam a estrutura do CFG sob a forma de uma linguagem livre de contexto. A Regra 1 adiciona a produção que relaciona o não-terminal F, que representa o método f(), ao nó de entrada do CFG de f(). As chamadas ao módulo sob análise são registadas na gramática (Regra 2). A Regra 3 lida com as chamadas a um outro método g() dentro do programa cliente (o método g() terá o seu não-terminal G adicionado pela Regra 1). O ponto de retorno do método, adiciona uma produção ɛ (Regra 4). Todos os outros tipos de nó do CFG são tratados uniformemente, apenas fazendo a ligação para os nós sucessores (Regra 5). É de notar que apenas o código do programa cliente é analisado. Intuitivamente esta gramática representa o control flow do thread t do programa, ignorando o que não é relevante relativamente à sua utilização do módulo. Por exemplo, se f g L(G t ) então o thread t pode ter uma execução onde executa consecutivamente os método f() e g() do módulo. A gramática G t pode ser ambígua, ou seja, oferecer várias derivações diferentes para a mesma palavra. Cada ambiguidade no parsing de uma sequência de chamadas m 1 m n L(G t ) representa diferentes contextos onde essas chamadas podem ser executadas pelo thread t. É portanto desejável manter a gramática ambígua para que a verificação do contrato tenha em conta todas as ocorrências das sequências de chamadas no programa cliente. A linguagem L(G t ) pode conter sequências de chamadas que o programa não executa, por exemplo, considerando um caminho no CFG que nunca é executado. No entanto a linguagem L(G t ) contem todas as sequências de chamadas que o programa pode executar, não produzindo falsos negativos. Exemplo Consideremos o programa apresentado na Figura 2. Este programa exemplifica como a análise lida com ciclos e recursividade. O programa tem apenas o método f(), sendo este o ponto de entrada to thread em questão. O módulo sob análise é representado pelo objeto m. O CFG deste método está 55

70 void f() { while (m.a()) { if (cond) m.b(); else m.c(); } } m.d(); f(); A entry B m.a() C cond D E m.b() m.c() f() F G m.d() H return Figura 2: Programa que usa o módulo m (esquerda) e respetivo CFG (direita). representado na Figura 2 (direita). Segundo a Definição 2 construimos a gramática G = (N, Σ, P, S), onde N = {F, A, B, C, D, E, F, G, H}, Σ = {a, b, c, d} e S = F. As produções P da gramática são, F A C D E F F B A B D b F G d H B a C a G E c F H ɛ. 5 Verificação de Contratos A verificação de um contrato garante que todas as sequências de chamadas definidas por este são executadas de forma atómica em todos os threads do programa cliente. Visto que existe um número finito de sequências definidas pelo contrato verificamos cada uma das sequências para verificar o contrato. O Algoritmo 1 apresenta o pseudo-código que verifica um contrato contra um programa cliente. Para cada thread t do programa cliente é necessário saber onde ocorrem, no programa, cada uma das sequências w = m 1,, m n definidas pelo contrato (linha 4). Para isso fazemos o parsing destas sequências na gramática G t (linha 5). A gramática G t inclui todas as palavras e sub-palavras de G t. As subpalavras têm de ser incluídas pois é necessário ter em conta traços de execução parciais do thread t. A gramática G t pode ser ambígua e cada árvore de parsing distinta representa diferentes execuções de m 1,, m n que podem ocorrer no thread t. A função parse() devolve o conjunto destas árvores de parsing. Se subirmos na árvore de parsing iremos encontrar o nó que representa o método sobre o qual todas as chamadas aos métodos m 1,, m n são executadas. Este nó é o lowest common ancestor dos terminais m 1,, m n na árvore de parsing (linha 7). Temos portanto que se o lowest common ancestor obtido for executado atomicamente (linha 8) então toda a sequência de chamadas é executada sobre 56

71 Algoritmo 1 Algoritmo de verificação do contrato. Require: P, o programa cliente; C, o contrato do módulo (conjunto de sequências). 1: for t threads(p ) do 2: G t make_grammar(t) 3: G t subword_grammar(g t) 4: for w C do 5: T parse(g t, w) 6: for τ T do 7: N lowest_common_ancestor(τ, w) 8: if run_atomically(n) then 9: return ERROR 10: return OK o mesmo contexto atómico, respeitando o contrato. A árvore de parsing tem informação da localização no código onde pode ocorrer um violação do contrato e podemos oferecer instruções ao utilizador de onde esta ocorre e como a evitar. A gramática G t pode usar toda a expressividade oferecida pelas linguagens livres de contexto. Por isso não é suficiente usar o algoritmo LR( ) [16] para a fase de parsing, visto que este não lida com ambiguidades na gramática. Para contornar isto podemos usar um parser GLR (Generalized LR parser), que explora todas as ambiguidades que podem dar origem a diferentes árvores de derivação. Tomita apresenta um parser GLR [21], uma versão não-determinista do algoritmo LR(0), bem como algumas otimizações na representação da stack de parsing que reduzem a complexidade temporal e espacial da fase de parsing. Outro aspeto importante a ter em conta é que o número de árvores de parsing pode ser infinito. Isto é devido a ciclos na gramática, ou seja, derivações de um não-terminal para si próprio (A A), o que é comum em G t. Por este motivo a função parse() deve detetar ciclos redundantes e terminar a exploração desse ramo de parsing. Para isto o algoritmo deve detetar um ciclos na lista de reduções aplicadas e abortar o ramo atual de parsing se este ciclo não tiver contribuído para o reconhecimento de um novo terminal. Exemplos A Figura 3 apresenta um programa (esquerda), que usa o módulo m, com três métodos, onde o método run() é o ponto de entrada de um thread t e é atómico. No centro da figura apresentamos a gramática G t simplificada. (Não apresentamos a gramática G t por motivos de brevidade.) Os métodos run(), f() e g() são representados na gramática pelos não-terminais R, F e G respetivamente. Se aplicarmos o Algoritmo 1 a este programa com o contrato C = {a b b c} a árvore de parsing obtida (representada por τ na linha 6 do algoritmo) é apresentada na Figura 3 (direita). Para verificar que todas as chamadas representadas nesta árvore de parsing são executadas atomicamente o algoritmo de verificação obtém o lowest common ancestor de a b b c na árvore (linha 7), neste caso R. Como R é executado atomicamente (atomic) este contrato está a ser respeitado pelo programa cliente do módulo. 57

72 void atomic run() { f(); m.c(); } void f() { m.a(); g(); } void g() { while (cond) m.b(); } R F c F a G G A A B ɛ B b A R F G A B A B A a b b ɛ c Figura 3: Programa (esquerda), gramática simplificada (centro) e árvore de parsing de a b b c (direita). void run() { if (...) { m.a(); g(); } else f(); } void atomic f() { m.a(); g(); } void atomic g() { m.b(); } R a G F F a G G b Figura 4: Programa (esquerda), gramática simplificada (centro) e árvores de parsing de a b (direita). A Figura 4 exemplifica uma situação onde a gramática gerada é ambígua. Neste caso temos o contrato C = {a b}. A figura mostra as duas maneira de fazer parsing da palavra a b (direita). O Algoritmo 1 vai gerar ambas as árvores. A primeira árvore (cima) tem como lowest common ancestor de a b o não-terminal F, que corresponde ao método f(). Este método é executado atomicamente, respeitando o contrato. Por sua vez a segunda árvore (baixo) tem R como lowest common ancestor de a b. Este não-terminal não corresponde a um método executado atomicamente e por isso o contrato não é cumprido. 6 Validação Foi implementado um protótipo para avaliar a análise apresentada. Esta ferramenta analisa programas Java utilizando a framework de análise estática Soot [22]. Esta framework analisa diretamente Java bytecode, permitindo a análise de um programa compilado, sem necessitar de aceder ao seu código fonte. Para validar a análise proposta foram usados 15 testes tirados da literatura relacionada. Estes testes são programas que contêm violações de atomicidade conhecidas. Modificamos estes testes para um desenho modular e escrevemos a a R F R G b G b 58

73 Tabela 1: Resultados de validação. Teste Threads Palavras do Violações Contrato Detetadas Account [24] Allocate Vector [15] Arithmetic DB [17] Connection [4] Coord03 [2] Coord04 [3] Elevator [24] Jigsaw [24] Knight [17] Local [2] StringBuffer [3] NASA [2] Store [20] UnderReporting [24] VectorFail [20] contratos para verificar o escopo atómico das chamadas a este módulo. Em alguns testes os contratos contêm cláusulas com sequências de chamadas que os testes não executam, mas que, por completude, devem pertencer ao contrato. A Tabela 1 apresenta os resultados que validam a correção da análise proposta. As colunas representam o número de métodos de entrada de threads (Threads); o número de palavras do contrato, ou seja, C como definido no Algoritmo 1 (Palavras do Contrato); e o número de violações do contrato detetadas (Violações Detetadas). A nossa ferramenta detetou todas as violações do contrato pelo programa cliente, pelo que não existem falsos negativos, o que suporta a soundness da análise. Em nenhum dos testes foram reportados falsos positivos. Embora seja possível construir programas que levam a falsas violações, isto tende a não acontecer. Uma versão corrigida dos testes foi verificada e o protótipo identificou corretamente todas as sequências de chamadas do contrato como estando agora a ser executadas atomicamente. Todas as sequências de chamadas dos contratos verificados têm tamanho dois. A avaliação da performance é apresentada na Tabela 2. As colunas representam o número de linhas do programa cliente (SLOC Cliente); o número de nós do CFG do programa cliente (Nós CFG Cliente); o número de produções da gramática (Produções Gramática); o número de ramos de parsing que o parser explorou, incluindo ramos que falharam (Ramos de Parsing); e o tempo de análise, que inclui a deteção de threads, geração da gramática, criação das tabelas de parsing e parsing (Tempo de Execução). Esta coluna exclui o tempo de inicialização do Soot, que para estes testes foram sempre de 35 ± 5 s. Os resultados de performance mostram que a análise é eficiente. O programa Elevator é o teste mais lento, pois o parser explora um número razoavelmente elevado de ramos. Isto deve-se à complexidade do CFG deste teste. Em geral o tempo de parsing vai dominar a complexidade temporal da análise, ou seja, o tempo de execução 59

74 Tabela 2: Resultados de performance. Teste SLOC Nós CFG Produções Ramos de Tempo de Cliente Cliente Gramática Parsing Execução (ms) Account Allocate Vector Arithmetic DB Connection Coord Coord Elevator Jigsaw Knight Local StringBuffer NASA Store UnderReporting VectorFail vai ser proporcional ao número de ramos de parsing explorados. A utilização de memória não é um problema pois a complexidade espacial é determinada pelo tamanho da tabela de parsing e pelo tamanho da maior árvore de parsing. A utilização de memória não é afetada pelo número de árvores de parsing porque o nosso GLR parser explora os ramos de parsing em profundidade em vez de em largura. Isto é possível porque nunca temos árvores de parsing de altura infinita devido à deteção de ciclos improdutivos. 7 Trabalho Relacionado A programação por contrato foi introduzida por Meyer [19] como uma técnica para facilitar a escrita de código robusto e promover a reutilização de código baseada em contratos entre programas e objetos. Estes contratos especificam as condições necessárias para métodos do objeto poderem ser chamados, garantindo a sua correta semântica caso as pré-condições sejam cumpridas. Cheon et al propôs a utilização de contratos para especificar protocolos de utilização de objetos [7]. O autor apresenta uma análise dinâmica para a verificação destes contratos. Isto contrasta com o nosso trabalho que valida estaticamente os contratos. Beckman et al apresentam uma metodologia baseada em typestate, para verificar estaticamente que um protocolo de um objeto é cumprido [4]. Esta aproximação requer que o programador faça explicitamente unpack dos objetos antes de invocar os seus métodos. Hurlin [14] estende o trabalho de Cheon para suportar protocolos em cenários concorrentes. São adicionados ao protocolo operadores para permitir especificar que métodos podem ser executados em concorrência, e pré-condições que têm que ser satisfeitas para a execução de determinado método. A análise pode ser verificada estaticamente usando um theorem prover. Em geral aproximações baseadas em theorem proving são limitadas pois são ineficientes e, normalmente, indecidíveis para lógicas não triviais. Muitos trabalhos podem ser encontrados sobre violações de atomicidade. Alguns destes trabalhos podem potencialmente ser usados para a inferência automática dos contratos de módulos que apresentámos neste artigo. Artho et al 60

75 definem em [2] a noção de High-Level Data Races, que caracteriza sequências de operações atómicas que devem ser corridas de no mesmo contexto atómico para evitar problemas de atomicidade. As High-Level Data Races não capturam na totalidade as violações de atomicidade que podem ocorrer num programa. Praun and Gross estendem a aproximação de Artho para detetar potenciais anomalias na execução de métodos de um objeto e aumentam a precisão da análise distinguindo acessos de leitura e escrita sobre variáveis partilhadas entre threads [24]. Um refinamento adiciona às High-Level Data Races foi introduzido por Pessanha em [9] relaxando as propriedade definidas por Artho o que resulta numa melhor precisão da análise. Farchi et al propõe ainda uma metodologia para a deteção de violações de atomicidade em utilizações de módulos [10], baseado na definição de High-Level Data Race. Outro tipo de violações de atomicidade comuns quando se compõe operações executadas atomicamente são os stale value errors. Estas anomalias são caracterizadas pela utilização de valores obtidos de forma atómica em múltiplas operações atómicas, podendo estes estar desatualizados e comprometer a correção programa. Várias análises foram desenvolvidas para detetar este tipo de problema [3, 5, 9]. Diversas análises de verificação de violações de atomicidade podem ser encontradas na literatura, baseadas em padrões de acesso a variáveis suscetíveis a causar anomalias [17, 23], sistemas de tipos [6], invariantes semânticos [8], e outras metodologias especificas [11, 12, 13]. 8 Conclusões Neste artigo apresentamos o problema da ocorrência de violações de atomicidade na utilização de um módulo, independentemente dos seus métodos estarem individualmente sincronizados por algum mecanismo de controlo de concorrência. Para isso propomos um solução baseada na metodologia de programação por contrato. Estes contratos determinam quais as sequências de chamadas a métodos do módulo que deve ser executadas de forma atómica. Apresentamos uma análise estática para a verificação deste contratos. A análise proposta extrai o comportamento do programa cliente em relação à utilização do módulo e verifica que este cumpre o contrato. A fase de extração do comportamento do programa é versátil, podendo ser facilmente adaptada para outras análises baseadas no comportamento do control flow do programa. Foi implementado um prototipo e os resultados experimentais mostram que a análise tem boa precisão e é eficiente. Referências 1. Frances E. Allen. Control flow analysis. SIGPLAN Not., 5(7):1 19, July Cyrille Artho, Klaus Havelund, and Armin Biere. High-level data races. Software Testing, Verification and Reliability, 13(4): , December Cyrille Artho, Klaus Havelund, and Armin Biere. Using block-local atomicity to detect stale-value concurrency errors. Automated Technology for Verification and Analysis, pages , Nels E. Beckman, Kevin Bierhoff, and Jonathan Aldrich. Verifying correct usage of atomic blocks and typestate. SIGPLAN Not., 43(10): , October

76 5. M. Burrows and K.R.M. Leino. Finding stale-value errors in concurrent programs. Concurrency and Computation: Practice and Experience, 16(12): , Luís Caires and João C. Seco. The type discipline of behavioral separation. SIG- PLAN Not., 48(1): , January Yoonsik Cheon and Ashaveena Perumandla. Specifying and checking method call sequences of java programs. Software Quality Control, 15(1):7 25, March R. Demeyer and W. Vanhoof. A framework for verifying the application-level racefreeness of concurrent programs. In 22nd Workshop on Logic-based Programming Environments (WLPE 2012), page 10, Ricardo J. Dias, Vasco Pessanha, and João M. Lourenço. Precise detection of atomicity violations. In Hardware and Software: Verification and Testing, Lecture Notes in Computer Science. Springer Berlin / Heidelberg, November HVC 2012 Best Paper Award. 10. Eitan Farchi, Itai Segall, João M. Lourenço, and Diogo Sousa. Using program closures to make an API implementation thread safe. In Proceedings of the 2012 Workshop on Parallel and Distributed Systems: Testing, Analysis, and Debugging, PADTAD 2012, pages 18 24, New York, NY, USA, ACM. 11. Cormac Flanagan and Stephen N Freund. Atomizer: a dynamic atomicity checker for multithreaded programs. SIGPLAN Not., 39(1): , January Cormac Flanagan and Stephen N. Freund. FastTrack: efficient and precise dynamic race detection. Commun. ACM, 53(11):93 101, November Cormac Flanagan, Stephen N. Freund, and Jaeheon Yi. Velodrome: a sound and complete dynamic atomicity checker for multithreaded programs. SIGPLAN Not., 43(6): , June Clément Hurlin. Specifying and checking protocols of multithreaded classes. In Proceedings of the 2009 ACM symposium on Applied Computing, SAC 09, pages , New York, NY, USA, ACM. 15. IBM s Concurrency Testing Repository. 16. Donald E Knuth. On the translation of languages from left to right. Information and control, 8(6): , J. Lourenço, D. Sousa, B. Teixeira, and R. Dias. Detecting concurrency anomalies in transactional memory programs. Computer Science and Information Systems/- ComSIS, 8(2): , Shan Lu, Soyeon Park, Eunsoo Seo, and Yuanyuan Zhou. Learning from mistakes: a comprehensive study on real world concurrency bug characteristics. SIGPLAN Not., 43(3): , March Bertrand Meyer. Applying "design by contract". Computer, 25(10):40 51, October Vasco Pessanha. Verificação prática de anomalias em programas de memória transaccional. Master s thesis, Universidade Nova de Lisboa, Masaru Tomita. An efficient augmented-context-free parsing algorithm. Comput. Linguist., 13(1-2):31 46, January Raja Vallée-Rai, Phong Co, Etienne Gagnon, Laurie Hendren, Patrick Lam, and Vijay Sundaresan. Soot - a java bytecode optimization framework. In Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research, CASCON 99, pages 13. IBM Press, M. Vaziri, F. Tip, and J. Dolby. Associating synchronization constraints with data in an object-oriented language. In ACM SIGPLAN Notices, volume 41, pages ACM, C. Von Praun and T.R. Gross. Static detection of atomicity violations in objectoriented programs. Journal of Object Technology, 3(6): ,

77 Computação Gráfica 63

78 Ambientes Urbanos Virtuais para a Web Joana Filipa Barbosa 1, António Fernando Coelho 1, Carlos Rebelo 2 1 Departamento de Engenharia Informática, Faculdade de Engenharia, Universidade do Porto / INESC TEC, Rua Dr. Roberto Frias, s/n, Porto, Portugal {joana.filipa.barbosa, 2 3Decide - Praça Coronel Pacheco, 2, Porto, Portugal Resumo. Este projeto, baseando-se no estudo das recentes evoluções das tecnologias para a Web, nomeadamente o HTML5 e o WebGL, tem como objetivo explorar o desenvolvimento de uma aplicação interativa que disponibiliza ambientes 3D de espaços urbanos de uma forma nativa no browser. Este tipo de aplicação deverá ter em conta conceitos de interação pessoa-computador, baseando-se no modo como o utilizador adquire informação sobre espaços através de conteúdos tridimensionais, para oferecer uma interface usável e apelativa. Este sistema surge no contexto do produto alive Places, a ser presentemente desenvolvido pela empresa 3Decide. Esta aplicação integra também um módulo direcionado à divulgação de eventos, possibilitando a qualquer responsável pela organização de um evento utilizar o modelo tridimensional interativo como uma espécie de convite, atribuindo-lhe todas as informações associadas ao mesmo. Keywords: Ambientes urbanos, 3D interativo, Web3D, WebGL, HTML5 1 Introdução O presente projeto enquadra-se no contexto das aplicações gráficas interativas, pretendendo explorar uma lacuna ainda existente nas versões mais recentes destes sistemas: a disponibilização destes de forma nativa na Web. Com a emergência de novas tecnologias capazes de trazer ao browser do utilizador comum um ambiente tridimensional com novas e otimizadas formas de interação, a evolução destes softwares torna-se uma necessidade. Este projeto pretende oferecer a empresas e outras organizações uma ferramenta inovadora de partilha de informação relevante de um modo prático, dinâmico e apelativo com o objetivo de deixar uma marca positiva junto dos utilizadores finais, beneficiando de forma essencial as instituições clientes. É neste contexto que se insere o problema a resolver: como criar um sistema de representação de ambientes urbanos baseado nas mais recentes e promissoras 64

79 tecnologias 3D para a Web, que tenha em conta a interação com o utilizador e que torne estes ambientes e tecnologias bem aceites pelo público geral, levando-os à sua utilização habitual em situações do dia-a-dia, especificamente, dado o âmbito do protótipo, na participação de um evento. Para isso é necessário investigar um conjunto de temáticas-chave. A primeira dessas será a representação de ambientes urbanos tridimensionais no contexto web, avaliando e comparando tecnologias que permitam a criação destes cenários. Revelase igualmente importante estudar como é concretizada a promoção de locais dedicados à realização de eventos e como esta informação alcança os utilizadores. Para além disto terão de ser estudadas abordagens para a construção de interatividade nos cenários representados, tendo em conta conceitos de interação entre pessoa e computador, nomeadamente aqueles relativos à obtenção de informação de espaços a partir da navegação em ambientes virtuais. Num caráter mais técnico será necessário investigar, comparar e selecionar uma tecnologia apropriada à resolução do problema proposto. O presente projeto foi desenvolvido conjuntamente com a empresa 3Decide 1, no contexto de um produto que a mesma se encontra a desenvolver, o alive Places 2. 2 Estado da Arte Os artigos de Grupp[1] e Ortiz[2] serviram de base de estudo das tecnologias de desenvolvimento. Através da apresentação e comparação das tecnologias mais relevantes, acompanhadas de opiniões de especialistas diretamente envolvidos no desenvolvimento de algumas destas tecnologias e de dados noticiados ao longo das evolução das mesmas, estes artigos auxiliaram a escolha da melhor tecnologia, nomeadamente no contexto das aplicações 3D para a Web com renderização acelerada por hardware, a utilizar para o presente projeto. Dada a importância da interação no sistema a criar, e o contexto da promoção de um evento a ser desenvolvido no protótipo, o artigo de Chittaro et al.[3], assim como os estudos realizados por Oulasvirta et al.[4] forneceram pistas para compreender como o ser humano adquire informação sobre um espaço, sobre a navegação de percursos nesse espaço, e de como os utilizadores reagem aos diferentes formatos de disponibilização dessa informação. Enquanto que em Chittaro et al., e tendo por base um caso de estudo com um mapa 3D com GPS, as conclusões tiradas foram de que as pessoas não tinham dificuldades em associar objetos reais a objetos da cena tridimensional, o que mostra as vantagens deste formato em situações de orientação e localização por parte dos utilizadores. Já nos estudos de Oulasvirta et al., comparando situações de orientação mas também navegação para alcançar uma localização de destino através de mapas 2D e 3D, os resultados mostraram que apesar da conclusão de Chittaro et al. se verificarem, nos mapas 3D os utilizadores apresentavam dificuldades de localização relativa ao destino a alcançar, acabando por vezes por se perderem, nomeadamente por falta de uma perspetiva geral. Estes são dados de vital

80 relevância tidos em conta na construção da interação do presente projeto, de forma a alcançar uma melhor aceitação por parte dos utilizadores finais. Por último, no contexto dos projetos semelhantes ao nível da representação de ambientes urbanos virtuais tridimensionais, aqueles que permitiram uma mais próxima comparação com o projeto a desenvolver, permitindo assim avaliar as diversas componentes a abordar, foram os projetos de divulgação do campus da Universidade de Agricultura de Shenyang[5], e também o projeto de promoção da mesquita Alaca Imaret[6]. Estes relacionam-se também de forma próxima com o conceito de divulgação de uma representação espacial para as grandes massas, conceito objetivo do presente projeto. 2.1 Seleção de Tecnologia Após a investigação das tecnologias de renderização 3D disponíveis para a Web foram selecionadas apenas as 3 mais promissoras, especificamente as que apresentam um projeto mais atualizado e acessível ao utilizador comum e que permitem uma renderização acelerada por hardware. Foi criada a Tabela 1 para comparar as tecnologias a partir de uma análise mais detalhada. Tabela 1 - Comparação das tecnologias 3D para a Web Silverlight 5 3 Stage 3D 4 (Flash) WebGL 5 (HTML5) Software Proprietário Proprietário Livre Browsers IE6+, Firefox3+, Chrome, Safari Todos Versões recentes de Chrome, Firefox, Safari; Plugin Sim Sim Não Mobile Windows Phone 7.x Não Blackberry e Android; Contras Pouca aposta na componente 3D Suporte a dispositivos móveis descontinuado Baixo nível; Ainda com diferenças de performance Prós Boa performance; Ligação ao XNA Plataforma dominante nos browsers Ligação com HTML5 que se encontra em crescimento Depois do estudo das tecnologias 3D disponíveis para a Web, a tecnologia eleita foi o WebGL. Esta decisão justifica-se pelo grande crescimento e evolução da mesma e pelas características únicas em relação às outras: o seu carácter open-source e o facto de ser a única que permite a renderização de conteúdos 3D sem requerer instalação de plug-ins, tornando-se portanto muito mais acessível para um grupo diversificado de utilizadores. O facto de esta tecnologia ser o único standard web, apoiado por um conjunto de várias empresas relevantes na área da computação gráfica

81 e dos browsers Web, pode levar a que esta se torne, de forma mais madura, numa ferramenta de acesso globalizado permitindo aos seus programadores alcançar, de igual forma e sem desenvolvimento personalizado, os dispositivos, sistemas operativos e browsers de maior relevância. De forma a contornar a característica low-level desta tecnologia foi também selecionada uma biblioteca mais alto nível construída sobre o WebGL, nomeadamente a Three.js 6. A Three.js é uma API alto-nível, em Javascript, que pode ser usada com SVG e com o elemento canvas do HTML além do WebGL. Possui suporte às funcionalidades básicas de renderização gráfica, assim como animações, colisões e iluminação. Provavelmente a API mais popular para WebGL, e portanto fácil de encontrar tutoriais e demonstrações. A escolha desta API está diretamente relacionada com a facilidade de obtenção de informação de aprendizagem, além da já grande diversidade de funcionalidades que a mesma apresenta de momento. 3 Solução No contexto do produto alive Places e no decorrer da sua divulgação a potenciais clientes, a empresa 3Decide começou a deparar-se com uma nova problemática. Dado o caráter promocional deste tipo de aplicação, diferentes utilizadores, a partir de variados dispositivos, sistemas operativos e browsers, e com distintos níveis de experiência com softwares semelhantes, devem ter acesso ao sistema. Assim, torna-se importante assegurar que em todos estes casos a aplicação esteja operacional e seja funcionalmente idêntica. Além disto, muitos destes utilizadores não estariam interessados em ter de instalar software adicional no seu dispositivo pessoal para poderem ter acesso à aplicação, reduzindo imediatamente o valor do produto. Deste modo, surgiu o propósito desse projeto, a migração da ideia base do produto alive Places para um ambiente Web nativo, que seja capaz de alcançar um espectro de público mais abrangente. Neste novo sistema deverá ser possível ao utilizador interagir com a cena 3D de diferentes modos. Esta cena é criada a partir da interpretação de plantas/desenhos CAD com auxílio da ferramenta CityEngine e utilizando modelos criados de forma manual e/ou procedimental. O sistema deverá também permitir a navegação pelos diferentes níveis do modelo e como consequência destas interações deverá ser apresentada, de forma integrada e a partir da ligação ao back-office, toda a informação associada ao espaço representado. Existe ainda um outro objetivo associado a este sistema, que consiste na aplicação desta plataforma a um contexto de gestão de agenda de eventos. Esta implementação funcionará como uma nova camada de funcionalidades que será adicionada ao módulo base, e deverá consistir numa prototipagem que inclui informações sobre os eventos e as variadas atividades que os compõem, relacionando-os com os espaços onde estes decorrem. Este módulo deverá também incluir a integração da cena 3D com os detalhes dos eventos

82 3.1 Arquitetura do Sistema O sistema final constituído por 2 módulos principais: o back-office, coincidente com o do produto alive Places e onde são geridas todas as operações relativas à base de dados, e o front-office que corresponde ao projeto a ser desenvolvido na íntegra. Cena 3D Espaços API Informação Eventos Utilizadores Carregamento dos dados da cena 3D e da informação a apresentar Base de Dados Fig. 1 Diagrama de arquitetura do sistema O front-office subdivide-se em alguns componentes. O módulo da cena 3D diz respeito à renderização e funcionalidades de interação com os modelos tridimensionais. O componente de informação, composto pela informação dos espaços e pelos dados da gestão de eventos, é responsável por toda a apresentação e interação com os dados alfanuméricos que complementam a cena tridimensional. De forma não tão visível ao utilizador final, existem ainda mais dois módulos. A API é o elemento responsável pela gestão da interação entre a cena 3D e o componente da informação, pois executa a comunicação necessária de forma aos dois módulos se encontrarem em sintonia. O último componente, é aquele que tem como responsabilidade tratar o carregamento de todos os dados a apresentar, digam estes respeito aos modelos a utilizar na cena 3D ou aos detalhes a apresentar na página. 3.2 Descrição da Interface De maneira a implementar os módulos descritos na secção anterior, foi projetada uma interface capaz de encapsular os diferentes elementos necessários para satisfazer os requisitos do utilizador. Com esse intuito, o foco principal foi o componente do ambiente 3D, sendo por isso o painel de maior dimensão no ecrã e mantendo-se sempre visível. Neste painel, de forma a complementar os modelos tridimensionais, 68

83 está visível também uma pequena indicação do posicionamento atual do utilizador - o edifício, piso e sala presentemente ativos. O espaço do ecrã foi partilhado com outro painel de fácil acesso e interação, onde está disponível informação básica e curta sobre os diferentes elementos a divulgar. Fig. 2 - Interface do produto alive Places De forma a exibir dados informativos mais detalhados sobre esses mesmos elementos, foi ainda projetado um painel de detalhes, com caráter ocultável, para não tirar o foco da cena tridimensional. Para ambientar o utilizador aos controlos necessários na utilização da aplicação, foi criado um pequeno painel de instruções que surge quando o utilizador inicializa a aplicação e que poderá ser novamente consultado a qualquer momento da sessão. Na Fig. 2 pode ser vista a interface do produto alive Places que serviu de base à estruturação da interface da aplicação a construir. 4 Cena tridimensional e Gestão de espaços Após a especificação e planeamento do projeto, satisfazendo os objetivos iniciais, passou-se à sua realização, analisando de forma mais detalhada cada componente desenvolvido e quais as particularidades de cada um destes módulos. 69

84 4.1 Ambiente 3D Na implementação deste componente, foram seguidos os vários passos necessários para a construção de um ambiente tridimensional com funcionalidades básicas. Visualização de cena Numa primeira parte, foi criada uma cena composta por uma câmara em perspetiva, orientada para o centro da cena, duas luzes, uma ambiente e outra correspondente a um ponto de luz, e também um renderer, responsável pelo painel onde a cena será renderizada. Depois de preparado o ambiente, falta o essencial os objetos. Há dois modos de inserir objetos na cena: (i) construi-los programaticamente a partir de sólidos básicos que a Three.js já disponibiliza; (ii) importar modelos a partir de formatos de ficheiros populares e facilmente exportáveis por diversos softwares de modelação 3D. Neste projeto foi posta em prática a segunda abordagem de forma a corresponder às necessidades do sistema. Interação com cena Após a criação de uma cena é necessário permitir que o utilizador possa interagir com a mesma. A forma mais básica de interatividade consiste na interação com o conjunto de objetos, ou seja, ações como rodar a cena, aproximar ou afastar efeito de zoom -, ou ainda efeito de panning. Para isto foram utilizados controladores de câmara disponibilizados pela biblioteca Three.js. Um modo mais complexo de interatividade diz respeito à interação com objetos singulares que fazem parte da cena. Neste projeto pretende-se oferecer interação com diferentes pisos e diferentes salas. Para isso, todos os modelos importados têm já incorporadas estruturas referidas como picking boxes. Estas estruturas consistem numa espécie de caixas que circundam todas as salas e pisos com os quais deverá ser possível interagir. De forma a calcular os objetos intersetados no ambiente 3D a partir das posições bidimensionais do cursor do rato no ecrã, foi utilizado o algoritmo de Ray Casting. Este algoritmo consiste no uso de testes de interseção entre raios e superfícies que permitem resolver uma variedade de problemas em computação gráfica. 4.2 Módulo de Informação de Espaços O segundo componente desta aplicação que complementa a experiência do ambiente 3D é a página Web envolvente. Todo este componente é alimentado a nível de dados pelo back-office. Quanto à sua visualização, esta foi criada tendo em atenção a consistência da página a partir de pontos de acesso diferentes, nomeadamente browsers e sistemas operativos. Em relação à informação a disponibilizar, os dados lidos pela aplicação estão no formato JSON. O ficheiro transmitido contém todas as informações relevantes à apresentação de conteúdos ao utilizador. Para o desenvolvimento dos conteúdos informativos e com o intuito de uniformizar e acelerar o desenvolvimento para a web, assim como assegurar a sua consistência em 70

85 diferentes browsers, foram utilizadas frameworks auxiliares tais como Bootstrap, AngularJS e jquery. 4.3 API Por forma a realizar a interligação entre o módulo da cena 3D e o módulo da página e conteúdos informativos, foi necessária a criação de uma nova classe responsável pela gestão de todas as ações e comportamentos consequentes. O que se encontrava inicialmente planeado seria a utilização da API do produto alive Places, seguindo a mesma lógica funcional e adaptando apenas algumas características conforme o necessário. No entanto, após alguma análise e estudo da mesma, verificou-se que esta possuía elos e ligações em excesso para o que seria necessário no caso do presente projeto, e que a quantidade de alterações a efetuar para adaptar a API a este sistema ia ser significativa. Em consequência disso justificou-se a criação de uma API própria para esta aplicação, mais limpa e apropriada às características do desenvolvimento. Deste modo foi construída a classe Behaviours, e o método handler. Este método funciona como o intermediário entre todas as ações e suas reações. Todos os eventos acionados, sejam estes resultantes da interação do utilizador com a aplicação ou do próprio sistema, chamam esta função para que sejam desencadeadas as consequentes reações desse acontecimento. 5 Protótipo: Gestão de Eventos Este módulo surge com o intuito de fazer chegar o presente projeto a um outro nível, de forma a colmatar a lacuna existente em espaços dedicados à promoção de acontecimentos, sejam estes de caráter cultural, académico ou profissional - a sua divulgação e comunicação de eventos e atividades ao público. 5.1 Estruturação Em relação ao modelo de dados a utilizar, depois de estudadas as necessidades dos potenciais clientes na área dos eventos, foi representada a estrutura de base de dados a implementar de forma complementar à já existente no back-office. Foi então criada uma tabela evento, que irá conter os dados mais gerais de um acontecimento, associada a um projeto. Cada evento é constituído por atividades, apesar destas não necessitarem de um evento para existir, que estão associadas a um espaço e possuem um campo que diz respeito ao seu tipo (Workshop, palestra, cinema, musical, etc). Além disto temos ainda outra componente, os percursos, estes consistem num conjunto ordenado de espaços, e estão diretamente associados aos espaços correspondentes à origem e destino. Foi também analisada a melhor abordagem a tomar na implementação visual dos elementos informativos dos eventos de forma a estes entrarem em conformidade com 71

86 a restante interface visual do módulo de informação de espaços e de toda a cena 3D. A interface projetada encontra-se na Fig. 3. Fig. 3 - Mockup da interface do módulo de gestão de eventos 5.2 Implementação Após a estruturação do módulo, criou-se um separador que irá substituir no painel direito a listagem das imagens dos espaços por conteúdo informativo relativo a eventos. Para apresentar os detalhes da atividade selecionada faz-se uso do painel inferior deslizante mantendo de igual forma a consistência com o módulo anterior. Neste contexto, o painel lateral, à direita na Fig. 3, será composto por um calendário, que permite a navegação por eventos e atividades de forma temporal, e por uma listagem dinâmica composta, conforme a ação realizada, por eventos ou atividades relacionadas com o espaço ou a data selecionada. 5.3 Percursos O componente de percursos prende-se com a visualização de um trajeto composto por um número variável de espaços que fazem a ligação entre um local de origem e outro de destino. A implementação desta funcionalidade foi decidida com o intuito de apresentar ao utilizador informação relativa a como se dirigir duma sala onde o utilizador frequentará alguma atividade até qualquer outro ponto-chave, seja este um ponto de refeição, de saída ou mesmo a sala de uma outra atividade. Desta forma, a partir do back-office poderão ser criados, pelo cliente, diferentes tipos de percursos selecionando de forma manual os espaços que o constituem. O utilizador poderá visualizar uma rota selecionando uma opção duma combobox existente no elemento da atividade listado. 72

87 Fig. 4 - Interface final com um percurso selecionado Após a seleção de um percurso, este ficará visível na cena 3D de forma a oferecer ao utilizador uma descrição visual e realista do caminho a percorrer para ir do ponto de origem ao ponto de destino. Para distinguir as salas de origem e destino foram também colocados billboards, isto é, simples imagens indicativas centradas acima do espaço a que se referem, e que se encontram sempre voltadas para a câmara. A implementação destes billboards é realizada através da criação de um plano que tem como textura a imagem desejada e posteriormente, no ciclo de renderização, utilizar a função lookat para manter o billboard voltado para o utilizador. Fig. 5 - Máquina de estados da animação do percurso Além da visualização do percurso de forma estática, outra funcionalidade disponível ao utilizador é a de ver a animação do mesmo. Quando o utilizador pressiona o botão com este objetivo, ser-lhe-á visível uma animação que percorre ordenadamente os espaços do trajeto selecionado. Para criar a animação foi desenvolvida uma implementação por estados. Quando o utilizador pressiona o botão de ver percurso é chamado o método startpathanimation. Esta função irá ser chamada repetidamente com um conjunto de parâmetros até ser atingido o estado final. 73

88 6 Análise de Resultados Além de testes de compatibilidade em diferentes sistemas operativos e browsers e de forma a avaliar a qualidade do sistema construído, foram realizados testes a 11 pessoas analisando a usabilidade da aplicação. Dado que durante a fase de desenvolvimento do sistema foram utilizados métodos e bibliotecas direcionadas para a construção de páginas web consistentes na diversidade de browsers e resoluções, o processo de teste da aplicação em diversos sistemas operativos e browsers não levantou problemas. Dessa forma a aplicação foi testada e encontra-se funcional nas últimas versões dos sistemas operativos Windows, Mac OS e Ubuntu e também nas versões mais recentes dos browsers mais populares. Os requisitos mínimos quanto à versão do browser são apresentados na Tabela 2. Browsers Versão mínima requerida Tabela 2 - Requisitos mínimos de versão de browser Firefox Chrome/ Chromium Safari Opera Internet Explorer 11.0* (Anunciado) Para a realização dos testes de usabilidade foi seguida a metodologia Field Observation. Esta consiste numa avaliação experimental que observa o utilizador a interagir com o sistema, num contexto natural. Foi pedido que realizassem um conjunto de tarefas e que testassem a simplicidade com que as conseguiam efetuar. Enquanto isso, todas as suas ações foram registadas para posterior análise tendo como métricas de avaliação o tempo médio de realização da tarefa, o número de cliques até ser atingido o objetivo e ainda o número de erros (sendo um erro um desvio de 5 cliques do passo ideal). Após a avaliação experimental da usabilidade, foi também pedido aos utilizadores que respondessem a um questionário que abordava nas suas perguntas duas componentes: a aquisição de informação sobre o espaço apresentado durante a realização das tarefas, e a opinião pessoal dos utilizadores quanto à simplicidade de uso, qualidade da experiência e utilidade do sistema. Após a análise dos resultados obtidos pode-se concluir que os utilizadores apreciaram, de forma geral, a experiência de utilização, e foram também capazes de realizar a maioria das tarefas sem necessidade de ajuda. Verificam-se ainda algumas falhas, nomeadamente na distinção dos conceitos de atividade e evento, nos botões dos separadores de módulos e possivelmente na falta de auxiliares de interação. No entanto, todos estes problemas não pareceram ser potencialmente críticos da perspetiva do utilizador do sistema. Quanto a dois pontos cruciais - a utilidade e o grau de inovação duma aplicação deste caráter - a opinião revelada nos questionários foi consensual, tendo os utilizadores concordado que ambas são de grande valor. 7 Conclusões Da investigação inicialmente realizada, foi concluído que a utilização de ambientes virtuais tem verificado um crescimento em áreas pouco habituais até ao momento, 74

89 seja no âmbito da segurança, comércio, saúde ou mesmo simulação de desastres. No presente projeto, foi criada uma aplicação que visa alcançar o utilizador não especializado para a divulgação de espaços e eventos. Com este sistema pretende-se oferecer ao utilizador uma experiência que seja interessante e apelativa, mas que tenha toda uma outra componente focada na utilidade, nomeadamente na divulgação de informação. O módulo 3D permite ao utilizador uma experiência interativa, enquanto os módulos informativos complementares oferecem um conjunto de informação conexa. É a junção destas duas vertentes que faz desta aplicação algo inovador e com valor para os diferentes utilizadores, tanto aquele que divulga o seu espaço, como o utilizador final que faz uso dessa divulgação. O último ingrediente que pode fazer desta solução uma ideia de sucesso relaciona-se com o alcance do grande público, e isso consegue-se com a simplicidade de acesso à aplicação, a sua disponibilização de forma direta no browser e a sua compatibilidade com diversas plataformas. 8 Agradecimentos Este trabalho é financiado por Fundos FEDER através do Programa Operacional Fatores de Competitividade COMPETE e por Fundos Nacionais através da FCT Fundação para a Ciência e a Tecnologia no âmbito do projeto ERAS - ExpeditiousReconstruction of Virtual Cultural Heritage Sites (PTDC/EIA- EIA/114868/2009). Referências 1. Grupp, J.: WebGL and other Technologies for hardware accelerated 3D in Browsers. (2012). 2. Ortiz, S.: Is 3d finally ready for the web? Computer. 43, (2010). 3. Chittaro, L., Gatla, V.K., Venkataraman, S.: The Interactive 3D BreakAway Map: a navigation and examination aid for multi-floor 3D worlds. International Conference on Cyberworlds, pp (2005). 4. Oulasvirta, A., Nurminen, A., Nivala, A., Oulasvirta, A., Nurminen, A., Nivala, A., Oulasvirta, A., Nurminen, A., Nivala, A.: Interacting with 3d and 2d Mobile Maps: An Exploratory Study. (2007). 5. Ping, S., Aiguo, Z., Tao, Y.: Study and Practice of Virtual Campus Modeling and Touring International Conference on Multimedia Technology (ICMT). pp. 1 3 (2010). 6. Oudatzi, K.: Virtual reality in restoration of historic buildings: 3d model projection of the restoration project of Alaca Imaret Câmi with intuitive and interactive application through hyper realism technology th International Conference on Virtual Systems and Multimedia (VSMM). pp (2010). 75

90 Interactive visualization of 3D models in WebGL Ricardo J. J. R. Pesqueira 1 and Frutuoso G. M. Silva 2 Instituto de Telecomunicações Universidade da Beira Interior, Covilhã, Portugal 1 2 Abstract. 3D environments are widely used to simulate scenarios for many reasons. They allow simulations of scenarios, quickly and easily, therefore they are a great simulation tool. The use of 3D graphics in web browsers it is not new. But nowadays, with the appearance of the WebGL technology allows 3D graphics in the browser without plugins, it became easier to develop graphical applications for the Web. Besides, these web applications can have performances similar to desktop applications. Thus we can watch the emergence of many 3D applications for the web. In this paper we present a web tool for interactive visualization of 3D models in the OBJ format. This tool was created with Three.js framework and allows load up models from files, interaction with lights and navigation in the scenario. 1 Introduction The use of 3D graphics in web started with the VRML in 1994 and VRML97 in However, this format was not adopted massively as a solution for 3D graphics on web, mainly due to the limitations of bandwidth of Internet. Nevertheless, in 2000 a new version of VRML appears with the name of X3D for 3D graphics on web. But, once again, it was not the solution that would satisfy the market. Only in 2011 appeared the WebGL technology that allowed 3D graphics in browser with a performance similar to desktop computers, because it take advantage of graphics hardware, i.e. it runs on the graphics cards. WebGL is OpenGL ES for Javascript, which combined with canvas element of HTML5 allows the creation of 3D graphics in a web page. Thus, WebGL is cross platform for 3D graphics because it is a subset of OpenGL for mobile devices (i.e. OpenGL ES). Note that it runs on browsers like chrome, safari, firefox, opera but not in IE from Microsoft. WebGL runs on the graphics cards, which allows to execute some operation from graphics pipeline in the GPU, as, for example, the vertex and fragment operations. These operations are designated by shaders that the user can program. So, shaders are programs that run on GPU. In short, WebGL is simple OpenGL that is rendered directly in the browser. It uses the graphics card and is, therefore, very performant. However, the code can be complex and IE does not support WebGL at all. In this paper we describe a interactive visualization tool of OBJ models, which was created in WebGL to run on browsers. This tool allows to load OBJ 76

91 models with textures, manipulate it, adjust the lights and navigate in the scenario. Our goal was to create a free tool that allowed the manipulation of 3D textured models in a web browser. Besides, we wanted to evaluate the capacities and performance of the graphics in WebGL, i.e. the ease of development, efficiency and performance. This paper is structured as follows: one introduction in this first section. Section 2 presents an overview of the WebGL and its frameworks and libraries. Section 3 describes the interactive visualization tool created. Lastly, section 4 presents some conclusions and future work. 2 WebGL The recent trend in graphics hardware has been to replace fixed functionality with programmability in several areas, such as vertices and fragments processing. WebGL [5] is a web standard for a low-level 3D graphics API based on OpenGL ES 2.0 [6] and is a cross-platform. WebGL is exposed through the HTML5 [9] Canvas element as Document Object Model interfaces. It is a shaderbased API using OpenGL Shading Language (GLSL) [10] implemented into the browser through JavaScript, which means that it does not require any plugin. Figure 1 shows the OpenGL ES 2.0 pipeline where we can see the programmable areas, i.e., the vertex and fragment shaders. Shaders are programs written in GLSL that run on GPU allowing better performances of the graphics applications. Shaders are used to do shading or to produce special effects. Fig. 1. OpenGL ES 2.0 pipeline (from [6]). 77

92 WebGL does not offer the use of the fixed pipeline. What it does offer is the programmable pipeline, which is more powerful but also more difficult to use and understand. Thus the programmer has the responsibility to create the vertex and fragment shaders to render a scene. Vertex shader is a program that run on GPU that operates on incoming vertex values and their associated data. The vertex shader usually performs traditional graphics operations such as the following: Vertex transformation Normal transformation and normalization Texture coordinate generation Texture coordinate transformation Lighting Color material application The vertex shader must write the special variable gl Position in order to provide necessary information to the fixed functionality stages between vertex processing and fragment processing [11]. Fragment shader is a program that run on GPU that operates on fragment values and their associated data. The fragment shader usually performs traditional graphics operations such as the following: Operations on interpolated values Texture access Texture application Fog Color sum A fragment shader normally writes into one or both of the special variables gl FragColor or gl FragDepth [11]. In short, the vertex shader is executed once for every vertex and the fragment shader is executed once for every fragment (i.e., every pixel) that is produced by rasterization. But to understand how shaders work we need to know how manage input and output of the shaders. For that, GLSL language provides the type qualifiers. The type qualifiers can be attribute, uniform, and varying: Variables of type attribute allow the communication of frequently changing values from the application to the vertex shader. Variables of type varying are the output from a vertex shader and the input to a fragment shader. Variables of type uniform allow the application to provide relatively infrequently changing values to both vertex shaders and fragment shaders. 78

93 2.1 Frameworks As OpenGL also WebGL is a low-level library that allows accessing to the graphic hardware. Thus, some frameworks have appeared to facilitate the development of applications in WebGL. These frameworks have the advantage of masking the lower levels of the WebGL API, making it easier for the programmer. Following are listed some of the most used frameworks for the development of applications in WebGL. C3DL is a JavaScript library that will make it easier to write 3D applications using WebGL. It provides a set of math, scene, and 3D object classes that makes WebGL more accessible for developers that want to develop 3D content in browser but do not want to have to deal in depth with the 3D math needed to make it work [13]. CopperLicht is a WebGL library and JavaScript 3D engine for creating games and 3D applications in the web browsers. CopperLicht comes with a full 3D editor and supports all necessary features to create full 3D games in the browser [14]. GLGE is a javascript library intended to ease the use of WebGL. The aim of GLGE is to mask the involved nature of WebGL from the web developer, who can then spend his/her time creating richer content for the web. It supports a large number of features as keyframes and skeletal animations, collada format support, etc. [15]. GammaJS is a new Javascript library which can be used to create 2.5D platform games for a web browser using the power of HTML, JavaScript, CSS and WebGL [16]. O3D was created by Google originally built as a browser plug-in. But now, O3D is a JavaScript library implemented on top of WebGL. It is an opensource JavaScript API for creating rich and interactive 3D applications in the browser [17]. PhiloGL is a WebGL framework for data visualization, creative coding and game development [18]. SpiderGL is a JavaScript 3D graphics library which relies on WebGL for realtime rendering. The philosophy behind SpiderGL is to provide typical structures and algorithms for realtime rendering to developers of 3D graphics web application [19]. Three.js is a lightweight 3D engine with a low level of complexity. The engine can render using < canvas >, < svg > and WebGL [20]. For more information about other frameworks and tools see [12]. 79

94 3 VisObj - Visualization of 3D models To choose a framework to develop our project we decide to test a few frameworks, namely Three.js, CopperLicht and GLGE, that were the most used, powerful and with good support for illumination. Besides, these frameworks are more general, allowing the development of all kind of graphical application for web. Thus we created a 3D scenario to test with all the three frameworks, as shows Figure 2. a) Scenario 3D created for tests. b) Scenario in CopperLicht. c) Scenario in GLGE. d) Scenario in Three.js. Fig. 2. Tests in different WebGL frameworks. Based on the tests realized with several WebGL frameworks and according to the strengths and weaknesses of each framework, we decided to choose the Three.js for our project. First, the Copperlicht was eliminated because it requires the use of CopperCube for the creation of 3D scenarios. However, the Copper- Cube requires a license and our goal is to develop a free tool. Then, between the Three.js and the GLGE we choose the Three.js because it allows a greater parametrization of the illumination methods and also because it supports more file formats for 3D models. For example, the GLGE only supports collada files. The project consists in a indoor scenario where the user can navigate, load 3D models and interact with models and lights. Initially when our prototype 80

95 starts, it displays the instructions to navigate in the scenario. Thus, the cursor keys are used to control the camera orientation and the other keyboard keys (i.e., Q,W,E,A,S,D) are used to walk in the scenario. a) Chair without texture; b) Chair with a texture; c) Chair with a texture; d) Chair viewed in a different position; e) Plane with a different orientation; f) Plane viewed from other position; Fig. 3. Example of the view of two models with different textures and light intensity. 81

96 The user can load 3D models in Wavefront OBJ format [8] and then he/she can apply the texture to model by selecting a texture file, as shown in the menu in Figure 3 c). It was chosen the OBJ format because it is one of the most used. In Figure 3 a) we can see the chair model without texture and in the Figures 3 b), c) and d) with texture. Figures 3 e) and f) show a plane model with two different textures and observed from different positions with different light conditions. Figure 3 b) shows the chair model inside a translucent cube. This cube identifies the area where the models will appear after the user loads it. Thus, all the models are adjusted to fit well inside this cube. However, the user can also adjusts the dimension of the models and apply geometric transformations (e.g., scale, rotations and translations). Note that the user can make this cube visible or not by selecting the menu option Hide Glass Cube. The light conditions can also be adjusted by the user. For that, the user must first select the light to interact and then a menu will be available to adjust the light intensity and color. Our prototype is available on the Internet to be tested in a browser that supports WebGL (see it at interactive.html). 4 Conclusions and future work WebGL allows 3D graphics in browser without plugins and with high performance. Therefore, we have witnessed the emergence of several frameworks to facilitate the development of graphical applications for the web. Three.js is one of these frameworks that we used to develop our prototype due to its potentialities and also because it is free of charge. In terms of the ease of development and efficiency the Three.js proved to be a good framework. Also the performance of the Three.js was very good, as proves our prototype. Our prototype allows the visualization of models in OBJ format and applies them a texture, as well as it allows the navigation in the scenario and the manipulation of the models and lights. The prototype is also available on the Internet to be tested and used by any user. Note that the possibility to load different textures for a 3D model was a option singular in our prototype. It enables the user to test several materials for the same object, which can be an advantage for several areas (e.g., for a designer, architect, engineer, etc.). In the future we want to extend the prototype to allow the load of several models in the scenario and interact with them. Also, it would be interesting to have an outdoor scenario available to load and manipulate other type of models. Acknowledgements The support given by IT - Instituto de Telecomunicações in the scope of the PEst-OE/EEI/LA0008/2013 project. 82

97 References 1. Behr, J., Eschler, P., Jung, Y., and Zöllner, M. X3DOM : a DOM-based HTML5/X3D integration model. In Proceedings of the 14th International Conference on 3D Web Technology : 3D technologies for the World Wide Web. Darmstadt, Germany: ACM, , (2009) 2. Benedetto, Marco Di, Corsini, Massimiliano, and Scopigno, Roberto. SpiderGL: a Graphics Library for 3D Web Applications. In Proceedings of 3D-ARCH 2011, (2011) 3. Milivojević, Miroslav and Antolović, Igor and Rancić, Dejan. Evaluation and visualization of 3D models using COLLADA parser and WebGL technology. Proceedings of the 2011 international conference on Computers and computing (ICCC 11), , (2011) 4. Brunt, Paul. GLGE: WebGL for the lazy, KHRONOS-WEBGL, WebGL - OpenGL ES 2.0 for the Web, KHRONOS-OPENGLES, OpenGL ES 2 X - The Standard for Embedded Accelerated 3D Graphics, X/ 7. Peter Paulis, Ján Lacko. 3D Webpages, Studentská vedecká konferencia FMFI UK, Bratislava, pp , (2010) 8. Obj Specification. Retrieved Aug. 2012, from 9. W3C - HTML5, KHRONOS-GLSL, OpenGL Shading Language, Rost, Randi J. OpenGL Shading Language, Second Edition, Addison Wesley, KHRONOS-WEBGL, User Contributions, Contributions 13. C3DL. Retrieved May 2013, from 14. CopperLicht. Retrieved May 2013, from index.html 15. GLGE. Retrieved May 2013, from 16. GammaJS. Retrieved May 2013, from 17. O3D. Retrieved May 2013, from 18. PhiloGL. Retrieved May 2013, from 19. SpiderGL. Retrieved May 2013, from 20. Three.js. Retrieved May 2013, from https://github.com/mrdoob/three.js 83

98 Computação Móvel e Ubíqua 84

99 Planeador colaborativo de deslocações de bicicleta em meio urbano Nelson Nunes 1, João Barreto 2 1 Instituto Superior Técnico - Universidade Técnica de Lisboa / INESC-ID, 2 Instituto Superior Técnico - Universidade Técnica de Lisboa / INESC-ID, Resumo Nos últimos anos, os utilizadores de bicicleta têm vindo a usar cada vez mais serviços de pesquisa de trajectos na web. Este documento foca-se num serviço de pesquisa de trajectos para bicicleta que pode ser adaptado a qualquer cidade, mesmo onde não exista informação detalhada, precisa e actualizada sobre os atributos da rede viária que são relevantes para a pesquisa de trajectos seguros, competitivos e confortáveis para bicicleta (declive, intensidade e velocidade de tráfego, largura de vias, qualidade de piso, etc.). O nosso sistema envolve e tira partido dos esforços da comunidade de utilizadores de bicicleta de cada cidade. Por essa razão, a nossa solução não precisa de uma entidade central responsável pela introdução e manutenção dos atributos da rede viária. 1 Introdução Nas principais cidades da Europa, as bicicletas já conquistaram o seu espaço e têm sido utilizadas, para pequenas distâncias, como meio de transporte alternativo ao automóvel [1]. O meio de transporte bicicleta tem benefícios ambientais e energéticos. Melhora a qualidade do ambiente urbano, tendo impacto no bem-estar físico, social e mental dos cidadãos [2]. A bicicleta constitui o meio de deslocação mais rápido e eficiente dentro das áreas urbanas, especialmente para distâncias inferiores a 5km [3]. Tendo presente todos os benefícios referidos anteriormente, torna-se necessário estimular a utilização da bicicleta como meio de transporte no nosso país [4]. Em cidades portuguesas como Lisboa, Porto, etc., que apresentam um baixo número de utilizadores de bicicleta e que ainda fornecem uma infraestrutura escassa para este meio de transporte, a escolha de trajectos seguros e confortáveis é um factor crucial. Nessas cidades, a escolha destes trajectos para uma pessoa se deslocar é normalmente uma habilidade acessível apenas aos utilizadores de bicicleta mais experientes da cidade. This work was supported by national funds through FCT Fundação para a Ciência e a Tecnologia, under projects PEst-OE/EEI/LA0021/2013 and PTDC/EIA- EIA/122785/

100 Os melhores trajectos são aqueles que têm em conta todos os factores relevantes na deslocação de um utilizador de bicicleta. Factores como distância percorrida, inclinação e segurança são os mais relevantes para a pesquisa de um bom trajecto [5]. Enquanto que o factor distância apenas tem em consideração a distância, permitindo obter o trajecto mais curto, o factor inclinação permite evitar subidas inclinadas, devolvendo se possível um trajecto mais plano. O último factor tem como objectivo devolver um trajecto mais seguro e confortável. Este é um trajecto que tem em conta o tipo de pavimento, tenta abranger pistas exclusivas a bicicletas e ruas com tráfego motorizado pouco intenso e calmo. Hoje em dia, nota-se cada vez mais a expansão de serviços de pesquisa de trajectos para a bicicleta em ambiente web. Entre os exemplos mais populares que permitem pesquisa de trajectos para bicicleta encontram-se: Google Maps 3 (disponível nos Estados Unidos, Reino Unido e recentemente na França, Alemanha, Polónia, Irlanda e Luxemburgo), Ride The City 4 (algumas cidades dos Estados Unidos, Espanha e França), e BikeHub 5 (Reino Unido), entre outros. Já existem algoritmos eficientes e escaláveis de pesquisa de trajectos para bicicleta, bases de dados geográficos, arquitecturas e interfaces web bem definidas e já são utilizados serviços de pesquisa de trajectos, incluindo serviços multimodais e serviços de código aberto, com grande sucesso em algumas cidades do mundo [6,7,8,9,10]. O que impede então que esses serviços sejam replicados noutras cidades? A falta de informação detalhada (declive, intensidade e velocidade de tráfego, largura de vias, qualidade de piso, etc.) sobre a rede viária dessas cidades contribui largamente para a não existência desses serviços em muitas cidades. Para além disso, verifica-se a ausência de entidades disponíveis para manter essa informação actualizada ao longo do tempo. Por exemplo, o Goolge Maps já suporta pesquisa de trajectos para utilizadores da bicicleta para várias cidades dos Estados Unidos e Grã-Bretanha. Contudo, a cobertura de novas cidades tem sido lenta porque, para a maior parte das cidades, a informação disponível é insuficiente. A nossa contribuição é um sistema em que os dois desafios acima são ultrapassados envolvendo os próprios utilizadores de bicicleta, num esforço colaborativo de classificação de trajectos e troços da cidade. Com o nosso sistema, à medida que os utilizadores pedalam, classificam os troços dos trajectos de forma colaborativa, usando clientes móveis como Smartphones ou PDAs. Desta forma, o conhecimento da informação sobre a rede viária é cada vez maior para que o sistema possa devolver melhores trajectos aos seus utilizadores. Os principais desafios do nosso sistema são: 1. Como facilitar a introdução das classificações? 2. Como motivar os utilizadores a colaborar activamente? 3. Como filtrar a informação incorrecta? O nosso protótipo consiste numa aplicação cliente que corre na web e num servidor que permite o planeamento e classificação de trajectos. Os resultados 3 https://google.com/maps

101 indicam que este sistema pode ser bastante útil para os utilizadores partilharem as suas experiências de forma a que seja sugerido melhores trajectos aos utilizadores menos experientes no uso deste meio de transporte. 2 Trabalho Relacionado 2.1 Sistemas de pesquisa de trajectos Ride The City. Este sistema disponibiliza três opções (seguro, mais seguro e directo) para o utilizador pesquisar por um trajecto. O sistema atribui uma distância menor a ruas com pistas exclusivas para ciclistas, ruas que por isso são consideradas mais seguras. Ou seja, quando o utilizador selecciona o critério seguro ou mais seguro, o que o sistema faz na realidade é multiplicar a distância das ruas por um factor entre 0 e 1 de modo a devolver um trajecto seguro que possa incluir pistas para ciclistas. O factor multiplicativo usado no critério mais seguro é menor que o factor usado no critério seguro. Neste sistema é possível classificar os troços, escolhendo uma categoria numa escala de respostas (excelente, bom, etc.). Contudo, na versão actual, as classificações só servem como notificações para que a equipa que mantém o serviço corrija manualmente os atributos do mapa. Este sistema só funciona em cidades nas quais há uma equipa que mantém a informação (de declive, segurança, conforto etc.) da rede viária. Essa informação não pode ser corrigida directamente pelos utilizadores de bicicleta OpenTripPlanner. O OpenTripPlanner 6 é um planeador multimodal de itinerários de código aberto e tem como fonte de dados geográficos o OpenStreetMap. Há inúmeros serviços de pesquisa de trajectos na web suportados pelo OpenTripPlanner. Por exemplo, a TriMet, agência de transportes públicos do estado Oregon dos Estados Unidos, disponibiliza um planeador 7 baseado no OTP. Grande parte do OTP foi desenhada para permitir o planeamento de trajectos que possam ser percorridos pelos utilizadores da bicicleta. Este sistema permite aos utilizadores uma forma de planear as suas deslocações, com base em três parâmetros: distância, tipo de ruas/segurança e a sua inclinação. A qualidade do trajecto devolvido depende da existência dessa informação. 2.2 Sistemas de pesquisa de trajectos com feedback dos utilizadores OurWay. O OurWay é um sistema colaborativo de planeamento de trajectos que usa feedback dos utilizadores para devolver trajectos que se adaptam aos seus interesses [11]. Este projecto é usado dentro de um edifício e suporta navegação para utilizadores em cadeiras de rodas

102 Os utilizadores classificam os segmentos do trajecto relativamente à sua acessibilidade (categorias: bom, não confortável ou inacessível). Baseado na agregação das classificações dos utilizadores, o servidor calcula o melhor trajecto entre duas localizações. Os autores concluem que um sistema colaborativo de planeamento de trajectos é viável e pode funcionar bem Cyclopath. O Cyclopath 8 é uma wiki geográfica usada para pesquisar trajectos de bicicleta numa área denominada Twin Cities no estado de Minnesota dos Estados Unidos [12]. Neste sistema, as classificações inseridas por um utilizador não são usadas na pesquisa de trajectos por outros utilizadores. Como um utilizador expressa as suas preferências para uma pequena parte da rede é necessário algoritmos de Supervised Learning para inferir as suas preferências para os outros arcos na rede. Os utilizadores classificam cada arco com um atributo denominado bikeability numa escala de 0 (intransitável) a 4 (excelente). Este sistema não resolve o problema descrito neste artigo pois as contribuições dos utilizadores não são partilhadas com o resto da comunidade. O objectivo deste sistema é devolver um trajecto consoante o perfil do utilizador que solicita a sua pesquisa. É de referir que o conceito bikeability é vago, não sendo consensual entre os utilizadores de bicicleta. Os autores indicam que apenas em 53% dos casos, os utilizadores classificaram um troço com o mesmo valor de bikeability. 3 Arquitectura O sistema foi implementado com recurso a um sistema de pesquisa de trajectos de código aberto, o OpenTripPlanner. Foi necessário alterar a Rest API deste sistema para devolver os troços individuais de um trajecto de modo a estes serem identificados do lado da interface para poderem ser classificados. Foi também necessário incorpar as classificações dadas pelos utilizadores no algoritmo de pesquisa do trajecto mais curto. 3.1 OpenTripPlanner Para calcular o caminho mais curto é utilizada a seguinte fórmula que determina o peso de um arco (troço) com base nos seus atributos estáticos: P (arco) = (d D) + (d factorinclinacao I) + (d factorseguranca S) O parâmetro d é o comprimento do arco, D, I e S são os pesos especificados pelos utilizadores aos critérios distância, inclinação e segurança respectivamente. O factorinclinacao é determinado pelo OpenTripPlanner e depende dos dados de 8 88

103 elevação. Por outro lado, o OTP estima um valor para o factorseguranca através das etiquetas presentes no OpenStreetMap. Para o sistema suportar o planeamento de trajectos precisa de construir o objecto grafo que é guardado em disco e depois usado durante a pesquisa de um trajecto. Este objecto pode ser construído a partir de dados do OpenStreetMap, dados de elevação e dados dos transportes públicos no formato GTFS OpenTripPlanner com as classificações dos utilizadores Uma vez que o OpenTripPlanner não tem conhecimento dos dados de elevação, sem as classificações dos utilizadores, este critério não é utilizado. Relativamente ao factorseguranca, este é atribuído de acordo com as etiquetas presentes no OpenStreetMap. Contudo, este factor pode ser muito mais preciso, se tiver em conta a velocidade e intensidade do trânsito. Com a colaboração dos utilizadores o sistema pode ter esta informação em conta na pesquisa de trajectos. O nosso protótipo já permite que os utilizadores da bicicleta pesquisem por um trajecto na cidade de Lisboa e classifiquem os troços (arcos) de um trajecto. Escolhemos uma granularidade fina para as classificações, permitindo um valor numa escala de 1 a 5. Estes valores são escolhidos pelo utilizador com a ajuda da interface ilustrada na Fig. 1 e são guardados numa base de dados. Figura 1 - Interface para o utilizador classificar os troços do trajecto devolvido. A cada valor está associado um factor que é depois usado na fórmula que apresentámos anteriormente para cálculo do peso dos arcos. Na presente implementação, quando há mais que uma classificação para um troço, o sistema calcula uma média ponderada das classificações em que o peso de cada classificação depende da data da mesma. As classificações mais recentes têm por isso maior importância para o cálculo da média. O protótipo consiste numa aplicação cliente que corre por exemplo, num navegador de um Smartphone e num servidor que além de oferecer o serviço de 9 https://developers.google.com/transit/gtfs 89

104 pesquisa de trajectos, permite também ao utilizador classificar os troços de um trajecto. A arquitectura do sistema está representada na Fig. 2. O utilizador acede ao sistema através de um website onde pode visualizar o mapa da sua cidade. De seguida, introduz os parâmetros para a pesquisa de um determinado trajecto e o servidor devolve o trajecto que posteriormente é desenhado no mapa. O módulo denominado Gestor do grafo é responsável por construir o objecto grafo que depois é explorado quando o utilizador planeia um trajecto. Os recursos usados para criar o grafo são os dados do OpenStreetMap da cidade em causa e a nossa base de dados, que guarda as classificações introduzidas pelos utilizadores. Este grafo tem de ser criado e guardado em disco previamente, para depois ser usado pelo módulo denominado Planeador, que é invocado quando o utilizador envia um pedido HTTP ao servidor, ou seja, quando solicita uma pesquisa por um trajecto. Neste momento, o módulo planeador usa o algoritmo A* para encontrar o caminho mais curto entre dois nós na rede. Este algoritmo percorre os arcos que são encapsulados previamente no objecto Java guardado em disco que representa o grafo. Figura 2 - Arquitectura do sistema. 3.3 Gestão de incentivos Sem utilizadores a submeterem feedback nos troços dos trajectos, o nosso sistema não cresce e acaba por devolver trajectos inadequados aos seus utilizadores. Por isso, a nossa solução inclui um mecanismo de incentivos que tenta estimular a colaboração do maior número possível de utilizadores. Este mecanismo premeia os utilizadores que submetem mais informação correcta e que reagem mais cedo a alterações que aconteçam nos troços. Por outro lado, despromove utilizadores menos participativos, normalmente designados por free riders, e utilizadores que submetem informação de forma incorrecta. No caso do nosso sistema, um free rider é aquele que usa o sistema para planear os seus trajectos, mas que não contribui para o crescimento do sistema. O mecanismo de incentivos é baseado num sistema de pontuações, em que cada utilizador ocupa uma posição na tabela de acordo com a sua pontuação. Estas pontuações podem ser traduzidas em prémios aos melhores classificados, prémios esses que podem ser oferecidos por patrocinadores interessados (lojas, fabricantes, autarquias, etc.). 90

105 O principal desafio deste mecanismo é converter as contribuições dadas por um utilizador numa pontuação que reflicta a qualidade e utilidade das classificações de cada utilizador. É necessário fazer uma distinção entre classificações úteis e precisas. As classificações precisas reflectem as verdadeiras características do troço, de forma muito consensual entre os utilizadores de bicicleta. As classificações úteis são aquelas que reportam características em falta no sistema. Um troço que não tinha ainda uma classificação ou um troço que mudou (por exemplo, no piso ou na velocidade máxima) e ainda não havia classificações a reflectirem essa mudança são exemplos de classificações úteis. Desta forma, há classificações que são precisas, mas que acabam por não ser úteis devido ao troço já estar classificado de forma precisa e consensual por outros utilizadores, e vice-versa. Em seguida são apresentadas as regras para o cálculo das pontuações: 1. Aos primeiros utilizadores que classifiquem um troço é-lhes dado maiores pontuações do que àqueles que classificam depois. 2. Quando há muitas classificações a divergirem por mais de 2 valores de uma classificação dada por um utilizador, esse utilizador perderá automaticamente pontuação por não ter inserido a informação de forma correcta. 3. O mesmo acontece quando muitos utilizadores já classificaram um troço com um valor X e aparece uma classificação de um utilizador que diverge por mais de 2 valores de X. Esta última regra lança um desafio muito importante que faz parte do trabalho futuro. O sistema tem de ser capaz de distinguir entre classificações submetidas de forma incorrecta e classificações correctas que demonstram a mudança das características do troço. 4 Avaliação Preliminar Com a excepção do módulo de gestão de incentivos, o sistema está totalmente implementado e disponível num servidor do INESC-ID. Nesta fase, a única avaliação que foi feita foi qualitativa, para provar o conceito. Sendo o sistema já capaz de receber as classificações nos troços e de devolver trajectos com base nas classificações introduzidas pelos utilizadores, realizámos algumas experiências para avaliar de forma preliminar o nosso sistema. Na Fig. 3 apresentamos uma dessas experiências em que um utilizador pede para o sistema planear um trajecto com e sem as classificações dadas pelos utilizadores. A vermelho está representado o trajecto inicialmente devolvido pelo Open- TripPlanner. Depois do trajecto devolvido, classificámos os troços do trajecto com o valor 1 em termos de inclinação, o que significa subida íngreme. A verde está representado o trajecto devolvido depois do sistema ter tomado conhecimento das classificações introduzidas, devolvendo-nos um trajecto mais plano. 91

106 Figura 3 - Exemplo de duas pesquisas de trajecto com o nosso sistema. Este resultado preliminar indica que a ideia de ter um planeador colaborativo de trajectos é bastante promissora. 5 Conclusões Neste documento promovemos o meio de transporte bicicleta e enumerámos vários sistemas que permitem o planeamento de trajectos usando a bicicleta. Depois apresentámos o nosso protótipo que recebe as classificações dos utilizadores de forma a obter melhores trajectos. A nossa abordagem difere de outros sistemas de planeamento de trajectos porque utilizamos feedback dos utilizadores no cálculo dos trajectos. O resultado apresentado na secção Avaliação mostra que um sistema que permita aos utilizadores classificar troços pode dar resultados muito bons se o feedback for introduzido correctamente. Como trabalho futuro, planeamos implementar o mecanismo de gestão de incentivos já desenhado, de forma a estimular os utilizadores de bicicleta a interagirem com o sistema e a classificarem os troços dos trajectos. É também objectivo avaliar o sistema com uma experiência de grande escala com utilizadores reais em Lisboa. Além disso, pretendemos tirar partido do GPS e de outros sensores, como o acelerómetro, das plataformas móveis de forma a minimizar o esforço do utilizador a classificar os troços do trajecto percorrido. Referências [1] Mispelon, Chloe. ECF cycling barometer technical document [2] Rojas-Rueda, David and Nazelle, Audrey and Nieuwenhuijsen, Mark J. The health risks and benefits of cycling in urban environments compared with car use: health impact assessment study [3] European Commission. Cycling: the way ahead for towns and cities. Luxembourg: Office for Official Publications of the European Communities, [4] Instituto da Mobilidade e dos Transportes (IMT) e Gabinete de Planeamento, Inovação e Avaliação (GPIA). Plano de Promoção da Bicicleta e Outros Modos Suaves [5] Félix, Rosa M. Gestão da Mobilidade em Bicicleta. Dissertação para obtenção do Grau de Mestre em Engenharia do Território,

107 [6] E. W. Dijkstra. A note on two problems in connexion with graphs, volume 1. Numerische Mathematik (Historical Archive), Dec [7] Dechter, Rina and Pearl, Judea. Generalized best-first search strategies and the optimality of A* [8] Geisberger, Robert and Sanders, Peter and Schultes, Dominik and Delling, Daniel. Contraction Hierarchies: Faster and Simpler Hierarchical Routing in Road Networks [9] Bennett, Jonathan. OpenStreetMap - Be your own cartographer. Birmingham: Packt Publishing, [10] Luxen, Dennis and Vetter, Christian. Real-Time Routing with OpenStreetMap data [11] Holone, Harald and Misund, Gunnar and Tolsby, Hakon and Kristoffersen, Steinar. Aspects of Personal Navigation with Collaborative User Feedback [12] Priedhorsky, Reid and Pitchford, David and Sen, Shilad and Terveen, Loren. Recommending Routes in the Context of Bicycling: Algorithms, Evaluation, and the Value of Personalization

108 Application Synchronisation on Public Displays based on PubSubHubbub Manuel Pereira, Maria João Nicolau and Helena Rodrigues Centro Algoritmi, Escola de Engenharia, Universidade do Minho, Campus de Azurém, Guimarães, Portugal Abstract. Large-scale pervasive public displays networks are becoming an emerging paradigm and represent a radical transformation in the way we think about information dissemination in public spaces. One of the features of pervasive public display systems is their ability to create experiences that span across multiple displays in a coordinated fashion. Proprietary single site display solutions exist but these are not open to third-party developers. On the other hand, scalable open systems that enable large-scale, synchronised and multi-screen experiences, spanning multiple networks domains will call for the definition of multiple administrative boundaries that accommodate function partitioning. In our research, we are studying the key requirements involved in this open application synchronisation and present our initial work on designing a synchronisation model and Application Programming Interface for public displays application developers that is built on top of the PubSubHubbub protocol, an open protocol for distributed publish/subscribe communication on the Internet. Keywords: Public displays, synchronisation, publish-subscriber, PubSubHubbub 1 Introduction Open, large-scale pervasive public displays networks are becoming an emerging paradigm and represent a radical transformation in the way we think about information dissemination in public spaces. In particular, open networks of public displays create the opportunity for third parties to create and publish content in the form of applications, promoting openness as a source of value for all the parties involved [7, 14]. In the future we believe that the interconnected nature of these displays will mean that new applications for public displays will promote not only enticing situated interactions but also meaningful synchronised interactions between independent, possibly remote, public displays installations, challenging radically the current stat-of-the-art in digital signage. Application synchronisation on public displays networks has been mainly approached from the perspective of application scheduling. Storz et al [13] has 94

109 developed, as part of the e-campus project, a domain-independent API that supports the construction of domain-specific scheduling approaches. Using this approach, it is possible to support a combination of both statically scheduled content and interactive schedule content across multiple displays. A more recent approach for content scheduling in e-campus has been described in [2]. The scheduling API has been replaced by the concept of Content Descriptor Set (CDS) that describes how single items of media should be rendered at the display. The system is opened to content from numerous sources with no centralised control. Although not specifically analysed in the paper, coordination between displays seems to be supported in the definition of CDSs. Application synchronisation has also been investigated in the context of system support for smart spaces. The Event Heap is one of the main components of the iros operating system for smart spaces. Users in a meeting room interact with different visualization applications that run on displays and other situated devices, such as on laptops or PDAs, and are able to control any device or application from their current location. The Event Heap [10], a publish-subscribe system, provides for dynamic application coordination and forms the underlying communication infrastructure for applications in the interactive workspace. Our approach to application synchronisation on public display networks aims at evaluating a publish-subscriber protocol designed for the web space, the Pub- SubHubbub 1, as an architectural component of a public display network system with the objective to promote synchronised experiences across displays. In section 2 we describe the main architectural concerns that support the execution of applications on open public display networks. In section 3 we describe a synchronisation scenario in public display networks and define the initial requirements for public displays synchronisation. In section 4 we introduce the PubSubHubbub protocol, describe a PHP API for application development and briefly describe our approach through the definition of a simple application. Finally, in section 5 we present our conclusions. 2 Public Displays Applications Figure 1 presents the main functional blocks and interactions required to have a fully functional pervasive displays network. It can be instantiated in different forms and replicated as needed, depending on grow demands [5]. We will briefly describe the depicted architecture, emphasising the main architectural aspects that frame our work. The Application Developer is the main actor in the Application Domain. He is responsible for application development, application description and application registration. The application model for public displays networks is still an open issue. In this work we share the application model provided by the Instant Places, a specific display infrastructure. Instant Places aggregates place-based screen media and explores new concepts for user-generated content [11]. A display application in Instant Places is a web application whose primary goal is to 1 https://pubsubhubbub.appspot.com/ 95

110 render content on a public display [14]. Display apps are based on web technologies and standards, e.g., HTML, JavaScript and CSS. They are developed on public servers from where they can be used in any public display. Displays apps are rendered in any standard web browser or other types of specially tailored web stacks and their model is optimised for the distinctive execution context and user experience of public displays. The InstantPlaces system facilitates seamless integration of third party web applications residing anywhere in the public Internet into a display, thus catering for a scalable and open architecture. Instant Places offers a model for content presentation that takes into consideration both the display environmental data, e.g., sensors and user interactions, and app specific configuration. This approach enables the content being shown to be highly personalized, thus reflecting the dynamic and situated behavior of displays global web apps [6]. Fig. 1. Public Display Network architecture. Application registration in the Application Registry is the basis for an application distribution model. Making an analogy with the mobile phone context, Clinch et al. present a set of design considerations for public displays appli- 96

111 cations stores [3]. Application stores for public displays have the potencial to promote collaboration and synchronisation in public spaces as innovative ideas are likely to appear in open innovation environments. Additionally, sophisticated application description systems that are likely to appear, will also have the potential for promoting application sharing and synchronisation as developers and displays owners will be offered shared environments for application behaviour description. The Display owner accesses to one or more application stores, registers his display and installs applications on them. He interacts with the Orchestration Service to define how applications are rendered in the display. Application developers may also be able to define orchestration constraints and, ultimately, User may also influence display behaviour through situated interactions. Orchestration information are the basis for the Display Controllers to decide which content or application should be rendered, where in the display and when - scheduling model. Typical scheduling models for traditional public displays most commonly multiplex over a set of content items through time multiplexing, regularly changing the item visible on the display for another. Open public displays networks should accommodate new forms of highly dynamic scheduling that emerge from the dynamic nature of content itself. In particular, for the problematic of display application synchronisation, the need for dynamic scheduling may be associated with the need to react to application events running on a different display. A final issue on public display networks systems is the question of where to physically locate the application the display is executing. The potentially large-scale characteristics of public displays networks with their inherent innovative nature, characterized by a continuously changing number of users, display owners, content producers, display nodes, application items, application hosts, content types, interaction modalities, sensors and connections, may lead to several scalability and performance problems. In this context, existing scalability techniques can be applied, in particular in the web environment. This may call for application replication techniques or for dynamic VM synthesis supported by cloudlets [4]. 3 Synchronization scenario and requirements To illustrate the synchronisation aspect of public displays applications, consider the following scenario: International Action - World AIDS Day - It is the 1st of December - World AIDS Day. All around Europe there are initiatives exploring what AIDS means to different communities: including public information on how to avoid contracting AIDS; documentaries concerning the plight of many AIDS sufferers in Africa; and content from grass roots groups such as schools fund raising for AIDS charities. Citizens in Europe are united through common interactive experiences created by a team of international artists and displayed on every participating display in Europe. In this situation, displays are being used for improving communication between different communities and promoting awareness to a world-wide health 97

112 problem. Synchronisation requirements are evident as different and, preferably, independent public displays installations need to coordinate their actions. Consider for example the situation where a photo of a greeting gesture of a group of people in front of a display may immediately be spread for all participating displays. Every participating installation has previously looked up and subscribed the World AIDS Day application (or one of the World AIDS Day applications, if a few variations of the application may exist). The subscription process is out-of-scope of this document, but at the end every installation had been configured with the application URL (a public display opmtimised end-point) and a proper set of scheduling constraints would have been set by the respective installation s managers. Those would include, at the minimum, a rule for scheduling the application on the 1st of December and some indication about the eventbased nature of the application. Situated-behaviour and interaction with local resources is accomplished through the integration of the environment service provided by the display node (possibly an Instant Places node). Applications are running on public servers, possibly replicated in different servers or running on local VM supported by cloudlets [4]. Public displays networks will be sharing the most important characteristics of large-scale distributed systems: they will be decentralised in many forms, developed, owned and used by a wide variety of stakeholders with conflicting needs and expanding or evolving continuously. One of the key aspect of this situation is the autonomy between the public displays installations. Every installation is likely to be managed by independent owners and do not share any functional component of the public display network system apart from the application store and, in some cases, the public server running the web application. Although some form of a scheduler component capable of managing a set of displays installations could also fulfill the above requirements [13], we believe that such an approach would violate the autonomy of public display installations. In our research we intend to approach the problem of synchronisation in public places by offering a web based, loosely-coupled synchronisation framework for public displays applications that allows for public displays synchronisation while preserving the autonomy of display installations. In this paper, we report our initial work on exploring the PubSubHubbub, a publish-subscribe protocol for the web space. In the next section we briefly introduce the protocol and describe an API for application synchronisation on public displays. 4 Coordination within PubSubHubbub Publish-subscriber systems are known as having a particular relevance in communication models in the increasingly distributed and necessarily loosely coupled context of the modern Internet. They offer loosening coupling in space, time or synchronisation [8]. Moreover, publish-subscriber systems have been an important component in the web context, recently enforced by the increasing popularity of the Real Time Web. In particular, approaches such as PuSH 98

113 (PubSubHubbub) [9] add realtime notifications on top of RSS provide a RESTful decentralised publish-subscribe service. 4.1 PubSubHubbub PubSubHubbub is a simple, open, server-to-server web-hook-based pubsub (publish/subscribe) protocol as an extension to Atom and RSS 2. PubSubHubbub is a topic-based subscription protocol, not a service. Application developers can run a PubSubHubbub or use an open server. Google is running, in scalable clouds, an open test server for anybody to use to help bootstrap the protocol 3. The main architectural entities of the PubSubHubbub protocol are the Hub, the Publishers and the Subscribers. An Hub is the server which implements both sides of this protocol. It acts as a broker between publishers and subscribers. A feed publisher indicates in the feed document (Atom [12] or RSS [1]) its hub URL, to which a subscriber (a web server) can register the callback URL. The publisher notifies its hub whenever it generates a feed update. The hub than fetches the feed and sends it to all the registered subscribers. Subscribers provide endpoint URLs to which hubs can post updates. For a complete description of the PubSubHubbub protocol, please consult [9]. 4.2 Synchronisation PHP API We have design a basic PHP API for using the PubSubHubbub protocol. Our objective is to provide a very first application programming tool for providing synchronisation in public display networks. This will be the basis for the implementation of a few synchronisation scenarios in public displays networks. We intend to study performance issues as well as to define the requirements for a programming tool for developing synchronised applications for an open public display network. As we expect that, as display nodes, PubSuBHubbub will exhibit a federated behaviour, hud discovery and hub coordination is expected to be a crucial issue. In our API, an event represents the information that is shared between publishers and subscribers. It has a type, a description, a creation time and a list of optional parameters, specific to the application domain. The API consists of four operations: create event(), publish event(), subscribe event() and read event(). function create event($parameters) This function receives an array that contains the parameters of an event. Each parameter is described by a pair ( key, value ). This function adds a xml representation of the event to the respective application feed. It returns true or false if success or failure respectively (HTTP error code is logged for analysis). function publish event($topic urls,$hub url) This function publishes an event in the hub with address $hub url. The topic URL corresponds to the 2 https://pubsubhubbub.appspot.com/ 3 https://code.google.com/p/pubsubhubbub/ 99

114 address of the application feed. It returns true or false if success or failure respectively (HTTP error code is logged for analysis). function subscribe event($hub url,$callback url,$topic url,$lease seconds) This function subscribes an event the application is interested in receiving. $hub url defines the hub address, $callback defines the local endpoint URL that receives the hub notification when the event occurs. $topic url corresponds to the address of the feed the application intends to subscribe for notifications. $lease seconds defines the life time of the subscription (in seconds). The hub has to validate the subscriber application callback endpoint. To do that, an hub contacts the callback endpoint to test if it is alive. The application must to answer back to that contact. The API contains a class ( endpoint.php ) that offers the mechanisms to implement this handshake. function read event($parameters) This function extracts from a notification the key values that are described in $parameters. Example We are developing a simple application that shows a photo slideshow, the description of the current photo and a set of user submitted comments about the photos. Additionally, the application provides two endpoints for submitting new photos and comments. The application is associated to a set of public displays and the intended behaviour is to provide a shared photo slideshow in every place. Whenever a new photo is uploaded, the new photo is displayed in every public display. Whenever a new comment is published, the list of comments is updated in every application. Fig. 2. Application feed containing two new comment events. In our approach, different application components and/or different application components instances correspond to publishers and subscribers. Submission of a new photo or a new comment corresponds to application events which are published and subscribed accordingly. As an example, consider the figure 2 that describes a feed formed by two new comment events. 100

115 5 Conclusions and Future Work In this paper we have described our initial steps on system support for application synchronisation in public displays. We have framed application synchronisation within the context of existent architectures for public display networks and described an initial set of application synchronisation requirements. Building on the characteristics of openness, autonomy and scalability, we have described our initial steps on investigating PubSubHubbub, a publish-subscribe protocol for the web space. We have design an initial API for application development using the PubSuHubbub. More research work has to be done on evaluating performance issues and the programming model, possibly with external application developers. Also, integration with remaining architectural components such as the Display Controller or Scheduler or application subscription and application description models has to be further explored. Finally, as potentially in the future there will be many hubs and tons of publishers and subscribers, we also need to investigate the steps towards a federation of hubs that work cooperatively. Acknowledgment Research group supported by FEDER Funds through the COMPETE and National Funds through FCT Fundação para a Ciência e a Tecnologia under the Project FCOMP-01-FEDER References 1. Advisory Board RSS. RSS 2.0 specification, S. Clinch, N. Davies, A. Friday, and G. Clinch. Yarely: a software player for open pervasive display networks. In Proceedings of the 2nd ACM International Symposium on Pervasive Displays, pages ACM, S. Clinch, N. Davies, T. Kubitza, and A. Schmidt. Designing application stores for public display networks. In Proceedings of the 2012 International Symposium on Pervasive Displays, page 10. ACM, S. Clinch, J. Harkes, A. Friday, N. Davies, and M. Satyanarayanan. How close is close enough? understanding the role of cloudlets in supporting display appropriation by mobile users. In Pervasive Computing and Communications (PerCom), 2012 IEEE International Conference on, pages IEEE, P. Consortium. Deliverable D2.1 - scientific evaluation of pervasive display networkprototype, H. R. Constantin Taivan, Rui Jos and B. Silva. Situatedness for global display web apps, N. Davies, M. Langheinrich, R. José, and A. Schmidt. Open display networks: A communications medium for the 21st century. Computer, 45(5):58 64, P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2): ,

116 9. B. Fitzpatrick, B. Slatkin, and M. Atkins. Pubsubhubbub core 0.3 working draft. Project Hosting on Google Code, available at googlecode. com/svn/trunk/pubsubhubbub-core-0.3. html, B. Johanson and A. Fox. The Event Heap: A coordination infrastructure for interactive workspaces. In WMCSA 02: Proceedings of the Fourth IEEE Workshop on Mobile Computing Systems and Applications, page 83, Washington, DC, USA, IEEE Computer Society. 11. R. José, H. Pinto, B. Silva, A. Melro, and H. Rodrigues. Beyond interaction: Tools and practices for situated publication in display networks. In Proceedings of the 2012 International Symposium on Pervasive Displays, page 8. ACM, R. Sayre. Atom: The standard in syndication. Internet Computing, IEEE, 9(4):71 78, O. Storz, A. Friday, and N. Davies. Supporting content scheduling on situated public displays. Computers & Graphics, 30(5): , C. Taivan and R. José. An application framework for open application development and distribution in pervasive display networks. In On the Move to Meaningful Internet Systems: OTM 2011 Workshops, pages Springer,

117 Computação Paralela, Distribuída e de Larga Escala 103

118 Task allocation in Transactional Memory with Thread Level Speculation Ricardo Filipe and João Barreto Instituto Superior Técnico - Technical University Lisbon /INESC-ID, Abstract. The recent programming paradigm that results from unifying Transactional Memory with Thread Level Speculation (TM+TLS) requires that the application calculates the number of tasks for each application thread that it should spawn. Then, the application should schedule those tasks in such a way that takes advantage of modern multicore multiprocessor architectures. In this work we study how the application can calculate the best number of tasks to spawn per TM+TLS application thread, through information provided by the operating system. We also study how the application should schedule those tasks to take advantage of processor and cache affinity on current multi-core multiprocessor computers. 1 Introduction The novel programming paradigm that results from unifying Transactional Memory with Thread Level Speculation (TM+TLS) [2] is in its infancy and requires a lot of preparation work before it can be fully deployed. Our original TM+TLS paper [2] assumed that the application would eventually be able to split each TM application thread into TLS tasks, in such a way that it would provide better performance through parallel execution of those tasks. The advantage of this unified runtime lies in sharing of procedures and data structures between TM and TLS. This is no easy ordeal, but we provide a starting point in this paper. The first problem that arises for the application is to know into how many tasks should it divide each application thread to run simultaneously. There are several hardware and runtime constraints that the application needs to account for in order to calculate an acceptable number, e.g. the number of available hardware threads and their current load. Fortunately, the operating system can provide information to the application on the number of hardware threads available in the computer and their current processing load. This should already allow the application to make a fair estimate on the initial number of tasks to spawn per application thread, within the hardware constraints. This work was supported by national funds through FCT - Fundação para a Ciência e a Tecnologia, under project PEst-OE/EEI/LA0021/2011 and by FCT project spec- STM (PTDC/EIA-EIA/122785/2010). 104

119 After calculating how many tasks the application should use, the application can then assign each task to an hardware thread in such a way that processor and cache affinity are used to TM+TLS s advantage in a multi-core multiprocessor. Several studies show that locality aware hardware thread scheduling is useful for shared memory multi-threaded applications [9, 10, 6, 3]. We will further show that this statement holds true for TM+TLS applications, where not only do tasks belong to the same application but also to a specific application thread. Most TM+TLS application threads access different areas of the shared data structures with high probability, but each TM+TLS application thread (and subsequently all tasks derived from it) will access its state variables and its portion of shared data multiple times. In this paper we will survey the related work on locality aware thread scheduling and multi-thread frameworks that allow dynamic thread creation. We will then study how to calculate the appropriate number of tasks that each TM+TLS application thread should spawn, and how we can apply locality aware thread scheduling to TM+TLS applications on multi-core multiprocessors. We propose several task allocation algorithms based on the findings of this study. We then test how the number of spawned tasks per application thread can influence the performance of the TM+TLS application and we evaluate our proposed task allocation algorithms against the operating system s thread scheduling. We conclude that a perfect task scheduling algorithm can achieve a 46% increase of the TM+TLS application performance compared to the operating system s scheduling algorithm. Finally we draw some concluding remarks and future work on task scheduling for TM+TLS applications. 2 Related Work Thread scheduling has been a highly researched subject for many years, from the times of uniprocessor computers, through multiprocessor computers and most recently on multi-core multiprocessor computers [8, 1, 3]. It has always been a major problem for operating systems to decide on the policies by which they prioritize and schedule software threads onto the available hardware threads. A part of that research has to do with processor cache affinity and its influence in threads performance because of data locality [9, 10, 6, 3]. Even though there is plenty of research in locality aware thread scheduling that has shown overall positive results, the introduction of such mechanisms in state-of-the-art operating systems has been slow paced. More specifically, several papers have shown that the cache shared by all cores of a processor can be taken advantage of on multiprocessors, either uni or multi-core, while the cache of a single core has almost no influence on application s performance on multi-core processors [9, 3]. There has been work on off-line or feedback based thread allocators that we might want to follow in the future [11, 7]. These papers provide thread allocators based on previous runs of the application, which is useful information to have in 105

120 addition to the hardware information provided by the operating system. Different applications are split into threads differently, which can be divided into tasks in different ways since those threads have different parallelizability properties. Even though there has been much work on thread scheduling for general parallel applications, we are unaware of such work focusing on Transactional Memory or Thread Level Speculation driven applications, which we which is the focus of this paper. 3 Optimal number of tasks per TM+TLS thread In order to find the best number of tasks that the application should spawn for each TM+TLS application thread, we turn to the operating system for help. At any point in time the operating system can provide us with information about the hardware it is running on and its current usage. We gather this information at application startup, since that is when the TM+TLS framework we use creates tasks. A better solution would be to get this information at run-time and update the number of running tasks as deemed necessary, but the TM+TLS framework does not allow changing the number of running tasks. From the information we gathered we devise a simple formula for the number of speculative tasks to spawn per TM+TLS application thread: T OT AL HT (1 CURR LOAD) NUM T ASKS = T MT LS T HREADS TOTAL-HT is the number of hardware threads that the processor of the computer where the application is running on has available at the time. CURR-LOAD is the load of other applications running on the processors at the time. TMTLS-THREADS is the number of application threads created by the programmer of the TM+TLS application. Hence, the number of tasks per TM+TLS thread that this application can spawn at startup time is approximately given by the number of available hardware threads doing close to no work. Each operating system has its own way of delivering information about the hardware it is running on. For example, in Linux kernel 3.8 the total number of hardware threads can be obtained by parsing the /proc/cpuinfo file, which has all the information about the processors on the machine it is running on. To obtain the current CPU load on Linux kernel 3.8 we can simply parse the /proc/stat file within a small time interval and average out the load on all hardware threads. This file contains kernel information to identify the amount of time the CPU has spent performing different kinds of work. 4 TM+TLS task allocation scenarios Every mainstream operating system allows for a software thread to be scheduled to a certain hardware thread. In operating systems that use POSIX threads this 106

121 Fig. 1. Sample code division of a TM+TLS application; a) Perfect task scheduling; b) Best task scheduling; c) Best-effort task scheduling is done by setting the cpu id variable of the thread attribute at thread creation: pthread attr t attr; cpu set t cpuset; CPU ZERO(&cpuset); CPU SET(cpu id, &cpuset); pthread attr setaffinity np(&attr, sizeof(cpuset), &cpuset); We use this mechanism to schedule each software thread of the TM+TLS application to a certain hardware thread of a processor. Each software thread is running a task of a certain TM+TLS application thread. In TM+TLS applications, tasks from a same TM+TLS application thread are bound to have more shared information than tasks from different TM+TLS threads (Figure 1). State-of-the-art multi-core processors have up to three levels of cache memory, smaller in size as we get closer to the processing cores. Level 1 cache is very small, usually in the KB range, and can be accessed only by the processing core assigned closest to it, which means very fast access times. Other levels of cache memory may be several MB in size, which can already contain a lot of relevant application information. The higher level cache is shared by some/all the cores of one multi-core processor, hence shared data between those cores should be kept there. This cache is obviously slower to access from the respective processing core than Level 1 cache. Previous work on thread scheduling has shown that only higher levels of cache are worthy of being taken advantage of in multi-core multiprocessors [6, 3], due to the size limitations of Level 1 cache. These observations for regular application threads lead us to believe that tasks from the same TM+TLS application thread should also be scheduled on hardware threads in the same processor, as much as possible. Taking all the previous observations into account, we devise three different algorithms for task allocation into hardware threads (all assume there are at least as many available hardware threads as tasks spawned): 107

122 Perfect task allocation The ideal scenario would be to have all of the TM+ TLS application s tasks scheduled to the same processor, but that may not be possible most of the time (Figure 1.a). So our perfect scheduler puts all tasks of all application threads running on the same processor. Best task allocation When perfect scheduling is impossible, the best case scenario we should aim for is when each processor has enough available hardware threads for the number of tasks to spawn per each TM+TLS application thread (Figure 1.b). Hence, our best task allocation algorithm groups all tasks of each application thread and runs each group on a different processor. This should be the most interesting use case in comparison to common operating system thread schedulers, since it takes tasks from the same TM+TLS application thread into account. Best-effort task allocation The third best scenario would be when each processor had a lower number of available hardware threads than the number of tasks per TM+TLS application thread, in which case some tasks of the same TM+TLS thread will have to run in different processors (Figure 1.c). So, our best effort task allocation policy puts as many tasks as possible from the same application thread running in the same processor. The worst case scenario is when we have many processors with a few hardware threads each, in which case most of the tasks of a TM+TLS application thread will run in different processors, therefore not taking advantage of any cache affinity at all. 5 Evaluation For the experiments of our study, we used the red-black tree benchmark, provided with the original TLSTM implementation. We perform exclusively read-only operations in our experiments, although our results should be generic for any read-write scenario. We always execute two TLSTM application threads, which execute 60 read-only operations on the red-black tree each. All results are the average of five runs of each experiment. Our experiments were done on a uniprocessor multi-core machine (Intel Core i7-2670qm, a quad-core CPU that supports 8 hardware threads) and a multicore multiprocessor machine (4 AMD Opteron 6272 CPUs with 16 cores each, making a total of 64 hardware threads). 5.1 Calculating the correct number of tasks In our first experiment we intend to show that we can correctly choose the number of tasks that each application thread should spawn. As we explained in Section 3, this number is given by the formula: NUM T ASKS = T OT AL HT (1 CURR LOAD) T MT LS T HREADS 108

123 Fig. 2. Experiments with 2 application threads: a)results for the Red-black tree benchmark on both machines; b)experiment of several task allocation scenarios As for the number of application threads the programmer defined (TMTLS THREADS) we arbitrarily chose 2 as its value. On the Intel CPU machine, the total number of hardware threads available (TOTAL HT) is 8, according to the CPU specification parsed from the operating system. The load of the CPU at application startup time (CURR LOAD) was 15%, as parsed from the operating system information. This translates into an optimal number of tasks per application thread of 3, for the Intel CPU machine: NUM T ASKS = 8 (1 0.15) 2 = 3 We ran our benchmark with {1,2,3,4,5} tasks per application thread so we could see if our tests calculated the best number of tasks or not. We ran the same experiment on the AMD CPU machine just to see what the supposed performance gains should be, and prove that our results on the Intel machine were not skewed by other factors of the benchmark. As we can see from the results in Figure 2, our framework did indeed calculate the best number of tasks per application thread, i.e. 3. We can also see that when using only 1 hardware thread per core (2 application threads with 2 tasks each) we still are 15% behind the optimal performance of the system. This suggests that hyper-threading should be taken advantage of when available, i.e. the number of hardware threads should be the input for TOTAL HT, not just the number of CPU cores. Also interestingly enough, we can see that if we overlap the execution of our application with current applications (using the maximum number of hardware threads, 2 application threads with 4 tasks each) the performance of our application will suffer a 4% penalty. As expected, if we use more tasks than the hardware supports (2 application threads with 5 tasks each) the performance of our application will suffer a hefty 49% penalty. 109

124 5.2 Task allocation scenarios On our second experiment we will show the performance differences on several task allocation scenarios, which take into account the CPU layout on our AMD machine. We made this experiment with 2 application threads and 4 tasks each. We tested our three task allocation policies (perfect, best and best-effort task allocation) against the operating system s thread scheduling policy. Perfect task allocation sees that a CPU of that machine supports enough hardware threads (sixteen) to execute all of the application s tasks (eight) and allocates all tasks to different hardware threads on the same CPU. Best task allocation will see that there are at least as many CPUs in the machine as there are application threads, and then allocate tasks of the same application thread on different hardware threads of the same CPU, but tasks from different application threads on different CPUs. Best-effort task allocation only knows that there are four CPUs on the machine and allocates one task from each application thread to an hardware thread on each CPU. Therefore, this task allocation policy takes almost no advantage of cache locality. We also include the results with the operating system s scheduling for comparison against the cache-aware task allocation algorithms we propose. As we expected, when all tasks of an application are running on the same processing unit we get the best performance of the application (Figure 2), a boost of 46% for perfect task allocation in comparison to the operating system s scheduler. This is due to all of those tasks running on hardware threads that share the same high level cache, which is big enough to accommodate some of their shared data. Our best task allocation policy was not far off in performance from perfect task allocation, offering a 41% boost to the operating system s scheduler. This stems from the fact that tasks from the same application thread are more prone to share data than tasks from different application threads. This is reinforced by our best-effort task allocation policy getting much worse performance results. Perhaps surprisingly though, even our best-effort task allocation policy has better performance results than the operating system s thread scheduling policy by 16%. We attribute this to the fact that the operating system also switches thread context to different cores often enough to have an impact on the application s performance, on top of having no locality cache awareness. 6 Conclusions and Future Work With this work we concluded that each application should spawn a number of tasks per TM+TLS thread according to the hardware the application is running on. Too few spawned tasks will not get the maximum performance that the application might allow, and too many tasks create a bottleneck on the TM+TLS runtime. We can also see from our experiments that cache locality has a noticeable performance impact on TM+TLS applications. The main contribution of this 110

125 work is to encourage careful scheduling of TM+TLS tasks for this kind of application, since not only are the hardware threads running tasks from the same application but, more importantly, from the same application thread. Although we calculate the number of tasks that should be spawned for a given multi-threaded application at startup, and we schedule software threads to hardware threads in a fixed manner, we know that each application has different thread layouts and usage patterns, as seen in several complex Transactional Memory benchmarks [5, 4]. Eventually, we would like to have a dynamic and runtime task allocator that could decide on the number of tasks to spawn per thread based on more than the hardware information. For example, the application threads divisibility and possible performance improvements of running their tasks in parallel should be taken into account. However, this will only be possible once the TM+TLS framework allows changing the number of tasks at runtime. References [1] Arora, N.S., Blumofe, R.D., Plaxton, C.G.: Thread scheduling for multiprogrammed multiprocessors. SPAA 98 (1998) [2] Barreto, J., Dragojevic, A., Ferreira, P., Filipe, R., Guerraoui, R.: Unifying thread-level speculation and transactional memory. In: Proceedings of the 13th International Middleware Conference. Middleware 12 (2012) [3] Boyd-Wickizer, S., Morris, R., Kaashoek, M.F.: Reinventing scheduling for multicore systems. HotOS 09 (2009) [4] Cao Minh, C., Chung, J., Kozyrakis, C., Olukotun, K.: STAMP: Stanford transactional applications for multi-processing. In: IISWC 08 (2008) [5] Guerraoui, R., Kapalka, M., Vitek, J.: Stmbench7: a benchmark for software transactional memory. SIGOPS Oper. Syst. Rev. (2007) [6] Kazempour, V., Fedorova, A., Alagheband, P.: Performance implications of cache affinity on multicore processors. Euro-Par 08 (2008) [7] Lee, J., Wu, H., Ravichandran, M., Clark, N.: Thread tailor: dynamically weaving threads together for efficient, adaptive parallel applications. SIGARCH Comput. Archit. News (2010) [8] Ousterhout, J.K.: Scheduling techniques for concurrent systems. In: Proceedings of the 3rd International Conference on Distributed Computing Systems. pp (1982) [9] Philbin, J., Edler, J., Anshus, O.J., Douglas, C.C., Li, K.: Thread scheduling for cache locality. SIGOPS Oper. Syst. Rev. (1996) [10] Squiillante, M.S., Lazowska, E.D.: Using processor-cache affinity information in shared-memory multiprocessor scheduling. IEEE Trans. Parallel Distrib. Syst. (1993) [11] Suleman, M.A., Qureshi, M.K., Patt, Y.N.: Feedback-driven threading: power-efficient and high-performance execution of multi-threaded workloads on cmps. ASPLOS XIII (2008) 111

126 Estimativa da Divergência de Réplicas em Sistemas Geo-replicados Andy Gonçalves, Valter Balegas, Sérgio Duarte, Rodrigo Rodrigues, and Nuno Preguiça CITI Departamento de Informática, Universidade Nova de Lisboa, Portugal Resumo Muitos serviços na Internet são suportados através de infraestruturas de cloud computing, em que os dados são replicados em máquinas de vários centros de dados distribuídos geograficamente. Para tal, é frequente o recurso a mecanismos de replicação otimista, já que esta permite melhorar a latência das operações, mas cria o problema de poder haver réplicas divergentes do mesmo objeto. Uma via para controlar a divergência das réplicas passa pelo uso de métricas que medem o quão desatualizados estão os dados de uma réplica. Neste artigo, propõe-se a utilização de uma abordagem probabilística ao cálculo dessas métricas de divergência. A nossa solução consiste em estimar no cliente a probabilidade que a execução de uma operação tem de violar as restrições da aplicação e, com base nisso, permitir às aplicações decidir se devem executar a operação local ou remotamente. Esta aproximação consegue reduzir significativamente a comunicação necessária entre réplicas, quando comparada com a utilização de soluções deterministas. Keywords: Cloud Computing; Geo-Replicação; Divergência limitada; Replicação otimista; Operação desconectada; Métricas 1 Introdução As infraestruturas de cloud são atualmente utilizadas para disponibilizar todo o tipo de serviços e aplicações, desde redes sociais e jogos, até ao comércio online ou ao fornecimento de conteúdos multimédia. Estas infraestruturas têm benefícios face às tradicionais arquiteturas cliente/servidor, porque facilitam a escalabilidade dos serviços decorrente da possibilidade de expansão da infraestrutura consoante a necessidade. As infraestruturas de cloud tendem ainda a recorrer à geo-replicação de dados para melhorar a disponibilidade e latência dos serviços, colocando réplicas dos dados próximo dos clientes que os acedem. O teorema CAP mostra que é impossível em simultâneo obter elevada disponibilidade e consistência dos dados e ainda tolerar o particionamento na rede [4]. Para lidar com esta impossibilidade, os sistemas desenvolvidos em ambientes de Este projeto é parcialmente financiado por PEst-OE/EEI/UI0527/2011 e PTDC/EIA-EIA/108963/

127 cloud optam frequentemente por relaxar a consistência dos dados, permitindo fornecer elevada disponibilidade apesar de eventuais partições na rede [3,6,2]. Esta aproximação pode ainda minimizar a latência por permitir o acesso à réplica mais próxima do cliente. Quando se usa esta aproximação, as aplicações podem aceder a versões desatualizadas dos dados, o que pode levar à violação das restrições de integridade das aplicações. Um exemplo disto é uma loja online, onde o stock de produtos tem de se manter positivo. Com acessos a uma versão desatualizada do stock, um cliente pode fazer uma operação que torna negativo o valor real do stock, apesar de o valor a que o cliente tem acesso se manter positivo. Para lidar com este problema, permitindo a execução local das operações nestas situações, foi proposta a utilização de soluções de particionamento das permissões de execução (escrow)[8] e controlo da divergência dos dados [11]. Estas soluções não são apropriadas para ambientes de cloud com um número elevado de clientes. No primeiro caso, haveria dificuldade em atribuir a todos os clientes as permissões necessárias antecipadamente, o que dificulta a sua utilização. No segundo caso, para limitar a divergência de forma determinista seria necessário efetuar comunicações entre os clientes e servidores sempre que um limite definido em qualquer cliente pudesse ser violado, o que inviabiliza a sua utilização. Neste trabalho propõe-se a utilização de técnicas probabilísticas para estimar a divergência das réplicas, em particular, das réplicas dos clientes. Para tal, desenvolveram-se algoritmos que estimam o valor da divergência das réplicas em termos do seu valor numérico e do número de operações executadas remotamente. A informação é coligida nos centros de dados e propagada para os clientes quando estes obtêm uma cópia dos dados, permitindo aos clientes estimar a divergência entre a sua cópia local e a cópia do servidor sem necessidade de comunicações adicionais com o servidor. Com base nesta informação, os clientes podem estimar, com um certo grau de certeza, se uma operação por eles efetuada garante uma restrição. Isto permite que o cliente adapte o nível de coordenação com o centro de dados consoante o pretendido pelo cliente. Os resultados preliminares obtidos mostram que o nosso sistema é capaz de manter restrições de integridade e adaptar o nível de coordenação oportunamente. Este artigo está organizado da seguinte forma: a secção 2 descreve trabalho relacionado em termos de mecanismos de controlo de divergência; a secção 3 apresenta a abordagem probabilística ao controlo de divergência usada no nosso trabalho; a secção 4 descreve a arquitetura do sistema e a secção 5 resume as conclusões tiradas com este trabalho. 2 Trabalho Relacionado Várias soluções foram propostas para medir e controlar a divergência de dados replicados. Alguns sistemas [11,9] definem métricas para determinar a divergência de uma réplica face a um estado abstrato, a que chamamos cópia única, com 113

128 todas as atualizações de todas as réplicas aplicadas por uma ordem de serialização. Estes sistemas forçam a sincronização para que a divergência de uma réplica face à cópia única não exceda os limites que a aplicação pode tolerar. O TACT [11] define diferentes métricas de divergência (valor númerico, diferença na ordenação das operações e frescura temporal) e propõe algoritmos para manter a divergência das réplicas limitada. Estes algoritmos exigem o contacto entre as réplicas sempre que uma operação pode levar à violação da divergência permitida. Em particular, para a métrica numérica, a solução proposta exige que, ao executar uma operação, uma réplica contacte com todas as réplicas cujos limites possam ser violados, o que pode levar a comunicações permanentes. No Mobihoc [9], uma das réplicas atua como servidor central, recebendo todas as atualizações e disseminando-as para as réplicas conforme os limites definidos por elas. Adicionalmente, o servidor central minimiza a comunicação com as réplicas com base na informação sobre o nível de interesse das réplicas nos diferentes objetos. Mais recentemente, foram utilizadas técnicas probabilísticas para determinar limites de frescura para leituras feitas em sistemas de quorums parciais, minimizando a comunicação [1]. O trabalho apresentado neste artigo explora igualmente uma aproximação probabilística para estimar a divergência dos dados. 3 Sistema para estimativa da divergência Nesta secção descreve-se a solução desenvolvida para estimar a divergência dos dados em ambientes de computação cloud. 3.1 Modelo do Sistema Neste trabalho consideramos um ambiente de cloud com dois níveis de replicação. No primeiro nível, existe um pequeno conjunto de centros de dados nos quais executam servidores, sendo que a base de dados é replicada totalmente em cada centro de dados. Num segundo nível, os clientes podem fazer cache dos dados presentes nos servidores. Os clientes replicam apenas pequenos subconjuntos dos dados de forma a permitir a execução local das operações e a sua submissão assíncrona para os servidores. Assume-se que os objetos armazenados no sistema são CRDTs [10], garantindo a convergência final das réplicas independentemente da ordem pela qual as atualizações são aplicadas às réplicas. A aproximação desenvolvida permite estimar a divergência das réplicas dos clientes e estimar a probabilidade de uma operação levar à violação das restrições da aplicação. A ideia base da nossa abordagem consiste em utilizar estatísticas obtidas a partir das atualizações vistas anteriormente, em conjunto com métodos probabilísticos para prever a evolução do estado do objeto ao longo do tempo. Estes mecanismos são usados para estimar a divergência de uma réplica em relação à cópia única, com um grau de certeza que pode ser controlado pela aplicação, com implicações diretas sobre o grau de comunicação entre a réplica do cliente e a réplica do centro de dados. 114

129 3.2 As Métricas As métricas utilizadas na nossa abordagem baseiam-se nas mesmas métricas propostas noutros sistemas [11,9], com as necessárias adaptações ao modelo de consistência usado: valor: indica o quão diferente está o valor numérico do objeto em relação à cópia única; operações: indica quantas atualizações feitas por outras réplicas estão por aplicar na réplica local; A figura 1 ilustra o significado de cada métrica. X é um objeto numérico que se encontra replicado. A atualização mais recente, feita pela réplica B no instante 15, decrementa X em 3 unidades. Essa operação não foi propagada ainda para a réplica A.A métrica de valor indica portanto uma divergência de três unidades, e a métrica das operações indica que há uma operação que ainda não foi propagada para a réplica A. Réplica A Cópia única Réplica B X = 10 X = 7 X = 9 (B, 9) : X -= 2 (A, 12) : X += 1 (C, 13) : X -= 1 (B, 9) : X -= 2 (A, 12) : X += 1 (C, 13) : X -= 1 (B, 15) : X -= 3 (B, 9) : X -= 2 (C, 13) : X -= 1 (B, 15) : X -= 3 Métricas para A: Valor: 3 Operações: 1 Métricas para B: Valor: 2 Operações: 1 Figura 1. Divergência de réplicas, em relação à cópia única 3.3 Estimar o Valor das Métricas Nesta secção descreve-se como se usam estatísticas sobre atualizações já vistas, para estimar o valor das duas métricas. A solução usada baseia-se na utilização duma estimativa simples que pressupõe que, quando existe um elevado número de clientes, a agregação das operações de todos leva a um ritmo de atualizações regular. Assim, para estimar o quão divergente está o objeto replicado face ao estado da cópia única, necessita-se de uma estatística: o ritmo de crescimento do objeto, λ obj, calculado a partir das atualizações observadas. De seguida mostramos como calcular o ritmo para ambas as métricas. 115

130 Métrica de Valor Para a métrica de valor o ritmo representa a variação do valor do objeto por unidade de tempo. Assim: λ objv al = V al T ime = V f V i T f T i onde T i e T f são as estampilhas temporais que demarcam o início e fim do período de tempo T ime, e V x é o valor numérico do objeto em T x. (1) Métrica de Operações Para a métrica de operações procura-se um ritmo que represente o número de atualizações por unidade de tempo, ou seja: λ objord = n T ime (2) onde T ime é o período de tempo que passou para o qual se quer saber o ritmo, e n o número de atualizações que aconteceram nesse período de tempo. O Ritmo na Estimativa A diferença entre o estado de uma réplica e o estado de cópia única é a divergência. O nosso objetivo é produzir uma estimativa da divergência, ð, que se aproxime desse valor. Como λ obj é um crescimento em função do tempo, estimar o estado de cópia única consiste em calcular a divergência que occoreu na réplica para o intervalo de tempo que decorreu desde a última sincronização com a réplica do centro de dados 1. Assim, sendo T ime o tempo passado desde o último estado visto, ð = λ obj T ime. Portanto o estado atual é estimado adicionando ao último estado visto, a divergência estimada, ð. O Grau de Certeza Estimada a divergência, há que calcular o grau de certeza da estimativa, que é probabilidade de o estado ter variado em ð. Para isso recorrese à distribuição de Poisson [5]. Sendo o número de eventos que ocorrem num espaço de tempo representado por uma variável aleatória X, que segue uma distribuição de Poisson com uma média de λ eventos num dado período de tempo, a probabilidade de acontecerem k eventos no mesmo período é dada pela expressão: P (X = k) = λk e λ, k N +, λ > 0 (3) k! Como λ obj é um ritmo por unidade de tempo, para se obter um grau que tem em conta o tempo, T ime, passado desde o último estado visto, o parâmetro λ equivale a λ = λ obj T ime = ð. Sendo o parâmetro k a divergência estimada, k = ð, pelo que para estas métricas, λ = k = ð. A distribuição de Poisson, originalmente, só pode ser usada com λ > 0. Assim, para ritmos negativos, é utilizado o módulo da divergência, porque a incerteza de 1 O centro de dados pode não ter visto todas as operações feitas até um determinado momento, mas a estimativa é feita com base nas operações que este dispõe. 116

131 um valor de divergência negativa é a mesma do simétrico desse valor, portanto passamos a ter os parâmetros λ = k = ð na expressão (3). 3.4 Limitar a Divergência Tal como em outros sistemas, para limitar a divergência nas réplicas locais, são definidos limites para as métricas em cada réplica. Como a estimativa tem um grau de incerteza associado, para limitar a divergência tem de ser definido também o grau de certeza com que se quer que ð esteja abaixo do limite, lim. Quanto maior este grau de certeza, menor é a probabilidade de o limite ter sido transposto, mas mais frequentemente ocorrerá coordenação com o centro de dados para limites baixos. Por oposição, um limite mais alto relaxa a necessidade de um grau de certeza maior. O grau de certeza, ζ, de que ð está abaixo do limite lim será a soma dos graus de certeza de todos os valores entre 0 (o mínimo de divergência permitido, ou seja, nenhuma), e lim: ζ = P (X k) = lim k=0 onde P pode ser calculado com a expressão (3). P (X = k), k N + (4) 3.5 Restrições de Integridade Para garantir que uma restrição é mantida, é necessário definir o mínimo de divergência necessária, ð res, que é necessário verificar-se para que a restrição seja violada. Posto isto, garantir uma restrição de integridade com grau de certeza ζ, torna-se um problema de verificar se o limite de divergência ð res é mantido, como visto na secção anterior. Suponha-se que no exemplo da loja online há a restrição que o stock nunca é negativo, e quer ser verificado com um grau de certeza alto, ζ = Um cliente viu há 3 segundos que o stock era de 10, com um ritmo de crescimento de -1 por segundo (portanto λ = k = ð = 1 3 = 3). Neste caso, ð res = 10, já que para a restrição ser violada, o stock teria de variar em 10, para ser 0. Assim, o grau de certeza, ζ res que a divergência foi de 10 ou menos, é obtido usando a expressão (4) com lim = 10 e λ = k = 3, cujo resultado é ζ res = Uma vez que ζ res ζ, a restrição é garantida com o grau de certeza desejado. 4 Arquitetura O sistema proposto é fornecido sob a forma de um middleware para permitir a sua fácil integração noutros sistemas já existentes. O sistema é composto por dois componentes, um gerador, nos centros de dados, e um estimador, nos clientes. Estes componentes situam-se entre as camadas da aplicação e do armazenamento. 117

132 No centro de dados, o componente gerador é responsável por guardar informação das atualizações recebidas, para gerar estatísticas sobre os objetos.estas estatísticas são usadas para gerar o ritmo de crescimento. No lado do cliente, o componente estimador é responsável por guardar informação sobre os limites das métricas, as restrições que se querem preservar, e o último estado dos objetos lidos no centro de dados, assim como o ritmo de divergência calculado pelo componente gerador. Quando o cliente invoca uma leitura sobre um objeto, esta é pré-processada pelo estimador para detetar se o objeto está desatualizado, segundo o critério de divergência em vigor para esse objeto. A atualização dos ritmos é feita periodicamente entre o gerador e o estimador, podendo o gerador comunicar oportunamente quando ocorre uma variação súbita do ritmo de divergência. Aplicação servidor Aplicação cliente 1) 4) 1) 4) Componente gerador Componente estimador 2) 3) 2) 3) Base de dados Cache local Centro de dados Cliente Figura 2. Arquitetura do sistema A figura 2 mostra esta arquitetura, e o fluxo de execução de uma operação. A aplicação faz um pedido ao componente, que implementa a interface da base de dados subjacente (1). O componente comunica com a base de dados (2) e obtém a resposta (3), e depois de executar as suas funções de geração/estimativa/comunicação, responde à aplicação (4). 5 Conclusão Este artigo apresenta uma solução que permite estimar a evolução dos dados e a divergência das réplicas em sistemas de cloud, usando duas métricas de divergência: o valor numérico dos dados e o número de operações não observadas. Com base nesta solução, permite-se às aplicações estimar o valor dos dados num dado momento e limitar a divergência das réplicas locais. O número de mensagens para calcular as estimativas é relativamente pequeno, quando comparado com outras soluções existentes na literatura, necessitando apenas de coordenar o 118

133 cliente e o centro de dados para trocarem meta-dados que indicam a estimativa de evolução do estado do objeto replicado. Para além de calcular a divergência, a abordagem proposta permite preservar restrições aplicacionais simples (inequações do tipo x k). Deste modo, a aplicação pode gerir o risco de executar uma operação localmente ou contactar o servidor para confirmar o resultado, reduzindo a latência no primeiro caso. No futuro, pretende-se estudar de forma mais completa o impacto da solução na diminuição das comunicações num sistema de cloud assim como integrar na solução aproximações mais sofisticadas de previsão [7]. Referências 1. Peter Bailis, Shivaram Venkataraman, Michael J. Franklin, Joseph M. Hellerstein, and Ion Stoica. Probabilistically bounded staleness for practical partial quorums. Proc. VLDB Endow., 5(8): , April Valter Balegas and Nuno Preguiça. Swiftcloud: replicação sem coordenação. IN- Forum, Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels. Dynamo: amazon s highly available key-value store. SIGOPS Oper. Syst. Rev., 41(6): , October Seth Gilbert and Nancy Lynch. Brewer s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News, 33(2):51 59, June Frank A Haight. Handbook of the Poisson distribution. Wiley New York, Wyatt Lloyd, Michael J. Freedman, Michael Kaminsky, and David G. Andersen. Don t settle for eventual: scalable causal consistency for wide-area storage with cops. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, SOSP 11, pages , New York, NY, USA, ACM. 7. Spyros Makridakis, Steven C Wheelwright, and Rob J Hyndman. Forecasting methods and applications. John Wiley & Sons, Nuno Preguiça, J. Legatheaux Martins, Miguel Cunha, and Henrique Domingos. Reservations for conflict avoidance in a mobile database system. In Proceedings of the 1st international conference on Mobile systems, applications and services, MobiSys 03, pages 43 56, New York, NY, USA, ACM. 9. Nuno Santos, Luís Veiga, and Paulo Ferreira. Vector-field consistency for adhoc gaming. In Proceedings of the 8th ACM/IFIP/USENIX international conference on Middleware, MIDDLEWARE2007, pages , Berlin, Heidelberg, Springer-Verlag. 10. Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. Conflictfree replicated data types. In Proceedings of the 13th international conference on Stabilization, safety, and security of distributed systems, SSS 11, pages , Berlin, Heidelberg, Springer-Verlag. 11. Haifeng Yu and Amin Vahdat. Design and evaluation of a conit-based continuous consistency model for replicated services. ACM Trans. Comput. Syst., 20(3): , August

134 Replicação Multi-nível de Bases de Dados em Memória Helder Martins, João Soares, João Lourenço, e Nuno Prequiça CITI Departamento de Informática, Universidade Nova de Lisboa, Portugal Resumo Os serviços Web são frequentemente suportados por sistemas com uma arquitetura em camadas, sendo utilizadas bases de dados relacionais para armazenamento dos dados. A replicação dos diversos componentes tem sido uma das formas utilizadas para obter melhorarias de escalabilidade destes serviços. Adicionalmente, a utilização de bases de dados em memória permite alcançar um desempenho mais elevado. No entanto é conhecida a fraca escalabilidade das bases de dados com o número de núcleos em máquinas multi-núcleo. Neste artigo propomos uma nova abordagem para lidar com este problema, intitulada MacroDDB. Utilizando uma solução de replicação hierárquica, a nossa proposta, replica a base da dados em vários nós, sendo que cada nó, por sua vez, executa um conjunto de réplicas da base de dados. Esta abordagem permite assim lidar com a falta de escalabilidade das bases de dados relacionais em máquinas multi-núcleo, o que por sua vez melhora a escalabilidade geral dos serviços. Keywords: Sistemas Distribuídos; Replicação; Macro-componente; Concorrência; Base de dados 1 Introdução Os serviços Web são frequentemente suportados por sistemas baseados em arquiteturas multi-camada, sendo os dados destes serviços mantidos por sistemas de gestão de bases de dados (SGBD). De forma a melhorar a escalabilidade e desempenho dos serviços, mecanismos de replicação são normalmente utilizados ao nível dos componentes dos sistemas [13,1]. Mais recentemente, a utilização de bases de dados em memória permite a estes serviços alcançar melhorias de desempenho quando comparados a SGBD tradicionais [2,7]. No entanto, a fraca escalabilidade dos SGBD em ambientes multi-núcleo, inclusive dos suportados por memória, continua a ser um dos fatores limitativos do desempenho destes sistemas [14]. Este trabalho foi parcialmente financiado pela Fundação para a Ciência e Tecnologia (FCT/MCTES), no contexto dos projetos de investigação PTDC/EIA- EIA/108963/2008 e PTDC/EIA-EIA/113613/

135 Throughput (Ktrans/sec) HSQL H Clients Throughput (Ktrans/sec) HSQL H Clients (a) Um SGBD (b) Um SGBD por cliente Figura 1. Escalabilidade para cargas de 100% leituras Estudos mostram que os actuais SGBD consomem até 30% do seu tempo em operações relacionadas com sincronização (ex: locking e latching), até mesmo quando apenas um cliente (i.e., apenas uma thread) está a executar no sistema [5]. Adicionalmente, a execução concorrente de duas operações pode ser mais lenta que a execução sequencial das mesmas devido à interação das operações [18]. Escalabilidade de SGBD em memória Comparativamente a bases de dados suportadas por disco, as bases de dados em memória não incorrem em overhead nem em contenção no acesso a I/O. Desta forma, é expectável que estes sistemas escalem com o número de núcleos dos processadores atuais. De forma a verificar a escalabilidade dos sistemas atuais, corremos o benchmark TPC-C com uma carga de 100% de leituras nos sistemas HSQL e H2 numa Sun Fire x4600 com 16 núcleos e 32 Gbytes de RAM. Os resultados, representados na figura 1(a), mostram a falta de escalabilidade destes motores, mesmo para cargas que não conflituam. De forma a melhor compreender se a falta de escalabilidade se deve a falta de recursos, corremos, concorrentemente, um número crescente de pares cliente e motor de bases de dados na mesma máquina. A figura 1(b) mostra dos resultados obtidos desta experiência, a qual representa o débito agregado. Estes resultados põem em evidência que o problema da falta de escalabilidade dos SGBD se deve ao seu desenho e não aos recursos disponíveis. 1.1 Abordagem proposta Em [14] mostra-se as limitações à escalabilidade dos SGBD em máquinas multinúcleos, inclusive em SGBD conhecidos como o MySQL e o PostgreSQL. Este trabalho apresenta o desenho do MacroDDB, uma solução baseada em replicação de bases de dados hierárquica, suportando a semântica snapshot isolation, na qual a base de dados é replicada por vários nós, sendo que cada nó, por sua vez, mantém um conjunto de réplicas da base de dados. O MacroDDB tem uma organização que em cada nó existe uma réplica que é a primária e as outras são secundárias. Uma transação de leitura executa numa 121

136 réplica secundária, não levando a nenhuma troca de mensagens com as outras réplicas do mesmo nó ou de outros nós. As transações de escrita executam inicialmente na réplica primária do nó em que executa o cliente até ao momento da validação final. Neste momento, a transação é validada, verificando a existência de transações concorrentes a executar noutros nós que conflituam com a transação executada [4]. A solução é baseada na utilização dum sistema de comunicação em grupo, como proposto por Kemmet et. al.[10]. Após a validação da transação, as restantes réplicas locais são atualizadas assincronamente. Esta aproximação hierárquica permite minimizar as mensagens trocadas na rede e o número de réplicas em que a validação das transações necessita de ser executada. A solução proposta neste artigo baseia-se em SGBD suportados em memória. 2 MacroDB: Bases de Dados Replicadas numa Máquina Tal como posto em evidência anteriormente, as atuais arquiteturas dos SGBDs apresentam uma fraca escalabilidade em máquinas multi-núcleo [14]. Isto deve-se ao facto dos SGBDs se basearem numa arquitetura otimizada para acessos ao disco rígido. A nossa solução para este problema passa por considerar cada nó do sistema como um sistemas distribuído de baixa latência com memória partilhada. Desta forma, e utilizando técnicas de replicação, a nossa solução, para cada nó, passa pela utilização de uma nova abstração, intitulada Macro-Componente. Esta abstração encapsula várias implementações de uma mesma interface, neste caso base de dados, num único componente, tal como descrito a seguir. MacroDB [15] é um exemplo de um Macro-Componente [11] desenhado para melhorar a performance de SGBDs em memória em processadores multi-núcleo. Para isso, replica a base da dados em diferentes motores de SGBDs, executando todos no mesmo nó, oferecendo uma visão global consistente aos clientes. MacroDB utiliza uma estratégia de replicação primário-secundário [17,6]. Transações de escrita, efetuadas pelo clientes, executam concorrentemente na réplica primária, sendo propagadas assincronamente e em batch, para as réplicas secundárias após commit no primário. As transações de leituras executam concorrentemente nas réplicas secundárias. Esta estratégia possibilita que transações de leitura não abortem transações de escrita, visto executarem em réplicas distintas. A execução de transações de escrita, nas réplicas secundárias, como uma operação única, reduz o tempo de aquisição de locks, minimizando assim a interferência entre transações. Para além disso, transações de leitura concorrentes são reencaminhadas para réplicas secundárias distintas, possibilitando assim balanceamento da carga pelas diferentes réplicas e melhorias de desempenho consideráveis [15]. De forma a oferecer uma visão global consistente da base de dados, o runtime do sistema garante a execução das transações de escrita nas réplicas secundárias pela sua ordem correta, i.e., pela mesma ordem em que estas fizeram commit na réplica primária, garantindo assim a consistência do estado das diferentes 122

137 réplicas do sistema. Para além disso, transações de leitura podem ainda ser temporariamente atrasadas de forma a garantir que a réplica na qual executam se encontre atualizada, i. e., que tenha executado todas as transações de escrita que fizeram commit posteriormente ao início da transação que irá executar. 3 MacroDDB: Macro-Componentes Replicados e Distribuídos O MacroDDB estende o MacroDB para um contexto distribuído, permitindo a replicação dum MacroDB por múltiplos nós dum centro de dados. Nesta secção descreve-se o desenho e implementação do MacroDDB. 3.1 Arquitetura do Sistema Um MacroDDB é um sistema de replicação de bases de dados, organizado como se apresenta na Figura 2. O MacroDDB é composto pelos seguintes componentes a executar em cada nó: (i) um MacroDB composto por múltiplas réplicas da base de dados; (ii) a componente de replicação, responsável pela coordenação da execução das operações nos múltiplos nós; e (iii) a componente do cliente, responsável pela interação da aplicação com o sistema. Uma aplicação interage com o sistema usando uma interface de bases de dados standard - JDBC na nossa implementação. Desta forma, para uma aplicação, o MacroDDB responde como uma qualquer base de dados. As operações executadas pela aplicação são processados inicialmente pela componente do cliente, a qual cria uma representação da operação. Estas operações são depois processadas pela camada de replicação que executa a operação no MacroDB local ou se coordena com as componentes de replicação dos outros nós para garantir a execução coordenada das operações. Esta coordenação é efetuada recorrendo a um sistema de comunicação em grupo. As operações são finalmente executadas no MacroDB local, onde o processamento segue a aproximação discutida na Secção 2. Nas secções seguintes descreve-se em detalhe os vários componentes do sistema e o modelo de execução das transações. Na solução atual, um MacroDDB replica completamente a base de dados. Esta aproximação, apesar de apresentar inconvenientes relativos ao espaço ocupado, tem uma vantagem importante: todas as transações de leitura podem ser executadas localmente e num único nó. 3.2 Componente do Cliente A componente do cliente (Cliente na Figura 2) é o componente do MacroDDB que a aplicação cliente utiliza para aceder às funcionalidades oferecidas pelo sistema, expondo a mesma interface do MacroDB, ou seja, a interface JDBC. Esta componente permite esconder à aplicação a localização e organização das réplicas das bases de dados. Para cada operação executada, cria-se uma representação da operação, a que chamamos macro-operação, que será usada para executar a 123

138 Nó 1 Nó 2 Nó 3 MacroDDB Cliente Cliente Cliente Camada replicação SCG Camada replicação SCG Camada replicação SCG Macro-comp. Macro-comp. Macro-comp. DB1 DB2 DB1 DB2 DB1 DB2 Figura 2. Arquitetura do Macro-componente distribuído operação nos macro-componentes. A operação é propagada para a componente de replicação do MacroDDB à qual a componente cliente está ligada. Macro-operação A Macro-operação contém a definição de uma dada operação ou seja, a sua implementação concreta. Para cada operação da interface é necessário existir uma definição da operação em forma de Macro-operação. Para isso a macro-operação apresenta funções que são invocadas posteriormente na componente de replicação, que contêm a implementação da operação. 3.3 Componente de Replicação A componente de replicação (ou Camada de replicação na Figura 2) é responsável pela execução das operações recebidas das aplicações e de outras réplicas do MacroDDB no MacroDB local. A componente de replicação está organizada internamente nos seguintes módulos: a) sistema de comunicação com o cliente; b) sistema de comunicação em grupo; c) distribuidor; e o d) tradutor. Sistema de comunicação com cliente O sistema de comunicação com o cliente é responsável pela interação com o cliente. Quando se recebe uma operação do cliente, esta é colocada numa fila de mensagens relativa ao cliente. Após a mensagem ser processada pelo componente módulo distribuidor, o resultado da execução da operação é devolvido ao cliente. Sistema de comunicação em grupo O sistema de comunicação em grupo gere a comunicação com as outras réplicas do MacroDDB, sendo responsável pelo envio e receção de mensagens. Este módulo usa o sistema de comunicação em grupo JGroups para efetuar a comunicação. Quando chega uma mensagem, a mensagem é inserida numa fila de pedidos não processados, permitindo libertar os recursos do sistema de comunicação em grupo e manter informação sobre a ordem das operações. Quando é solicitado o envio duma mensagem, recorre-se diretamente às operações definidas no sistema de comunicação em grupo usado. 124

139 Distribuidor O distribuidor é o módulo responsável pela execução das operações, consumindo as mensagens colocadas na fila de cada cliente e na fila do sistema de comunicação em grupo. O distribuidor tem a responsabilidade de determinar como cada operação deve ser executada e quando é que pode ser executada. Para isso as operações contém informação, que é utilizada pelo distribuidor que determina que operações podem ser executadas em simultâneo. Para permitir a execução concorrente de múltiplas operações, quando isso é aceitável, o distribuidor tem vários fios de execução a consumir as operações. Em cada momento existe, no máximo, um fio de execução a processar operações de cada fila. Tradutor O tradutor é responsável por receber o pedido (ou operação) que é enviada pelo componente distribuidor. Para esse efeito o tradutor oferece a função makecall que executa a operação definida na Macro-operação que foi criada na componente do cliente. A execução da operação definida na Macro-operação pode retornar três tipos de resposta: (i) resposta vazia para operações que não devolvem resultado; (ii) resposta com conteúdo; e (iii) resposta com exceção, quando uma operação termina em erro. Caso se trate duma operação enviada diretamente por um cliente, o resultado é devolvido ao cliente. Isolar a implementação das operações dentro de uma só função traz vantagens. Por um lado a implementação está isolada e portanto torna-se mais simples encontrar bugs nas implementações. Adicionalmente nem todo o conteúdo retornado pelo MacroDB é possível de ser enviado pela rede sem tratamento, portanto podemos efetuar computação arbitrária de forma a tornar o conteúdo viável para envio na rede. 3.4 Execução das transações Tendo apresentado as componentes que constituem o MacroDDB, nesta secção detalha-se a execução das transações. Como foi descrito, as operações executadas pela aplicação são enviadas pela componente do cliente para a componente de replicação, que define a lógica de processamento das operações. Para cada transação iniciada, todas as operações da mesma são executadas inicialmente no MacroDB local - esta execução pode ocorrer na réplica primária do MacroDB caso seja uma transação de escrita ou numa réplica secundária caso se trate duma transação assinalada como transação de leitura. No momento do commit, o processamento das transações difere. No caso das transações de leitura, a função commit do MacroDB é invocada e a transação conclui-se com sucesso (assumindo que o motor de base de dados garante que uma transação de leitura não pode falhar no momento do commit). No caso de uma transação de escrita é necessário validar a execução da transação. Para tal, verificam-se os potenciais conflitos escrita-escrita com transações que executaram concorrentemente. Esta verificação é efetuada recorrendo à propagação dos conjuntos de escrita através dum sistema de comunicação em grupo, 125

140 usando multicast atómico. Esta aproximação, usada anteriormente em vários sistemas [9,4], garante que os conjuntos de escrita são recebidos e processados pela mesma ordem em todas as réplicas. 4 Trabalho Relacionado A performance dos serviço Web está diretamente relacionada com a performance dos seus componentes, em particular do SGBDs. Replicação é um dos mecanismos mais utilizadas para melhorar a performance e a disponibilidade de SGBDs [16,3,12,1]. Diferentes propostas sugerem a utilização de middleware para melhorar a performance SGBD em ambientes distribuídos [13,16,3,12]. Estes trabalhos são ortogonais ao nosso, visto não considerarem a utilização de recursos da cada nó na performance geral do sistema. Ou seja, apenas consideram a performance do agregado dos nós do sistema, e não a utilização dos recursos disponíveis em cada nó. Ao tratar cada nó do sistema como um sistema distribuído de baixa latência, estendido com memória partilhada, MacroDDB apresenta uma solução de replicação hierárquica capaz de melhorar a performance global do sistema, garantindo o eficiente aproveitamento dos recursos de cada nó. Visto que o MacroDDB integra o MacroDB, cujo o objetivo é tirar o devido partido dos recursos oferecidos pelos sistemas multi-núcleo, naturalmente o MacroDDB torna-se uma solução para tirar partido de um conjunto de nós de máquinas multi-núcleo. O sistema Eve partilha os objetivos do nosso sistema [8]. Nessa solução, os pedidos são enviados para todas as réplicas, onde posteriormente os mesmos são agrupados em conjuntos independentes e executados concorrentemente de uma forma otimista. No caso da previsão estar errada e o valor das réplicas nos diferentes nós divergir, o sistema precisa de passar por um passo de desfazer as alterações e aplicar as mesmas sequencialmente. Na nossa solução garantimos que os nós terminam no mesmo estado, visto que são obrigados a executar os pedidos pela ordem total dada pela difusão atómica. 5 Conclusão Neste artigo apresentamos o MacroDDB, uma solução de replicação hierárquica de bases de dados, que oferece uma semâtica de snapshot isolation. Contrariamente a abordagens convencionais, MacroDDB mantém, em cada nó do sistema, um conjunto de réplicas da bases de dados. Estas utilizam um esquema de primário-secundário, em que transações de escrita executam na réplica primária e as de leitura em réplicas secundárias. Desta forma, transações de escrita podem executar localmente e num determinado nó sem que para isso haja necessidade de coordenação inicial com os restantes nós do sistemas. Apenas na validação de uma transacção de escrita é verificada a existência de transações concorrentes, que executem noutras máquinas, que conflituam, utilizando para isso comunicação atómica em grupo. Após validação, as restantes réplicas locais 126

141 são atualizadas assincronamente. Transações de leitura executam nas réplicas secundárias sem qualquer necessidade de coordenação com as restantes máquinas do sistemas. Esta abordagem permite assim lidar com a falta de escalabilidade dos sistemas de gestão de bases de dados em multi-núcleos. Adicionalmente possibilita minimizar a trocas de mensagens entre os diferentes máquinas do sistema. Referências 1. Jason Baker, Chris Bond, James Corbett, J. J. Furman, Andrey Khorlin, James Larson, Jean-Michel Leon, Yawei Li, Alexander Lloyd, and Vadim Yushprakh. Megastore: Providing scalable, highly available storage for interactive services. In CIDR, pages Lásaro Camargos, Fernando Pedone, and Marcin Wieloch. Sprint: a middleware for high-performance transaction processing. In Proceedings of the 2nd ACM SI- GOPS/EuroSys European Conference on Computer Systems 2007, EuroSys 07, pages , New York, NY, USA, ACM. 3. Sameh Elnikety, Steven Dropsho, and Fernando Pedone. Tashkent: uniting durability with transaction ordering for high-performance scalable database replication. In Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems 2006, EuroSys 06, pages , New York, NY, USA, ACM. 4. Sameh Elnikety, Willy Zwaenepoel, and Fernando Pedone. Database replication using generalized snapshot isolation. In Proceedings of the 24th IEEE Symposium on Reliable Distributed Systems, SRDS 05, pages 73 84, Washington, DC, USA, IEEE Computer Society. 5. Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, and Michael Stonebraker. Oltp through the looking glass, and what we found there. In Proceedings of the 2008 ACM SIGMOD-ICMD, SIGMOD 08, New York, NY, USA, ACM. 6. Abdelsalam A. Helal, Bharat K. Bhargava, and Abdelsalam A. Heddaya. Replication Techniques in Distributed Systems. Kluwer Academic Publishers, Norwell, MA, USA, Robert Kallman, Hideaki Kimura, Jonathan Natkins, Andrew Pavlo, Alexander Rasin, Stanley Zdonik, Evan P. C. Jones, Samuel Madden, Michael Stonebraker, Yang Zhang, John Hugg, and Daniel J. Abadi. H-store: a high-performance, distributed main memory transaction processing system. Proc. VLDB Endow., 1(2): , August Manos Kapritsos, Yang Wang, Vivien Quema, Allen Clement, Lorenzo Alvisi, and Mike Dahlin. All about eve: execute-verify replication for multi-core servers. In Proceedings of the 10th USENIX conference on Operating Systems Design and Implementation, OSDI 12, pages , Berkeley, CA, USA, USENIX Association. 9. Bettina Kemme and Gustavo Alonso. A suite of database replication protocols based on group communication primitives. In Proceedings of the The 18th International Conference on Distributed Computing Systems, ICDCS 98, pages 156, Washington, DC, USA, IEEE Computer Society. 10. Bettina Kemme and Gustavo Alonso. A new approach to developing and implementing eager database replication protocols. ACM Trans. Database Syst., 25(3): , September

142 11. Paulo Mariano. Repcomp - replicated software components for improved performance. Master s thesis, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, September Takeshi Mishima and Hiroshi Nakamura. Pangea: an eager database replication middleware guaranteeing snapshot isolation without modification of database servers. Proc. VLDB Endow., 2(1): , August Christian Plattner and Gustavo Alonso. Ganymed: scalable replication for transactional web applications. In Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, Middleware 04, pages , New York, NY, USA, Springer-Verlag New York, Inc. 14. Tudor-Ioan Salomie, Ionut Emanuel Subasu, Jana Giceva, and Gustavo Alonso. Database engines on multicores, why parallelize when you can distribute? In Proceedings of the sixth conference on Computer systems, EuroSys 11, pages 17 30, New York, NY, USA, ACM. 15. João Soares, João Lourenço, and Nuno M. Preguiça. Macrodb: Scaling database engines on multicores. In Proceedings of Euro-Par 2013, Matthias Wiesmann and Andre Schiper. Comparison of database replication techniques based on total order broadcast. IEEE Trans. on Knowl. and Data Eng., 17(4): , April Matthias Wiesmann, André Schiper, Fernando Pedone, Bettina Kemme, and Gustavo Alonso. Database replication techniques: A three parameter classification. In Proceedings of the 19th IEEE Symposium on Reliable Distributed Systems, SRDS 00, pages 206, Washington, DC, USA, IEEE Computer Society. 18. Jingren Zhou, John Cieslewicz, Kenneth A. Ross, and Mihir Shah. Improving database performance on simultaneous multithreading processors. In Proceedings of the 31st VLDB, VLDB 05. VLDB Endowment,

143 Gestão de Dados e Conhecimento 129

144 Conceção de um Data Warehouse Espácio- Temporal para Análise de Trajetórias Humanas Vitor Oliveira, Ana Paula Afonso, and André Falcão Universidade de Lisboa, Faculdade Ciências Resumo Com a evolução das tecnologias móveis à disposição dos utilizadores, tem surgido um aumento exponencial do volume de dados produzidos a partir estes dispositivos. Contudo, os dados existentes sobre a mobilidade humana apresentam ainda redundâncias, incoerências, pouca informação semântica e ainda são escassos os algoritmos de prospeção de dados especialmente concebidos para este tipo de dados, espáciotemporais. Neste artigo é proposto um modelo de um Data Warehouse Espácio-Temporal de trajetórias humanas, assim como os processos necessários para o tratamento de dados e o seu enriquecimento com informação semântica com o objetivo de criar as bases para a concretização de aplicações e algoritmos de deteção de comportamentos e atividades de utilizadores móveis. Este modelo é testado num exemplo concreto, o conjunto de dados Geolife, para uma população de 182 utilizadores com cerca de 24 milhões pontos geolocalizados em trajetórias. Os resultados mostram que o sistema desenvolvido permite níveis de análise de grande complexidade, permitindo simultaneamente uma grande flexibilidade para processamento analítico. Keywords: Data Warehouse, Dados Espácio-Temporais, OLAP, Trajetórias, ETL. 1 Introdução Desde o início da década de 2000 tem-se observado uma rápida evolução das tecnologias móveis e como resultado desta evolução tecnológica, a captura de grandes volumes de dados referentes a utilizadores móveis, entre outros, tornou-se tecnicamente e economicamente viável, existindo assim um número crescente de novas aplicações com o objetivo de organizar, gerir e extrair informação relevante desses dados, nomeadamente o estudo de comportamentos humanos através das suas trajetórias. Uma trajetória é um caminho que um dado objeto móvel executa num determinado espaço e período de tempo. Tipicamente uma trajetória espácio-temporal é representada por um conjunto ordenado de pontos Pi = (xi, yi, ti) em que xi e yi representam as coordenadas geográficas no tempo ti e compõe uma trajetória T = {P1,..., Pn} [1]. De modo a extrair informação útil e relevante destes conjuntos de dados é fundamental a conceção de métodos adequados para 130

145 o tratamento e análise desses dados de modo a permitir a descoberta de padrões de comportamento dos utilizadores, análise de perfil, planeamento urbano, controlo de tráfego, marketing, entre outras. Contudo, o volume de dados produzidos por movimentos humanos é ainda escassamente utilizado para análise, descoberta de conhecimento e prospeção de dados. As principais razões para este facto prendem-se com dois aspetos. O primeiro, relaciona-se com o facto dos dados sobre trajetórias tipicamente representarem redundâncias, inconsistências e não possuem ou possuem pouca informação semântica, assim como não existe uma estrutura abstrata de representação. Por outro lado, existem poucos algoritmos especialmente concebidos para prospeção de dados e exploração de padrões para este tipo de objetos móveis. Uma das aproximações para a resolução do primeiro problema é a construção de um Data Warehouse (DW) [2]. Num DW os dados são organizados e manipulados de acordo com os conceitos e operadores fornecidos por um modelo de dados multidimensional que apresenta os dados na forma de um cubo de dados [3]. Um cubo de dados permite que os dados sejam modelados e visualizados em múltiplas dimensões, representando cada dimensão uma perspetiva de negócio e é tipicamente implementado através de um esquema em estrela (star schema) [3]. Um DW é modelado com base numa tabela de factos sendo que cada registo é chamado de facto, sendo o seu nível de detalhe designado por granularidade. Através de operações OLAP (On- Line Analytical Processing) [2] é possível explorar os dados contidos no DW, utilizando várias perspetivas e níveis de granularidade. Este artigo tem como objetivo a modelação e concretização de um Data Warehouse para dados espácio-temporais referentes a trajetórias de humanos com o intuito de facilitar a extração de informação. É apresentado o processo ETL (Extract, Transform, Load) [4] que efetua o correto tratamento do conjunto de dados e produz novas informações. Será também dada ênfase à criação de um cubo de dados que permita realizar uma análise multidimensional e hierárquica dos dados no DW, de forma a ser possível efetuar assim análises OLAP. Este artigo está organizado da seguinte forma: na secção 2 é apresentado o trabalho relacionado, sendo na seguinte secção apresentado o modelo proposto e os processos criados para o tratamento de dados. Por último, será apresentada a concretização do DW de acordo com o que foi proposto, e a experimentação do mesmo, tal como as conclusões retiradas deste trabalho e respetivo trabalho futuro. 2 Trabalho Relacionado Um Data Warehouse Espácio-Temporal, também definido como Data Warehouse de Trajetórias (DWTrs) [3] tem como objetivo a transformação dos dados sobre trajetórias em informação relevante que possa ser utilizada para fins de tomada de decisão em aplicações ubíquas, serviços baseados em localização, controlo de tráfego, planeamento urbano, entre outros [3]. Esta área tem sido pouco explorada na literatura, mas existem algumas propostas que irão ser apresentadas de seguida. 131

146 Braz et al. [5] propõem um modelo de DWTrs, baseado num esquema em estrela com a granularidade da tabela de factos a representar um setor de uma grelha regular de um dado espaço e tempo, sendo constituída por medidas numéricas que caracterizam o movimento da trajetória. As dimensões representam o espaço e tempo (x, y, t), não armazenando qualquer tipo de informação semântica, nomeadamente dados espaciais ou pontos de estadia das trajetórias. Cada uma das dimensões possui hierarquias simples (e.g., nível 0 > nível 1 > nível 2), não permitindo grande detalhe em análises OLAP. Spaccapietra et al. [6] sugerem um modelo concetual para o enriquecimento semântico de trajetórias. Este modelo para além de guardar dados espaciais, permite a contagem distinta de trajetórias e utilizadores/objetos (através de identificadores), e define pontos de estadia nas trajetórias. Porém, não possui qualquer tipo de agregação e hierarquização de informação. Em relação ao processo ETL de trajetórias, Marketos et al. [7] apresentam diversas técnicas: (1) um método para a reconstrução de trajetórias durante o processo de carregamento de uma base de dados de movimentos espaciais; (2) métodos para a caracterização dos dados dos movimentos; (3) a agregação de medidas para análises OLAP. Este modelo de dados é similar ao modelo de Braz et al. [5], mas possui dimensões e hierarquias, que permitem efetuar análises OLAP. Embora não armazenem dados espaciais (o espaço é caracterizado por células) possuem informações geográficas dos mesmos. Por último, o modelo de Almeida et al. [8] adota também o conceito de trajetórias semânticas, englobando a caracterização espacial e temporal da trajetória e sua caracterização semântica (e.g., pontos de estadia, informações do espaço e do utilizador/objeto que realizou um movimento). O modelo proposto permite a análise OLAP, contagem distinta, tendo também um módulo de SIG (Sistema de Informação Geográfica) integrado. Apesar dos trabalhos mencionados, ainda não existe um modelo de dados consistente para análise de comportamento de utilizadores móveis no espaço e no tempo, integrado com informação semântica de forma a aumentar a expressividade do modelo e simplificar a sua compreensão e utilização através de um cubo de dados multidimensional. De facto, a existência de dados permitirá criar as bases para a concretização de aplicações e algoritmos de deteção de comportamentos, atividades de utilizadores móveis, e ainda demonstrar a sua utilidade nas áreas mencionadas. 3 Data Warehouse Espácio-Temporal 3.1 Modelação Dimensional Uma das fases principais do ciclo de vida de um DW é a modelação dimensional [2]. Para a concretização dos objetivos propostos foi imperativo que o modelo construído tivesse como base coordenadas GPS e todas as suas características adjacentes, para além dos requisitos de um DW Espácio-Temporal definidos por Giannotti et al. [3]. Contudo, é fundamental a identificação dos processos de 132

147 negócio selecionando as questões que o DW irá responder. Um dos objetivos do DW proposto é responder a questões tais como, qual é o total de utilizadores que se movimentam numa dada região num dado intervalo de tempo? ou existe diferença substancial na velocidade média dos veículos numa região durante o fim-de-semana?. Este tipo de questões podem ser utilizadas para diversos fins, nomeadamente análise urbana, análise de perfil, análise de marketing, entre outras. Apesar de as mesmas puderem ser respondidas por sistemas OLTP (Online Transaction Processing), a opção recai em OLAP pelos custos computacionais e tempos de resposta serem muito inferiores. Assim, a granularidade relativa à tabela de factos é a representação de um ponto de uma trajetória através das suas coordenadas capturadas por um dispositivo relativas a uma localização, de uma determinada localização e de um determinado ponto de estadia (pertencente a uma ou mais categorias), relativos a uma trajetória, de um determinado utilizador, num determinado dia e hora, e associadas a um tipo de movimento do utilizador. Na Fig. 1 podemos observar o esquema em estrela para o modelo proposto, sendo as dimensões necessárias para a sua constituição as seguintes: Figura 1. Modelo em estrela de representação de trajetórias humanas Dimensão Utilizador. Identifica o utilizador e caracteriza o perfil do mesmo. Dimensão Trajetória. Identifica e caracteriza a trajetória correspondente ao ponto da trajetória a que o facto pertence. 133

148 Dimensão Data. Identifica a data de um determinado registo. Contém a hierarquia: Ano > EstaçãoAno > Mês > Quinzena > Dia. Dimensão Tempo. Identifica a hora e período do dia de um determinado registo. Contém a hierarquia: PeriodoDia > Hora > Minuto > Segundo. Dimensão Localização. Identifica o setor (região da cidade), ao qual pertencem as coordenadas. Dimensão Ponto de Estadia. Identifica e obtém uma descrição mais pormenorizada de um ponto de estadia para um determinado registo. Contém a hierarquia: Continente > Pais > Distrito > Região > Cidade > Freguesia > Bairro > CódigoPostal > Rua > Número. Dimensão Categoria Ponto de Estadia. Identifica as categorias de um ponto de estadia (e.g., restaurante, faculdade). Dimensão Dispositivo de Captura. Identifica e caracteriza o dispositivo com que foram obtidas o conjunto de coordenadas do registo. Dimensão Tipo de Movimento. Identifica o modo de deslocação do utilizador e caracterização desse modo de transporte (e.g., bicicleta, natural). As dimensões Localização, Ponto de Estadia e Utilizador possuem atributos de registo histórico tais como, InicioValidade, FimValidade, Razao e EmVigor, por se tratarem de dimensões de mudança lenta [2]. Foi ainda modelada uma dimensão do tipo ponte [2], que permite efetuar a relação entre as dimensões Ponto de Estadia e a Categoria Ponto de Estadia. A tabela de factos Movimento é composta pelas chaves estrangeiras das dimensões, pela chave OrdemTrajetória (dimensão degenerada [2]), latitude e longitude que caracterizam o registo geográfico que faz parte da trajetória, e as medidas numéricas velocidade média, distância percorrida, e tempo decorrido. 3.2 Modelação do Processo ETL O processo ETL compreende três etapas [4]: extração dos dados do sistema operacional, transformação dos dados extraídos tendo em conta as regras de negócio, e o carregamento de dados para o DW. Para além da análise e tratamento dos dados, é durante a fase de ETL (mais concretamente na fase de transformação) que são criadas as rotinas para a criação de informação semântica para enriquecer a qualidade do DW. Nesta secção serão descritas as rotinas criadas com este propósito, nomeadamente a rotina para caracterização de trajetórias, clustering de localizações, e extração de pontos de estadia. Caracterização de trajetórias. Relativamente à caracterização das trajetórias é possível calcular a velocidade média entre dois pontos seguindo a abordagem de Zheng et al. [9]: dados dois pontos consecutivos P1 e P2, é calculada a distância D1, tal como o intervalo temporal t1, e portanto a velocidade é calculada pela fórmula P1.V1 = D1/t1. Para calcular D, é utilizada a fórmula de Haversine pois permite uma melhor precisão para pequenas distâncias [10]. 134

149 Clustering de localizações. A formalização da representação do espaço geográfico quando se lida com dados espaciais é essencial. Uma abordagem possível é associar informação semântica para cada registo de uma trajetória, como por exemplo a rua e número de um dado bairro. Porém, nem sempre é possível obter estas informações semânticas devido a não existir autorização para o uso das mesmas, ou devido a problemas de captura nos dados. Giannoti et al. [3] refere que uma dimensão geográfica permite a divisão dos diversos registos por setores pertencentes à área geográfica abrangida. Uma abordagem possível é realizar esta divisão através de clustering de localizações a partir de uma amostra dos registos iniciais (caso o volume de dados seja muito elevado). Para a amostra produzida é efetuado o cálculo das distâncias [11], aplicando depois o método de clustering hierárquico ward [12] para dividir a amostra inicial em grupos (clusters). É utilizado um algoritmo hierárquico pois os registos são assim organizados numa árvore de acordo com a distância entre os mesmos, ficando os registos similares no mesmo ramo. Para organizar a totalidade dos registos, foi especificado o Algoritmo 1. Para cada registo pertencente ao conjunto inicial calcula-se a sua distância euclidiana [13] relativamente a cada grupo, sendo guardado o grupo para qual o registo tinha uma distância menor. Optou-se pela utilização do algoritmo euclidiano ao invés do algoritmo de Haversine pelos custos computacionais associados a este. Algoritmo 1: Algoritmo para distribuição de registos por clusters Input: Um conjunto de dados iset = {is} e um conjunto de clusters clusterset = {C} Output: Um conjunto de dados oset = {os} 1 foreach iset is do 2 mindist = 1e34; 3 mincluster = 1; 4 foreach clusterset c do 5 dx = is.x c.x; 6 dy = is.y c.y; 7 dist = dx dx + dy dy; 8 if dist < mindist then 9 mindist = dist; 10 mincluster = c.id; 11 os.x = is.x; 12 os.y = is.y; 13 os.idgrupo = c.id; 14 oset.insert(os); 15 return oset; Extração de pontos de estadia. Um ponto de estadia corresponde a duas situações que podem ocorrer numa trajetória (Fig. 2): na primeira situação (ponto de estadia 1) o utilizador permanece num determinado local um certo limite de tempo (e.g., o utilizador entra num edifício perdendo assim o sinal de GPS, sendo este readquirido quando sai). Na segunda situação (ponto de estadia 2) o utilizador permanece numa determinada região por um certo limite de tempo, obtendo-se assim diversos pontos GPS nessa região. Para a extração dos pontos de estadia de trajetórias, foi elaborado o Algoritmo 2 adaptado de [14,15]. O algoritmo estabelece dois limites, distlim e templim, que definem respetivamente, o limite máximo de distância a que um 135

150 Figura 2. Representação de pontos de estadia certo ponto Pi pode estar do ponto inicial da região, e o limite máximo de tempo que um utilizador fica numa determinada área. Para obter informações semânticas sobre cada ponto de estadia é utilizado o serviço Google Reverse Geocoding 1, nomeadamente as que representam a dimensão Ponto de Estadia do modelo da Fig. 1. A sua categorização é feita através do Google Places 2, sendo obtida as categorias e o respetivo nome do local. Algoritmo 2: Algoritmo para extração pontos de estadia Input: Uma Trajetória T, um limite de distância distlim, e um limite de tempo templim Output: Um conjunto de pontos de estadia P E = {P } 1 i = 0, nump ontos = T ; // número de pontos GPS na trajetória 2 while i < nump ontos = 0 do 3 j = j + 1, T oken = 0; 4 while j < nump ontos = 0 do 5 dist = Distancia(p i, p j); // dist^ancia entre pontos [10] 6 if dist > distlim then 7 tempdecorrido = p j.t p i.t ; // tempo entre pontos 8 if tempdecorrido > templim then 9 P.coordMedia = calculacoordmedia({p k i k j}); 10 P E.inserir(P ); 11 i = j, T oken = 1; 12 break; 13 j = j + 1; 14 if T oken! = 1 then i = i + 1; 15 return P E; Apesar de existirem outras alternativas para a deteção de pontos de estadia [15], como clustering (e.g., DBSCAN), optou-se pelo método anterior na medida em que, a entrada e saída de um utilizador num edifício não iria ser considerada ponto de estadia uma vez que não existiriam pontos suficientes para formar clusters nestes algoritmos. Embora este processo enriqueça a informação disponível neste DW, a identificação exata do ponto a que um local de estadia corresponde é um processo complexo derivado a diversos fatores: erro de captura através do dispositivo de GPS e grande concentração de pontos de interesse nas grandes cidades. Zheng et al. [15] apresentam uma solução para estes problemas, mas apenas calcularam o ponto de interesse visitado por grupos de utilizadores, não apresentando soluções de cálculo do ponto exato que foi visitado por um utilizador individual. 1 https://developers.google.com/maps/documentation/geocoding/ 2 https://developers.google.com/places/documentation/ 136

151 4 Aplicação do Data Warehouse ao Geolife Nesta secção é realizada a aplicação do modelo proposto, concretizando o DW e respetivo cubo de dados para análise, e são realizadas algumas interrogações OLAP (através do cubo de dados e respetivas hierarquias) tendo em conta os processos de negócio abrangidos pelo modelo e as questões formuladas. 4.1 Conjunto de Dados O conjunto de dados utilizado neste processo foi disponibilizado pela Microsoft Research Asia relativos ao projeto Geolife [16]. Os dados correspondem à versão 1.3, sendo recolhidos por um total de 182 utilizadores durante um período de 5 anos (Abril de 2007 a Agosto de 2012). Os dados foram recolhidos através de sensores e telemóveis com GPS estando sujeito a erros. As trajetórias estão registadas com uma marca temporal de 1 a 5 segundos ou espacial de 5 a 10 metros entre pontos. Apesar dos dados abrangerem cerca de 30 cidades na China e existirem registos em outros países/continentes, para este projeto foram apenas utilizados os dados em Beijing, dado que de um total de 18,670 trajetórias do conjunto de dados 17,107 estão concentradas nesta cidade. 4.2 Processo ETL Depois do modelo proposto ser concretizado no SQL Server [17], foi necessário popular o DW através do processo ETL especificado na secção 3.2. Extração A extração [4] foi efetuada a partir dos ficheiros do conjunto de dados, sendo realizada uma análise a partir do domínio e das regras de integridade das colunas, tal como a qualidade e a quantidade de dados disponíveis para a respetiva extração. Os dados foram importados dos ficheiros de origem para um único ficheiro CSV, com o seguinte para posterior limpeza e transformação: userid, trajetória, ordem trajetoria, latitude, longitude, altitude, gps UTC timestamp. Transformação Esta fase envolveu a eliminação de duplicação de dados, registos temporais errados, registos espaciais anormais, sendo também efetuada a correção do fuso horário [16]. Através da abordagem de caracterização de trajetórias, foi calculada a distância percorrida, tempo gasto, e a média da velocidade para cada trajetória, sendo também calculadas as medidas numéricas definidas na tabela de factos. O clustering dos registos da região de Beijing foi realizado em R [11]. Através de uma amostra de 10% dos dados, foi obtida a árvore com os respetivos registos. Dado a enorme quantidade de grupos gerados, através do comando cuttree [11] foi gerada uma árvore com apenas 256 grupos. Por fim, foi efetuada a extração dos pontos de estadia usando os de 30 minutos para templim e 200 metros para distlim, sendo obtidos cerca de 21,000 pontos de estadia. Neste processo foram detetados milhares de pontos de estadia que 137

152 pertenciam ao mesmo local sendo realizada uma análise dos dados através do atributo MoradaCompleta (obtido através do Google Reverse Geocoding) para eliminar os pontos de estadia repetidos e reduzir o seu número para análise. Através desta operação obteve-se cerca de 4,000 pontos de estadia. Carregamento de dados Nesta última fase do processo ETL foi efetuado o carregamento de dados para o DW. Este processo foi efetuado utilizando a ferramenta Integration Services [17] do SQL Server, que permite automatizar os processos e efetuar o tratamento de erros que possam surgir durante o carregamento de dados. Para tal foi concebido um processo iterativo para efetuar a ligação entre os ficheiros CSV resultantes da fase de transformação, e as tabelas criadas anteriormente no SQL Server. Para efetuar o carregamento das dimensões Ponto de Estadia, Categoria Ponto de Estadia e respetiva dimensão de ponte, foi criado um outro processo, porque o facto da dimensão de ponte ser constituída por chaves estrangeiras as dimensões referenciadas tiveram de ser carregadas em primeiro lugar. 4.3 Cubo de Dados A construção do cubo de dados foi elaborada utilizando o módulo Analysis Services [17] do SQL Server. Após a definição da fonte de dados, a elaboração do cubo é feita através da definição das dimensões, sendo neste processo definidas as hierarquias modeladas para efetuar técnicas como drill-down e roll-up [12]. A construção do cubo é concluída com base na tabela de factos, uma vez que todas as dimensões estão referenciadas nesta tabela através de chaves estrangeiras. Os dados multidimensionais são guardados utilizando o método MOLAP [17], porque apesar de tornar o processamento do cubo mais moroso, os ganhos de desempenho nas interrogações são compensadores. Este fator é de extrema importância quando é utilizada a técnica pivot para visualização dos dados sobre diversas perspetivas e para escolha das dimensões pretendidas [12]. Para realizar a integração da dimensão Categoria Ponto de Estadia, seguiuse a abordagem de Ferrari et al. [18], que utiliza a dimensão de ponte definida anteriormente. Esta dimensão de ponte é definida como um measure group, interligando assim a dimensão de Ponto de Estadia e as respetivas categorias das mesmas. Foram ainda criadas as seguintes medidas calculadas: TempoDecorrido- Minutos, medida Tempo em minutos, e DistanciaPercorridaMedia, que devolve a distância média percorrida de um certo conjunto de coordenadas. 4.4 Experimentação do modelo De forma a experimentar os níveis de análise e flexibilidade do modelo, esta secção apresenta um conjunto de interrogações simplificadas de acordo com os processos de negócio mencionados na secção 3.1. Na Fig. 3, podemos observar a distribuição dos utilizadores ao longo do dia nos diversos bairros de Beijing (destaque para o bairro de Zhongguancun). 138

153 Figura 3. Representação de utilizadores nos bairros de Beijing Na Tabela 1(a) pode-se observar a utilização dos transportes coletivos pelos utilizadores, apresentado um maior detalhe (drill-down) para segunda-feira. Por sua vez, na Tabela 1(b) podem-se observar as velocidades médias dos transportes motorizados nos diferentes dias da semana, notando-se um aumento médio ao fim de semana. (a) (b) Tabela 1. Tempo passado em transportes coletivos e Velocidade média de transportes motorizados A Tabela 2 apresenta os pontos de estadia mais populares de Beijing, mostrando o tempo lá passado pelos utilizadores nos diferentes períodos do dia. Por último, no gráfico da Fig. 4 podemos observar a dinâmica da vida de Beijing através da observação da movimentação e velocidade dos utilizadores distribuída pelas diferentes horas do dia. 139

154 Tabela 2. Tempo passado nos pontos de estadia mais pupulares Figura 4. Movimentação por períodos do dia 5 Conclusão e Trabalho Futuro Neste artigo foi apresentada a conceção de um Data Warehouse Espácio-Temporal orientado para análise de dados de trajetórias de utilizadores. O modelo proposto apresenta uma caracterização semântica dos registos, quer a nível de utilizadores e movimento dos mesmos, geográfico, temporal, quer ainda a nível técnico de captura dos registos. Foi ainda desenvolvido no processo ETL, algoritmos para caracterização de trajetórias, extração de pontos de estadia e a sua categorização e divisão de localizações da região abrangida. A experimentação do modelo permitiu validar a sua utilidade na realização de pesquisas que poderá potenciar tarefas de planeamento urbano e análise de movimentação dos utilizadores. Como trabalho futuro, pretende-se criar um algoritmo que permite agrupar utilizadores semelhantes com base nos seus pontos de estadia e localizações frequentadas. Outro objetivo, será utilizar um outro conjunto de dados (e.g., referente à mobilidade de utilizadores nacionais), que permita obter mais informação a nível de pontos de estadia e tenha informações demográficas sobre os utilizadores, de modo a realizar-se análises de perfil mais enriquecidas, tal como a utilização de técnicas de prospeção de dados. 140

155 Agradecimentos O trabalho apresentado neste artigo foi suportado pela FCT (Fundação para a Ciência e Tecnologia) através do Projeto Estratégico da Unidade LaSIGE, ref a PEst-OE/EEI/UI0408/2011, e do projeto de investigação SInteliGIS, ref a PTDC/EIA-EIA/109840/2009. Referências 1. Dodge, S., Weibel, R., Lautenschütz, A.K.: Towards a taxonomy of movement patterns. Information Visualization (June 2008) Kimball, R., Ross, M.: The Data Warehouse Toolkit. 2nd edn. John Wiley & Sons, Inc., NY, USA (2002) 3. Giannotti, F., Pedreschi, D.: Mobility, Data Mining and Privacy: Geographic Knowledge Discovery. 1 edn. Springer Publishing Company, Incorporated (2008) 4. Kimball, R., Caserta, J.: The Data Warehouse ETL Toolkit. John Wiley & Sons (2004) 5. Braz, F., Orlando, S., Orsini, R., Raffaeta, A., Roncato, A., Silvestri, C.: Approximate aggregations in trajectory data warehouses. In: Proc. of the 2007 IEEE 23rd Int. Conf. on Data Engineering Workshop, DC, USA, IEEE Computer Society (2007) Spaccapietra, S., Parent, C., Damiani, M.L., de Macedo, J.A., Porto, F., Vangenot, C.: A conceptual view on trajectories. Data Knowl. Eng. 65(1) (April 2008) Marketos, G., Frentzos, E., Ntoutsi, I., Pelekis, N., Raffaetà, A., Theodoridis, Y.: Building real-world trajectory warehouses. In: Proc. of the Seventh ACM Int. Workshop on Data Engineering for Wireless and Mobile Access, NY, USA, ACM (2008) Almeida, C.: Data warehouse de trajetórias: um modelo semântico com suporte à agregação por direção dos movimentos. Master s thesis, Universidade Federal de Campina Grande, Campina Grande, Paraíba, Brasil (2010) 9. Zheng, Y., Li, Q., Chen, Y., Xie, X., Ma, W.Y.: Understanding mobility based on gps data. In: Proc. of the 10th Int. Conf. on Ubiquitous computing, NY, USA, ACM (2008) Sinnott, R.W.: Virtues of the Haversine. Sky and telescope (1984) Husson, F., Lê, S., Pagès, J.: Exploratory Multivariate Analysis by Example Using R. A Chapman & Hall book. CRC Press (2011) 12. Han, J.: Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA (2005) 13. Deza, M.M., Deza, E.: Encyclopedia of Distances. 1 edn. Springer (August 2009) 14. Li, Q., Zheng, Y., Xie, X., Chen, Y., Liu, W., Ma, W.Y.: Mining user similarity based on location history. In: Proc. of the 16th ACM SIGSPATIAL Int. Conf. on Advances in geographic information systems, NY, USA, ACM (2008) Zheng, Y., Zhou, X., eds.: Computing with Spatial Trajectories. Springer (2011) 16. Zheng, Y.: User Guide Geolife Dataset. Microsoft Research Asia. Version 1.3 edn. 17. MacLennan, J., Tang, Z., Crivat, B.: Data Mining with Microsoft SQL Server Wiley Publishing (2008) 18. Ferrari, A., Russo, M.: The many-to-many revolution advanced dimensional modeling with microsoft sql server analysis services. (2011) 141

156 Segurança de Sistemas de Computadores e Comunicações 142

157 Improving Intrusion Detection Systems by means of Knowledge Sharing based on Social Networks Amir Azhdari, Edmundo Monteiro Department of Engineering Informatics University of Coimbra, Portugal {amir, Abstract. This paper proposes a new approach to security protection to detect intrusions, particularly in the field of distributed intrusion detection systems (DIDS). There has recently been a rapid increase in the use of knowledge sharing-based social networks, such as Facebook, and the presence and social impact of these pervasive networks is overwhelming. In the light of this, the proposed approach is based on the combination of an intrusion detection system (IDS) with a social network that relies on knowledge sharing to detect intrusions. In this study, the opportunity for knowledge sharing is provided by applying a distributed architecture based on a social network. The proposed approach involves intrusion detection systems as simulated nodes. The achieved results suggest there has been an improvement in some characteristics such as extensibility and tolerance. Moreover, it is able to eliminate some shortcomings such as failures and restrictions on the type of intrusion detection systems that are employed. Furthermore, the proposed system - social network intrusion detection system (SNIDS) - has been integrated into two open source intrusion detection systems: Snort and Bro. In addition, the application of the SNIDS in the DARPA 2000 dataset has proved the effectiveness and efficiency of the proposed approach. Keywords: Social network, IDS, knowledge sharing. 1 Introduction The rapid growth of the Internet has led to an increase in security problems. In addition, attack technologies have begun employing more complex methods, like coordinated attacks. In these circumstances, there is an increased need for software tools that can automatically detect a wide range of intrusions. Precautionary network intrusion detection systems should be able to detect attack and defend computer systems in a very short time [5]. Intrusion detection is an indispensable tool for monitoring and analyzing events in a computer or network so that it can protect it against attacks. Generally, systems that detect intrusion can be classified as host based, network based and distributed based. Host-based intrusion detection (HIDS) and networkbased intrusion detection (NIDS) are considered to be the main kinds of intrusion detection systems in this area. The combination of information from network intranet 143

158 and entire host and network-based intrusion detection systems, create a distributed intrusion detection system (DIDS). The components of the intrusion detection system are distributed in different ways. The reason for this is to enhance the safety, tolerance and distribution of the traffic load of components such as sensors, intrusion detection systems, or even logging and allow an analysis to be conducted of the different components of a single network or several networks. Currently, in distributed IDS systems, such as GrIDS [13][4], DIDS [6], AAFID [1], EMERALD [11] or systems based on mobile agents [8], the analyzer is distributed between different parts of the network. Moreover, in other distributed IDS systems such as [16] or in IDSIPS [14][10] the sensor and logger is distributed between different parts of the network. The proposed architecture can be added as a supplement to each of these types of systems, and enable new knowledge sharing to be carried out among the intrusion detection systems. In other words, the proposed architectures are used beyond the level of intrusion detection systems for communication between them. The advantages of using this system together with existing systems include the following: they widen the range of knowledge-based detection, make it possible to employ different algorithms to acquire new knowledge, eliminate points of failure, and provide infinite extensibility to the capabilities of the heterogeneous intrusion detection systems. The rest of this paper is structured as follows: Section 2 describes related studies on knowledge sharing in intrusion detection systems. Section 3 discusses the statement of the problem and proposed methodology with the tools used. Section 4 makes a comparison between our proposed system and other similar systems on the basis of the results of our experiments and the final section brings the study to a conclusion and recommends areas for future research. 2 Related work In what follows, we briefly describe knowledge sharing in the field of intrusion detection systems, and interaction with various topics such as distributed systems, interactive distributed systems, sharing information, and other listed items. Tao Peng and his colleagues have prepared an article with the title The subscription model for distributed systems"[16]. In this model, statistics are collated by means of a compression algorithm, in which a machine learning approach is adopted to coordinate shared data among distributed detection systems. The main problem with employing this model construction coordinator (as a focusing device) is that it is a bottleneck addition, and there will be single point of failure. The model is made more vulnerable by the coordination mechanism. In fact SNIDS system has no central control and is an intrusion detection device which decides on intrusions on an individual basis and at a local level and uses the social networks for sharing knowledge with friends. In [14], two models have been proposed for the homogeneous and heterogeneous integration of an intrusion detection system. In the model of direct integration, this is 144

159 carried out with a single console, and through multi-system management and monitoring. The system can interact by means of its data sharing but indirect integration is achieved by using security information and event management software (SIEM). The procedure is to collecting all the data from various log and then correlations and coordinating between them via SIEM. In the first model, however, the management console is weakened but it is difficult to focus as an observer service since it is more susceptible to damage. Another problem, which has been mentioned by the authors, is that there is a lack of cooperation between the information sharing systems. In the second model, the problems posed in [16] still exist. In SNIDS there is no node which is responsible for synchronization and there are no restrictions on the type of intrusion detection system employed. Geetha, Delbert [18] introduced a decentralized intrusion detection system, which is a virtual neighborhood network where every neighborhood is responsible for taking care of each other, by using penetrating observation, and feedback to tell other networks they can be collected. Each site is sent mobile agents to its neighbors and for review in a specific time period. However, in this model there is no central controller, and there are differences in the social networks which are, first, in the way they respond to the effective way in which the model collects feedback and the conclusion is done by voting. However, although this provides greater accuracy in the analysis, there is a significant reduction in speed. In addition, this model does not include any form of knowledge sharing or knowledge gathering about intrusions into the system itself, and depends on the help of others for decision-making. 3 Methodology and the proposed system One of the new methods of knowledge sharing is to make use of a social network model [3]. As the name implies, it is a system based on the functional nature of the social networks and involves adopting a collaborative approach. In this study, an improved SNIDS is proposed which consists of the system s components and relationships. 3.1 Components of an intrusion detection system Figure 1 shows a schematic view of an intrusion detection system and the necessary components displayed for each node. Since all the components of intrusion detection systems are similar, our aim is to explain the effectiveness of the proposed system. Relationship: The relationship is responsible for the task of exchanging knowledge with other nodes in the social network. This is part of the exchange protocol. The knowledge that is published by other nodes is received by this component; then following this, the mapping operation is carried out internally within the framework of the protocol. As a result, knowledge is perceived by the local intrusion detection system, and this knowledge is made available for a single decision with regard to local learning. On the other hand, after receiving the knowledge about the constituent units that is derived from local knowledge, it will conduct the coordination procedure 145

160 necessary for converting data from an internal format to the format protocol and publishing it. Local Learning: In intrusion detection systems for local learning, new intrusion detection models are added to the knowledge base. This task is performed in the SNIDS system by the local Learning. This component consists of two processing units, and the decision part. The task of the processing unit is to analyze data on the Logger to discover new patterns. These patterns are added to the knowledge base with the help of the decision unit. As well as receiving input from the processing unit that works as an engine of local knowledge, the decision unit also receives knowledge about the known influences of communication units and this knowledge is shared with others in the network intrusion detection system. This decision-making unit decides on how to add this knowledge and conveys it to a knowledge base, if the new knowledge has to be added to it. Fig. 1. Components of intrusion detection system as a node in a social network 3.2 Protocol to communicate with neighbors A standard format is included for intrusion detection systems with regard to the proposed system [9]. In a relationship unit of knowledge, the action takes place by means of mapping knowledge of the network intrusion detection system to the standard form and vice versa. As shown in Figure 2, this component comprises three main parts: the input units, output units, and message box. The Input Unit: The data is received by the input unit for a specific protocol message from a particular address in a social network. The message will be sent after a match has been received. The received message which has been sent to the standard network format will be converted into a message through the format of the local intrusion detection system. Appropriate descriptive data and information that has been 146

161 received will be added to the endpoint. Finally, the message is transferred to the message box. Fig. 2. Internal components of exchange of Knowledge The Output Unit: The send converter is in the output unit. Messages in local format are converted to standard network format in this unit and will then be sent to other nodes (intrusion detection systems) from the agreed port. The general formats for the exchange of known messages are as follows: Name: these fields are defined by a signature. Ids: the name of the intrusion detection system in the social network. Precedence: is a numerical sign indicating the priority status of the knowledge base. Pattern: is the stored value in the token parameter which is used to adapt the network packets. At least one model for each sign is mandatory. A defined format is used for the signature pattern in the Snort [12] system, where each sign contains the "header" and "option. The first part contains information that shows the occurrence of any inconsistent and suspicious signs in any network, at any place, and suggests what kind of package should be examined and what action should be taken against the suspected activity. The second section includes a range of options to detect intrusions in the network and alarm system. Frequency: this is the number of packets matching the measured range; it shows the amount of time required to sign an action that has to be performed. This depends on how many measurements will be consistent with the model. Interval: the frequency of the signal specifies the time for compliance time. The default value is 1 second. Quiet: the value of this sign determines the amount of time the target of the sensors will not receive any close matches to the signature. It can be concluded that the attack has subsided with the signature. The zero value for the frequency will cause these signs to be ignored. Action: this clarifies the operation of the agreement signed by the intrusion detection system. This action will consist of a single report or no value. Desc: this field specifies the purpose of the sign. 147

162 Figure 3 shows the purpose of the descriptive details that are sent with signature patterns to provide supplementary information about the condition and performance of the systems with the signed message. This information will help the destination system to make a better decision. Fig. 3. General formats for the exchange of known messages <?xml version= 1.0 encoding= utf-8?> <SignaturePattern xmlns=http://www.ids.com/social/signature> <Signature ids= name= version= precedence= frequency= interval= quiet= action= desc= > <patterns> <pattern>pattern 1 context</pattern> <pattern>pattern 2 context</pattern> <pattern>pattern N context</pattern> </pattern> </signature> The Message box: A message box is always an active component. All the received </SignaturePattern> and sent messages are stored in it. The message box sends the new messages to the send converter in the output unit. As we have suggested, the standard format has been adapted from the model displayed in [15] for the configuring signatures of Cisco wireless controllers in intrusion detection systems. 3.3 Social network services In this section, we describe the context of the social networking service that is based on knowledge sharing, which has been outlined in this study. Membership: before someone can join the network, the intrusion detection system must first be developed internally to enable the person to share his/her knowledge with others. After the internal development has been established, the person can receive invitations to join the network and becomes a member of the network. If he wants to become a member of the network independently and without an invitation, this can be carried out by sending the primary information to the social network server. It should be noted that the central server is not responsible for the quality of the system or its performance. At the time of the membership every system has to accept all the conditions. Thus, when the central server and terms of the networks have been accepted by the applicant, the membership is confirmed and the system will assign a unique identifier to a network address of the proposed model so that the intrusion detection system can protect it. Profile: this involves creating profiles that often occur at the same time as the registration process. Each system is required to provide information about the characteristics and structure. This information contains different levels of accessibility to social networks services (public, between friends and private). The purpose of this information is to allow the system to be recognized by other nodes and make it possible to establish a friendly relationship. The information will include the following: the ad- 148

163 dress of the host intrusion detection system, the city, State, and starting date of the activity on the web, the architecture of the intrusion detection system, the risks to the network, whether the network is a local network, and the number of active network intrusion detection systems. These data are kept as a profile of the intrusion detection system in the social network service. Dating: after obtaining membership and completing the profile, the next step is to select friends and share knowledge with them. When the membership has been confirmed and the profile systems established, the network services that are based on the profile information offer some similar nodes for friendship. If you have some friends who have already joined the social network, the system will offer them as new friends and suggest how you can add them to your list. The social network structure is formed in this way. 3.4 Knowledge exchange methods in the network After creating a network through a proposed mechanism, (the Friends Finder discussed in the last section), it is time to share the knowledge. Here we provide two methods for knowledge transfer between the nodes. Method 1. Post without permission in this model, after establishing friendship with another node, each node sends all the knowledge it has that is based on its network protocol. After a friendly relationship has been formed between two nodes and if the method uses "post without permission", each node can immediately send any knowledge information that has not yet been sent. Method 2. Selective nodes in this method, after the registration has been completed, each node in the network converts all its knowledge into a standard network format and defines the level of accessing for its friend. After this, it proceeds to dating and friendship procedures. Friends can check for the shared knowledge and decide if they wish to select some of them so that they can be transferred into their own local knowledge base. 3.5 Updating mechanism In social network intrusion detection systems, any [intrusion detection] system can share its knowledge base with other intrusion detection systems on the basis of common definitions and methods in social networks through messaging. Thus, whenever new knowledge is added to the knowledge base, it converts it into the standard architecture and sends it to its other friends. The friends also get to know each other by checking their message box for the new knowledge. To prevent loops, each node can only send each item of knowledge. Thus, any new knowledge that is created through this social network can be shared with other systems. 149

164 4 Evaluation and experiment results SNIDS systems have been evaluated in two ways. We compared the characteristics of the system with other systems based on knowledge sharing and used simulation to assess the impact of social networks on the performance of intrusion detection systems. 4.1 Comparisons of features with similar systems In Table 1, SNIDS systems are compared on the basis of several features and this shows that the common intrusion detection systems are more important than other existing systems based on knowledge sharing. This comparison also shows that the system has addressed the SNIDS problems found in other systems. Table 1. Comparison of the proposed model with intrusion detection system based on other sharing knowledge Architecture Sharing model for distributed systems[16] Integration of detection and protection system[14] Criterion Variation in IDS Network coverage Single point failed Central Controller Type of Decision NO Organizational YES YES Local YES Organizational YES YES Local Virtual neighborhood network[18] NO Cross NO NO Vote SNIDS YES Internet NO NO Local Methods of assessment Assessment methods introduced in [17] are used to evaluate the intrusion detection system, and consist of tcpdump files which are used in seven weeks of training with data from DARPA2000 [7]. Each file is given to the intrusion detection system as an input file (Snort, Bro [2]). These systems are configured in such a way that allows all the preprocessor and conditions to be fulfilled. An alert file is created for each tcpdump file. Using a supplementary program file, the alarm file is matched with an attack list in the tcpdump file. A matching involves matching IP and port number or ICMP type/code. In this way, it will distinguish the appropriate warnings from the wrong cases. After matching all the attacks and warned files, the supplementary program counts the number of positive errors for each rule and negative errors for each type of attack. After this, the list of positive errors is filtered to remove duplicate items. Finally, an additional supplementary file is used to calculate the following 150

165 measurements. The formulas below are used to obtain the Overall Accuracy (See 1), False Positive Rate (See 2) and Detection Rate (See 3). ( ) (1) ( ) (2) ( ) (3) True positive (TP) = correctly identified False positive (FP) = incorrectly identified True negative (TN) = correctly rejected False negative (FN) = incorrectly rejected 4.3 Experimental results In this section, we studied the SNIDS system to improve the system s performance by means of simulation and considering the parameters for various cases. The results of this study as shown in Figure 4, employ 10 -fold cross validation methods for the test, so that accurate results can be obtained. These followed parameters which influence the evaluation of these systems such as, the number of nodes (intrusion detection systems), distribution period, network connections, type of connection (unilateral or bilateral), the kind of knowledge distribution among neighbors (the neighbors with more links, the least shared friends of the neighbor, and a combination of both), the impact of a connectivity topology (degree of dissociation graphs), and the number of overlapping nodes that have been used to estimate the performance of the values in Table 2. Parameter Table 2. Parameter values in evaluating Number of nodes 15 Interval distribution Total Knowledge in Network Maximum message exchangeable How to Network Connections Type of Relationship The way of knowledge distribution among neighbors Dissociation degree of the graph 1 5 mili/second Value A total of 72 rules for Snort and Bro 1 Message Random 15% unilateral and other are bilateral Combined The amount of overlap nodes 20 % First of all, the system will be determined by the set of parameter values and a Snort node type is chosen to determine its effect on the performance of knowledge sharing. 151

166 Following this, after 8 separate iterations, the system status will store the data and will then be evaluated by means of the method described. Several modes that have been studied which can be listed as follows: 1- All nodes base of Snort with different and distinct kinds of knowledge. 2- All nodes base of Bro with different and distinct knowledge. 3- A wide-ranging Snort base with an overlapping knowledge base. 4- Several different Snort and Bro modes with different and distinct knowledge bases. 5- Several different Snort and Bro modes with an overlapping knowledge base. As is shown in Figure 4, the comparison of the 4th and 5th with the first three modes is determined by employing only one type of intrusion detection system. A greater degree of accuracy is obtained in the diagnosis by increasing the range of the type of network intrusion detection system. This can also be achieved by comparing the 4th and 5th modes. If there is an overlap between the nodes in the first iteration, it can be accurately detected by measuring a slow growth caused by the frequent exchange of knowledge. Fig. 4. IDS performance evaluation in social networks. X-axis presents the number of iterations and Y-axis is the value of the Overall Accuracy. Fig. 5. SNIDS Comparison detection models in a diverse setting 152

167 The Receiver Operating Characteristic (ROC) curve is normally used to measure intrusion detection performance. The ROC curve displays the detection rate changes are diverse to produce more or fewer false alarms. Indeed it is a plot of the true positive probability against the false positive rate for the intrusion detection accuracy. Figure 5 shows the ROC curves of the detection models by attack types for all intrusions. In Figure 5, the x-axis is the false rate, the percentage of normal and abnormal classified connection is calculated; the y-axis is the detection rate, as percentage of intrusion detection. We compare the SNIDS of the detection models with sharing model for distributed system [16] and integration of detection and protection system [14] in DARPA datasets evaluation program. We can see from the Figure 5 that our detection model outperformed the others. 5 Conclusion and Future Works The comparison is shown in Table 1. In the proposed architecture, the problems (such as Single Point Failed Failure and Central Controller) have been solved in this system and the scope, coverage and implementation of the system have been expanded. However, a local decision system is retained, which is one of the advantages of the SNIDS system. The aim of designing the SNIDS system is to provide architecture for knowledge sharing in intrusion detection systems. This system can be used to supplement existing intrusion detection systems for any type of architecture and provides an opportunity to share knowledge among various types of systems. As the results show, the proposed system can improve efficiency by identifying intrusions with the aid of an intrusion detection system. Obviously, better results could be obtained if we had a wider range of shared knowledge. Research activities for future work can continue to analyze the effect of various parameters on the performance of the system so that it can derive optimum efficiency and refine the knowledge that is based on shared experiences. Another important area that requires investigation is the question of how to prevent the spread of false knowledge in social networks and protect member network systems against hackers. Acknowledgement This work is supported by CoFIMOM project PTDC/EIA-EIA/116173/2009. References 1. Balasubramaniyan, J., Garcia-Fernandez, J., Isacoff, D., Spafford, E., & Zamboni, D. (1998, dec). An architecture for intrusion detection using autonomous agents. Computer Security Applications Conference, Proceedings. 14th Annual, (pp ). 153

168 2. Chen, B., Lee, J., & Wu, A. (2006, april). Active event correlation in Bro IDS to detect multi-stage attacks. Information Assurance, IWIA Fourth IEEE International Workshop on, (pp. 16 pp. -50). 3. Fung, C., Zhu, Q., Boutaba, R., & Ba\c{s}ar, T. (2011). SMURFEN: a system framework for rule sharing collaborative intrusion detection. Proceedings of the 7th International Conference on Network and Services Management (pp ). Laxenburg, Austria, 4. gentschen Felde, N. H. (2012). A GridBased Intrusion Detection System (GIDS). 18th EUNIS Congress,. 5. K. Alsubhi, Y. A., & Boutaba, R. (August 2012). Security Configuration Management for Intrusion Detection and Prevention Systems. International Journal of Security and Networks (IJSN), 7(1), Karolina Jelen, P. K. (2008). Multiagent Approach to Autonomous Reorganization of Monitoring Task Delegation in Distributed IDS,. Springer Berlin Heidelberg, 134, pp Lippmann, R., Fried, D., Graf, I., Haines, J., Kendall, K., McClung, D.,... Zissman, M. (2000). Evaluating intrusion detection systems: the 1998 DARPA off-line intrusion detection evaluation. DARPA Information Survivability Conference and Exposition, DISCEX '00. Proceedings, 2, pp vol Mo, Y., Ma, Y., & Xu, L. (2008, dec.). Design and implementation of intrusion detection based on mobile agents. IT in Medicine and Education, ITME IEEE International Symposium on, (pp ). 9. Moura, G., Sadre, R., Sperotto, A., & Pras, A. (2012, april). Internet bad neighborhoods aggregation. Network Operations and Management Symposium (NOMS), 2012 IEEE, (pp ). 10. Peddycord, I. B., Ning, P., & Jajodia, S. (2012). On the accurate identification of network service dependencies in distributed systems. Proceedings of the 26th international conference on Large Installation System Administration: strategies, tools, and techniques (pp ). Berkeley, CA, USA. 11. Porras, P. A., & Neumann, P. G. (1997, October). {EMERALD:} {E}vent Monitoring Enabling Responses to Anomalous Live Disturbances. Proceedings of the 1997 National Information Systems Security Conference (NISSC), (pp ). 12. Roesch, M., & Green, f. w. (n.d.)..snort Rules,http://www.snort.org/. unpublished. 13. S. Staniford-Chen, S. C., & Zerkle, D. (1996). GrIDS.a graph based intrusion detection system for large networks. 19th National Information Systems Security Conference. 14. Scarfone, K., & Mell, P. (2010). Intrusion Detection and Prevention Systems. In P. Stavroulakis, & M. Stamp (Eds.), Handbook of Information and Communication Security (pp ). Springer Berlin Heidelberg. 15. Systems, Cisco. (2007). Wireless LAN Controller IDS Signature Parameters,. 16. Tao Peng, C. L. (2007). Information sharing for distributed intrusion detection systems. Journal of Network and Computer Applications, 30, Terry, S., & Chow, B. J. (2005). An Assessment of the DARPA IDS Evaluation Dataset Using Snort. An Assessment of the DARPA IDS Evaluation Dataset Using Snort. 18. Ye, D., Bai, Q., Zhang, M., & Ye, Z. (2008, may). P2P Distributed Intrusion Detections by Using Mobile Agents. Computer and Information Science, ICIS 08. Seventh IEEE/ACIS International Conference on, (pp ). 154

169 Biometric and Behavioural Identification of Users in Intrusion Scenarios Henrique Martins 1,2, Ricardo Azevedo 1, Paulo Novais 2, and Ângelo Costa2 1 PT Inovação SA, Aveiro, Portugal 2 Department of Informatics, University of Minho, Braga, Portugal Abstract. A strong authentication system is crucial in organizations today, as they have confidential resources that must be protected from external and internal threats. The users identity is not secure by the current authentication methods. Passwords are easily forgotten or shared, tokens can be duplicated and stolen, and physiological biometrics can be intrusive and require the purchase of expensive devices. The authentication phase is critical, but threats are not limited to this phase. The period between login and logoff is not monitored, i.e., it is assumed that the authenticated user is the one that uses the session all the time. But sometimes that s not true. In this paper we present a solution to reinforce the current authentication and intrusion detection systems, helping them by verifying the behavioural profiles of the accounts owner. This system will not require extra costs, since only the available hardware is used, and will be completely invisible to the user, as he will be authenticated and verified in a completely silent and unobtrusive way. Keywords: Identity Theft, User Authentication, Computer Security, Intrusion Detection, Behavioural Biometrics, Keystroke Dynamics, Mouse Dynamics 1 Introduction Session hijacking and identity theft are becoming common problems in computer systems. With the growing usage of online services, people become more exposed to different techniques, technological or social, that can be used to access their personal accounts, from services such as s, Facebook, bank accounts, among others. Currently, the dominant method of authentication is the combination of username and password. This method can be unreliable, because these credentials can be shared, forgotten or stolen. To offer better authentication mechanisms, other techniques are used; two of them are the tokens or digital certificates and biometrics. None of them completely solve the problem as they can be duplicated or stolen. Moreover the physiological biometrics (fingerprint, iris, retina, hand 155

170 geometry, etc.) are intrusive and require the purchase of expensive equipment that may not work in all the scenarios. The way we behave and act in a computer can be used as biometric information. This information supplemented with more data (i.e. contextual data) can be used to identify unequivocally (or at least with a certain degree of confidence) an individual. The information collected may vary from the way of typing on a keyboard (keystroke dynamics [11]), skill with the mouse (mouse dynamics [1]), habits, clicks, number of pages open, source access, etc., which will then be subject to the use of behavioural algorithms to identify and authenticate, unequivocally, the user. In this work we present the implementation of a system that strengthens the existing authentication and intrusion detection systems, helping them by verifying behavioural profiles of the account owner, resorting only basic hardware. Additionally, it will be completely transparent to the user, i.e., it will be working in an unobtrusive way, collecting data in background. The aim of this paper is to present a system capable of recognizing biometric patterns and, through behavioural algorithms and complex event processing, create user profiles that are used to identify and ensure authentication to services. 2 Behavioural Biometrics and Intrusion Detection The intrusion detection systems are mainly based on two approaches: knowledge or behaviour. In this paper our focus is on intrusion detection based on behaviour. Currently, there a few tools that implement this approach, although Denning [6] stated that this type of approach is an important requirement for an intrusion detection system (IDS). Intrusion detection systems based on behaviour techniques assumes that an intrusion can be detected by observing a deviation from a normal or expected behaviour of the system or the users. The normal behaviour model is obtained from the information gathered through various means. The intrusion detector then compares this model with the current activity and whether a deviation is observed, an alarm is triggered. This means that any activity that does not match a learnt behaviour is considered as a potential intrusion. This approach has the advantage of detecting intrusion attempts and unforeseen vulnerabilities, being able to contribute to the automatic discovery of new attacks. Behavioural biometrics are also less dependent on the operating systems security mechanisms, thus helping to detect abuse of privileges attacks that do not convey any specific vulnerability. In short, this approach may be summarised in one sentence: Everything that has not been seen before is a threat [5]. The high rate of false positives is considered as a significant drawback of the behaviour based techniques because the profile may not be complete after the learning phase. In addition, the behaviours may vary with time causing the need for periodic training. Behavioural biometrics [16] has the potential to verify users based on their interaction with the computer, mostly through the keyboard and mouse. There 156

171 are several scenarios in which Behavioural Biometrics can be used in computers [14]: Log-in Verification: Whenever the user logs to his local station or to a service on the intranet or internet by typing a user-name and password - these are monitored and verified. Continuous Verification: After the user performs a successful login to the computer or to the web service, his entire interaction, through keyboard, mouse activities are continuously monitored to verify that the user is legitimate. For the evaluation of biometric systems we will be using two measures: Type I error, which is the rate a legitimate user is rejected by the biometric system, and Type II error, which is the rate an imposter that is accepted by the biometric method. 2.1 Techniques The system presented within this paper is based on mouse and keystroke dynamics, which represent two separate but related behavioural biometrics. These techniques are described in the following paragraphs. Keystroke Dynamics Keystroke dynamics can be captured via several different features extracted from the typing rhythm of the user including: latency between consecutive keystrokes, flight time, dwell time, overall typing speed, frequency of errors (use of backspace) and control keys (use of left/right shift) [14] [11]. Systems of this kind do not necessarily employ all of these features; most of the applications measure latencies and dwell time only. Features like keystroke sequences are often used for long texts verification, being typically extracted based on di-graph, tri-graph or (more generally) n-graph segments of the entire text. In these, the latencies, intervals and flight time are measured for each sequence of keystrokes. Verification methods are dedicated to verify users based on fixed or variable text inputs. This latter method can be used in order to verify users continuously [14]. Generally, typing pattern solutions can be divided in analyse the user behaviour during an initial login attempt and determine the authentication state of a user permanently. Haider et al. [10] measure the delay between key presses that are then processed in three distinct classification algorithms - fuzzy logic, neural networks and statistics - in order to discriminate between the user and an imposter. Combining both algorithms they achieved a Type I error of approximately 2% and Type II error of 6%. Bergadano et al. [3] proposed to use relative duration times of n-graphs instead of absolute ones. That means, the graphs were sorted by their duration and then the distance between the single graphs is calculated and compared to other users typing samples generated n-graphs. This work achieved a type I error of 4% and type II error of 0.01%. Ferreira et al. [7] uses a similar approach but applicable to free text and therefore to enable continuous authentication. 157

172 Mouse Dynamics Exploiting mouse activities for user verification is a more complex approach. The pioneer and most comprehensive study to our knowledge was carried out by Ahmed et al [1]. The study defines four different mouse actions as follows: mouse movement, drag and drop, point and click and silence. Several different features were defined, such as the interpolation between the movement speed and the travelled distance, which estimates the average speed a user will travel for a certain distance. In addition, several histograms were used to capture different working statistics of the user such as the average travelling speed in eight direction zones or the relative occurrence of each one action. This study showed relatively good results of less than 3.29% Type I error and less than 0.5% Type II error, when the number of actions was greater than 2,000 and the verification session last for minutes on average. Nevertheless it showed relatively poor results of less than 24% Type I error and 4.6% Type II error when the session was of a shorter duration (above 4 minutes). Pusara and Brodley [15] attempted to uniquely partition users according to their mouse movement behaviour. They calculated the mean, standard deviation and the third moment of the distance, angle and speed between different two adjacent points, when a defined window of data points is considered. A decision tree classifier was trained to differentiate among users activity. Gamboa and Fred [8] [9] consider features such as the angle, curvature, horizontal, vertical and combined velocity, acceleration and jerk obtained from a vector of data points that were intercepted between two mouse clicks in a web memory game. The authors evaluated the use of two statistical models with the use of the extracted features to verify the identity of an individual. 3 Intrusion Detection System Model We present an architecture for intrusion detection. It is based on the keystroke dynamics and mouse dynamics techniques, being the rest of the methods used to fine tune or extend the features according to the operating system or user interaction. The final result, being an application, has two main goals: to ensure identity verification and continuous authentication of the users. Also, the main focus of this work is to authenticate the users in a transparent way and without changing their flow of interaction. In terms of architecture this project consists in a two phase verification methods. The first phase strengths the common security methods (username and password) present in a web page. Additionally, through the use of keystroke dynamics it is intended to verify if the person who is authenticating is the real owner of that account. The second phase only applies after the user s successful authentication. The verification algorithm will confirm if the authenticated person corresponds to the actual user. This algorithm will mainly use techniques such as keystroke dynamics and mouse dynamics, with the objective to identify masked intruders or internal users using accounts previously authenticated by others. 158

173 3.1 Static Authentication System In this section is showed the authentication system developed using the keystroke dynamics technique. This is a traditional authentication system, were the user inserts, in the authentication portal, his/her username and password. The major difference to the common process is that the user is authenticated not only with the combination username and password but also if the writing pattern is equal to the user profile. Fig. 1. Authentication process flow chart. To build a writing pattern, keyboard events (key press and key release) are monitored to construct the profile metrics according to the user behaviour. At the data collection stage only events that involve typing are registered. All others, like function keys or special keys are ignored. Once the data is collected it is evaluated according to the following metrics: Dwell time: total time that a key is pressed; Digraph: time between a key pressed and the following key being released; Speed: total time taken to write the username and password, measured the time taken from the first key press and the last interaction; Transitions: use of the Tab key or the mouse to cycle trough the text boxes; Capitals: the use of Shift or Caps Lock to change the type. The user profile is built through the first fifteen sessions. Thereafter the algorithm enters the detection mode which only returns true (i.e. successfully authenticated) if the input provided ensures its identity. The Figure 1 provides a flowchart perspective of the authentication process. The user inserts his credentials, and the system verifies the typing pattern of the text inserted in order to verify the real identity of the user. If authentication is allowed then an adaptive algorithm [13] is used to monitor the user, thus, it is 159

174 able to adapt the user profile according to its behaviour. Whenever there is a correct authentication the profile and authentication markers are updated. The adaptive algorithm is an important aspect once it guarantees that the profile is updated according to users behavioural changes (i.e. if a physically disability happens the users behaviour may change and the algorithm will adapt to the change, after a short period of time). 3.2 Continuous Authentication System The common sense lead us to consider that the intrusions only happen when there is no one logged in, but much of the corporate threat is based on users close to the victim [7]. With this in mind, not only it is required that the intrusion is detected upon the login as well as during the use of the system. The continuous authentication system was developed taking these problems into consideration, by providing a method to detect abnormal user patterns. This is done by monitoring the user s mouse and keyboard interactions, and with this information inferring if an intrusion is happening. Fig. 2. Continuous authentication system process. The Figure 2 presents an overview of the system. All the user interaction with mouse and keyboard is captured, cleaned (due to the huge amount of mouse data) and processed. Then this data is classified in the same way as 3.1, where a correct identification leads to a user profile update and an incorrect identification ends in a access deny. The data from the keyboard and mouse can be combined, therefore data fusion can be achieved, obtaining accurate results. But the methods used to capture data from each input are very different. The following sections present monitoring methodologies used. 160

175 Keyboard Monitoring The keyboard monitoring system collects the keyboard data, removes the special keys from the set, and implements an algorithm slightly different than the one presented before. Now, the system must be able to classify continuous and free text. This means that the paradigm has changed and evolved from a fixed and expectable number of interactions to a variable one (although it relies on a minimal set of letters). The metrics used are: Pressure time: inherited from the previous system; Word latency: the latency values of every combination possible between the letters of a word are tested, leading to an n-graph. The Table 1 presents the latency calculation between each letter of the word TESE. To each key is presented the time taken between the press and release actions, and the relation to the next key (latency). Hence, the system reads the relation between the remaining keys, as it can be seen, each key relates to the next in a different way. Table 1. N-graph TESE example. Keystrokes Digraph Trigraph Tetragraph Key Pressed Released Graph Latency Graph Latency Graph Latency T T + E 187 T + E + S 358 T + E + S + E 510 E E + S 295 E + S + E 447 S S + E 245 E The learning phase is concluded in the first fifteen user sessions. Henceforth the adaptation algorithm is used, being each session constituted of 250 characters. In order to complement and enhance the efficiency of the system, another method was added, mouse monitoring. In this way the process of detection is improved and external conditionings, as the writing position or writing with only one hand, are corrected using an unbiased and separate method. The combined methods provide a more accurate result, therefore a more secure system. Mouse Monitoring The data is obtained from the mouse movement and clicking [1], resulting in the combination of all possible gestures. The data blocks are transmitted every 100 milliseconds and are constituted of the following actions: Silence: absence of movement; Movement: movement; Point and click: movement followed by a click or double click; Drag and drop: movement while clicking pressed followed by the button released. Commonly, each application has a different interface, being each action presented in a unique place of the screen. The mouse movement is correlated with 161

176 the screen size to calculate the distance. Thus, due to the work-flow of the applications that the user operates it is obtained different patterns of usage. To overcome this problem, each application has its own profile. This method provides a more accurate result than a general capture. For instance, writing a document has a mouse pattern that is very distinct from drawing an image. Due to the considerable amount of data collected, the data is filtered of its outliers with an interquartile range function. Specifically, the outliers can be reading errors of the mouse, interpretation errors or behaviour without any specific meaning. After the use of the filter function the 25% of the values were cleaned, therefore, the efficiency and precision increased. The following items demonstrate the data obtained over a user session: Speed of the movement compared with distance; Movement direction; Speed of the movement compared with direction; Types of actions; Average speed of each action. Fig. 3. User s mouse gestures in distance, speed and the resultant polynomial curve. The Figure 3 shows the raw data gathered and the resultant user profile. The blue dots are the raw values. They are very much scattered, thus they are of difficult interpretation. To achieve the user profile a 15 degree polynomial regression algorithm was used, obtaining a polynomial curve. The resultant curve is very precise, imprinting all the user characteristics and common actions. As a result an intrusion can be detected by achieving a different curve from what it was expected, as seen in Figure 4. Moreover, in Figure 4 the blue line is the base template of the user actions and the brown line is an intrusion attempt. The distinction is very clear and the curves differ very much in both speed and distance. In result the detection is done accurately and the session is closed. In the Figure 5 is shown the accuracy of the system and curve generation of a normal user session and the base curve. In particular, the base curve is 162

177 Fig. 4. User curve and intrusion attempt. Fig. 5. Comparison of user base data and a normal session. achieved by feeding the system with 15 sessions of normal user activities. The comparison obtained from a very accurate curve and one generated in real-time are very close. The maximum differential value is under 10% between curves, and although there are distinguishable marks that differ from the base line they are not great, resulting in a positive classification. 3.3 Classification Algorithms It was presented along this article methods of capturing the user interactions and data processing, but the data must be provided with meaning; by extracting a user profile that is unique and able to be compared in the future. These methods must then be structured by classification algorithms which allow the system to compare the events captured in a session with the user profile. These algorithms are crucial to an authentication system. The classification algorithms allow the data classification and outcome a result that can be comparable with all the others users, even if their profile is very distinct. Therefore, the classification algorithm is responsible for the authentication of the user session, by comparing it to the user profile. The survey [12] shows a comparison between the most common classification algorithms. They are sorted according to their equal-error rate, being all of them used in keystroke dynamics problems. Due to the complexity of the data processing and the expected results, in this work the Outlier Count and the Nearest Neighbour (Mahalanobis) algorithms were adopted. As observed in [12], even though the Manhattan algorithm provides the best results in the classical keystroke approach, in this work its results were worse than the others. 4 Results The case studies were done in a controlled environment, being the users known beforehand and their profile exhaustively reviewed in order to verify the algorithms and the data collection methods. 163

178 Two case studies were developed to test the two different authentication methods proposed, the Static Authentication System (Case Study 1) and the Continuous Authentication System (Case Study 2). The environment was a computer science laboratory with two different setups, each to a specific case study. 4.1 Case Study 1 To this case study a web login page was setup. It consisted in a simple login page in which each user had an account. To train the system, the users had to do 15 login attempts. Thereon, the system would process the data, done in less than 30 seconds, and save the user profile. The user would then do a round of tests verifying if is profile was accurate. The day after the user would test the system again to establish a deviation pattern. The false negatives were calculated (Type I Errors) from the user attempts to login on his/her account, being set as the base value for comparison. After these processes the other users would try to forge their entry with the user credentials, being ignorant about the way the user typed his credentials. Each user attempted to login in the other users account in two attempts. From these attempts the Type II Errors were calculated to each account, being the number of successful login accesses. In total it was done 500 login accesses, being 300 valid accesses and 200 unauthorized accesses, by 10 different users in a one-week period. In the Table 2 is shown the comparison between the three algorithms. So, in the first column are the Type I errors percentage when the Type II error is 0%, meaning that no intruder can break into the system. Also, the last column are the Type II errors percentage when the Type I error is 0%, meaning that the user can authenticate in every attempt. Table 2. Case study 1 algorithms comparison. Algorithm Type I error for Type II error for EER Type II error=0% Type I error = 0% Outlier Count 19% 4,9% 32,4% Mahalanobis 16,6% 6,5% 30,6% Combined 10% 4,2% 27% In a thorough analysis, the combined algorithms result the the one that presents the better results. Even though the Outlier Count and the Mahalanobis are better in different cases, nonetheless, the overall performance in what this project intended to aim, therefore, the Combined Algorithm was chosen. Moreover, along the tests, the users were allowed to choose their username and password, being the passwords ranging from 5 to 10 characters, leading to a great variance in the results. Most of the Type II error outcome from short passwords, being the best results achieved from 8 or more letters. 164

179 4.2 Case Study 2 This case study consisted in continuous monitoring of 6 computers, each with a unique user, according to the one presented in the Section 3.2. The case study had the duration of one week, being monitored 730 user sessions. As a result, 525 were legitimate session (390 form the keyboard and 135 form the mouse) and 205 illegitimate (135 form the keyboard and 70 form the mouse). The reason behind the high keyboard results is because the keyboard intrusion detection takes less time than the mouse (about 5 minutes less). To better compare the results, the Table 3 is presented, following the Table 2 context. Table 3. Case study 2 algorithms comparison. Algorithm Outlier Count Mahalanobis Combined Device Type I error for Type II error for EER Type II error=0% Type I error = 0% Keyboard 53% 4,2% 25% Mouse 48,7% 20,3% 25,3% Keyboard 55,7% 12,6% 25% Mouse 31% 12,5% 20% Keyboard 44% 9% 24,6% Mouse 12,4% 5,9% 11% Yet again, the Combined algorithm is the one that presents the best results, being the best one in 5 of the 6 calculations. This approach is indeed the best in a normal scenario, to the common users. 5 Conclusions and Future Work The use of behavioural biometrics has some great advantages over most of the other authentication methods. Their transparent usage, user acceptance and maintaining the common usage, makes this techniques an obvious choice to intrusion detection systems. So, we have presented a complete system that managed two different approaches to user authentication, keyboard dynamics and mouse dynamics. Also, two case studies were done to test different contexts: a static login system monitoring and a dynamic user session monitoring. The end results showed that the static authentication system was at par with the current projects developed, and the continuous authentication system presented promising results, being the area were future efforts will be concentrated. The future steps will be testing more robust classification algorithms [2] in order to achieve better results. The implementation of stress detection algorithms [4] to minimize behavioural variations is also an important step to improve the overall quality of the systems. Finally the support to touch screen inputs is an important goal to achieve as well. 165

180 References 1. Ahmed Awad E Ahmed and Issa Traore. A New Biometric Technology Based on Mouse Dynamics. IEEE Transactions On Dependable And Secure Computing, 4(3): , KP Bennett and C. Campbell. Support vector machines: hype or hallelujah? ACM SIGKDD Explorations Newsletter, 2:1 13, Francesco Bergadano, Daniele Gunetti, and Claudia Picardi. User authentication through keystroke dynamics. ACM Transactions on Information and System Security, 5(4): , D. Carneiro, M. Gomes, A. Costa, P. Novais, and J. Neves. Enriching Conflict Resolution Environments with the Provision of Context Information. Expert Systems (accepted to appear). 5. Herve Debar. Intrusion Detection FAQ: What is behavior-based intrusion detection?, D E Denning. An Intrusion-Detection Model. IEEE Transactions on Software Engineering, SE-13(2): , João Ferreira, Henrique Santos, and Bernardo Patrão. Intrusion Detection Using Keystroke Dynamics. In The Proceedings of the 10th European Conference on Information Warfare and Security, pages 81 90, Hugo Gamboa and Ana Fred. An identity authentication system based on human computer interaction behaviour. Proc. of the 3rd Intl. Workshop on Pattern Recognition in Information Systems, Hugo Gamboa and Ana Fred. A behavioral biometric system based on humancomputer interaction. Proceedings of SPIE, 5404(i): , Sajjad Haider, A Abbas, and AK K Zaidi. A multi-technique approach for user identification through keystroke dynamics. IEEE international conference on systems, 2: , J Ilonen. Keystroke dynamics. Advanced Topics in Information ProcessingLecture, Kevin S Killourhy and Roy A Maxion. Comparing anomaly-detection algorithms for keystroke dynamics. In Dependable Systems and Networks - DSN, pages Ieee, Ivan Koychev and Ingo Schwab. Adaptation to drifting user s interests. In Proceedings of ECML2000 Workshop: Machine Learning in New Information Age, pages 39 46, R Moskovitch, C Feher, A Messerman, N Kirschnick, T Mustafic, A Camtepe, B Lohlein, U Heister, S Moller, L Rokach, and Y Elovici. Identity theft, computers and behavioral biometrics, Maja Pusara and Carla E Brodley. User re-authentication via mouse movements. Proceedings of the 2004 ACM workshop on Visualization and data mining for computer security VizSECDMSEC 04, pages 1 8, Roman V RV Yampolskiy, Monroe Ave, and V Govindaraju. Behavioural biometrics: a survey and classification. International Journal of Biometrics, 1(1):81 113,

181 Secure Password Management With Smart Cards Nuno Pinheiro, Ricardo Chaves, Carlos Ribeiro INESC-ID/Instituto Superior Técnico Abstract. Currently, most user authentication services are based on passwords. To avoid memorization of multiple passwords, users tend to re-use the same password on multiple systems. As such, finding the password of the user, gives the attacker access to several systems of the user. Some solutions mitigate this problem by allowing users to remember only one password. These solutions, such as Single Sign On or hash based password generators, require trustworthy external services or the generation of multiple dependent passwords. These systems are susceptible to DOS and brute force attacks. Another solution is the use of password managers that store passwords ciphered by a master password. Although being more resistant to DOS attacks, usually they are still susceptible to brute force ones. The work herein presented proposes the implementation of a password manager based on smart cards where the passwords are securely stored inside the smart card and can only be accessed after mutual authentication, eliminating the problem of brute force attacks. Keywords: Single Password Authentication, Password Managers, Smart Cards 1 Introduction In the last years, a rising number of services, both for single machines and distributed systems, have been introduced. These services handle different resources from private data to public information, requiring a reliable and secure access control system. For this access control to be possible, an authentication scheme that allows people to prove their identity is required. Several authentication schemes exist, based on at least one of three factors[1] namely something that the user knows, such as a simple pin or a complex password; something that the user owns, such as a physical token; or something that the user is, proven by his physical or behaviour attributes, such as his fingerprints. From these factors, the most commonly used is the first[2], something the user knows, or password-based authentication. The access to different services requires the user to memorize different passwords to authenticate himself towards these services. A common approach to avoid this memorization effort is the re-usage of the same secret among different 167

182 services[3], the user shares the same password with the different services. This means that in case of password disclosure from one of the services, all of these will be compromised, and an attacker can have access and control over all of the user resources[4]. To avoid these password re-usage problems, different approaches have been considered, allowing the user to have a multi-password security strength by memorizing only a single password. The existing approaches are based on: Single Sign-on services[5], consisting of a dedicated service to user authentication, which can be susceptible to denial of service attacks, preventing the user from accessing his resources; Hash-based passwords[6] solutions that deterministically generate passwords from a master password, which main problem is the relationship between the master password and the generated passwords, making them susceptible to brute force attacks; and password managers systems[7] that store passwords of the user encrypted with a master password, with the main problem of storing the data on devices which are not secure. The work herein presented builds upon these single-password authentication solutions to design a password manager based on smart cards, which allows users to authenticate towards different services using different strong passwords, but requiring the memorization of only one, possibly weak, password. Section 2 covers the state of the art, covering the current solutions to singlepassword authentication and introducing smart cards and their role on the authentication process. Section 3 describes the proposed solution for a singlepassword authentication mechanism, more specifically, a password manager based on smart cards. To evaluate the proposed solution, Section 4 describes a deployment of the system and its obtained properties. Section 5 concludes this paper with some final remarks and future work directions. 2 State of the art To avoid the memorization effort and mitigate the effects of password disclosure, Single Password authentication mechanisms have been proposed. These mechanism allow a user to authenticate himself towards different systems requiring only the memorization of one single password. One type of single password mechanism are password managers. A password manager is an application that stores and provides access to passwords. These passwords are typically stored on the machine of the user. Section 2.1 describes different types of single password authentication mechanisms solutions and compares the different properties provided by each one. Given that the proposed solution considers the use of smart cards as secure storage devices, section 2.2 describes this technology. 2.1 Single Password Authentication Mechanisms This section covers single sign on, hash based passwords and password manager solutions that allow users to have a multi-password security-strength with the memorization of a single password. 168

183 Single Sign On Most services implement their own authentication system. A different approach to this is to delegate the user authentication to an external service. This kind of services, known as Single Sign On(SSO), consist of a service with the single purpose of authenticating the user and securely communicate a successful authentication to the services the user wants to access. This allows the user to memorize only one password to authenticate with the SSO service, providing access to multiple services. To allow the usage of a SSO system, the service to which the user wants to authenticate must be aware of the SSO system and must trust in it. This implies that if a service does not trust in the SSO system of the user, the user will still need to memorize a new password for the service. This implies that SSO systems have low portability, only working with systems which trust them. One reason that can lead to not trusting in SSO systems is the assurance of their availability. In case of a denial of service attack or misbehaviour of the SSO system, it can be turned off or made unreachable, disabling user authentication. Different SSO solutions have been proposed, such as OpenID and Shibboleth[8] Although different solutions exist, there is none that is widely accepted, meaning that a user still needs to access multiple SSO systems accounts to access different services. This implies that SSO services are not yet truly singlepassword solutions. In terms of security, the main problem of this type of solutions is that in case of the user password being disclosed by an attacker, either by brute force attack to the password or misbehaviour of the SSO system, all the user services which trust in this SSO system can be accessed. Hash Based Passwords Hash Based Password systems are systems that generate different passwords for different services based on a single master password provided by the user. When a user registers in one service, he inserts his master password and the name of the service in the password generator. Based on this data, a password is deterministically created. The next time the user wants to access that service, the user then repeats the generation process, obtaining the password for that given service. Some services can use more parameters than those previously specified, such as the user name, adding more entropy to the generated passwords. In most cases, the entire process is automated, only requiring the user to insert his master password. The algorithms used by these solutions, to generate the passwords, require two properties: It must be computationally hard to calculate the master password from the generated passwords and the algorithm must be deterministic. The first property grants that in case of disclosure of one of the passwords it is not computationally feasible to discover the other passwords. The second property allows the user to regenerate all his passwords without requiring the application to store any information. To achieve these properties the generators typically use cryptographic hash functions which already provide these properties by definition. 169

184 The main disadvantage of these solutions is the fact that all the user passwords are related. This means that if one of the generated passwords is disclosed, an attacker can use dictionary or brute force attacks to disclose the master password, thus allowing the generation of all the passwords of the user and access all his services. The main advantage of these solutions is their portability. These systems can be integrated with any system, as long as the user is free to choose his password. The user can have a standalone password generator not integrated with the systems in which he wants to authenticate, generate the passwords from this standalone application, and manually insert the passwords on these systems. This also grants transportability of the system since the user can run this standalone application in a smart phone or web-based application. Password Managers Password Managers are applications which store and provide access to the passwords of the user. The user only needs to memorize a master password and store his passwords in the password manager. Two main types of password managers exist: Password managers internal to applications, such as a component of a browser with this functionality[9], or Password managers external to the applications, which work as a server for other applications to retrieve and store the passwords used by them[10]. By choosing different passwords for different services, the user can achieve a truly multi-password strength, requiring him to remember only one master password. These passwords are also independent since they are not generated from a root value. To protect the stored passwords, symmetrical cipher algorithms are used. These algorithms use the user password, or a transformation of it such as its hash, as a key to encrypt the stored data. This means that only with the presentation of the user password, will these systems be able to get the passwords. As in the case of hash-based password, this means that if an attacker performs a brute force or dictionary attack to the data stored in the password database, he will be able to retrieve the master password and access the data. An advantage of passwords managers is that the attacker will first need to access the passwords database, while in hash-based passwords, an attacker only needs one of the generated passwords. Some solutions do not implement one or more of these features. By default, Mozilla Firefox does not require a master password, not requiring the user to authenticate, and the cipher of the passwords data base is performed with a default key. Google Chrome delegates the ciphering and authentication to the operating system. In the case of running over the Windows operating system, the encryption is made by the CryptProtectData provided by the Windows API, assuring that the data can only be accessed after the user is properly authenticated in the operating system. An important feature which must be considered on password managers external to the applications is the access control policy that defines which applications can access the user passwords. Two examples of this type of systems are Gnome 170

185 Keyring[11] and KDE KWallet[12]. Gnome Keyring access control policy is based on the user space in which the applications run. After the user authenticates, any process running over the same user space as the user can access the data. KDE KWallet policy requires the user to accept or deny this access from an application when it tries to access the passwords for the first time in a session. In spite of this, in case of computer loss or non legit access, an attacker will be able to access the passwords database since this database is stored on an insecure device, and although cryptographically protected against trivial attacks, it will not resist to dictionary or brute force attacks. 2.2 Smart Cards In solutions like password managers, where data is encrypted with possibly weak passwords, there is some probability that an attacker can access the data and decipher it. Smart cards[13] are a solution that is able to mitigate this problem. They consist of a card, usually with the size and shape of a credit card, which can store and process data. Smart cards are designed to be tamper-resistant, meaning that it is not possible to successfully get data stored inside the card by using physical attacks. Their design also covers hardware-specific processors which implement cryptographic functions in such a way that side-channel attacks can be avoided. These properties allow smart cards to be used on authentication protocols based on something the user owns. Some smart card solutions also allow authentication of the user by fingerprint matching inside the card. In these scenarios, the smart card secure storage allows for the authentication key and user fingerprint template to be securely stored inside the card. Smart cards applications are limited to implementation dependant restraints on length of data that can be stored and data rate of communication. An example of a smart card is JCOP31[14], containing 14kB of available non-volatile memory for data and applications, and performing with a default communication rate of 9600 bits per second. An usual technology to perform communication between a computer application and a smart card is PC/SC[15]. This technology consists of a multi-platform infrastructure providing a common interface to access smart cards with readers from different manufacturers. Although smart cards are used in several solutions as trusted components, PC/SC does not grant security properties, such as authentication and confidentiality, to the messages. Designers of systems based on smart cards are responsible for assuring these properties in case of card replacement or channel eavesdropping. 3 Proposed Password Manager Solution As discussed above, being password-based authentication the most common method, it is important for users to use different passwords in different services. 171

186 The common memorization problem can be mitigated by providing users with single-password authentication services. Password managers help users achieve multi-password strength without having a relation between different passwords, as opposed to hash-based passwords, and discovering this single password will not provide access to all the systems unless the password database can be accessed. A problem that keeps existing with most password managers is that, when the encrypted password database can be accessed, an attacker can perform brute force and dictionary attacks to find the master password and decipher the passwords for the different systems. Herein we propose the use of smart cards (SC) to protect data. SC can be used to cipher the data to be stored outside the card, protecting the data with keys cryptographically stronger than a common password, and can even be used to store data inside the card itself. By using smart cards to cipher the externally stored passwords, the password database could still be attacked, but the computational resources required to attack it will be significantly greater given the size of the key. When the passwords are stored inside the card, brute force attacks can be avoided by forcing a maximum number of authentication tries, after which the card will be blocked or the data of the user is deleted. The solution herein proposed consists of a password manager based on smart cards. In this solution, the passwords are protected inside the card. The passwords can only be accessed after user authentication towards the smart card. We mitigate the risk of accessing the passwords since an attacker needs access to the card, and authenticate himself. In this solution, besides the user authenticating towards the card to prove his identity, the card also needs to be authenticated, avoiding the storage of the password on a non-legit card. Section 3.1 gives an overview of the solution, its main components, technologies used and the taken trust model. Section 3.2 takes into account its previous section and defines how the proposed solution can assure a secure communication between the personal computer and the smart card. 3.1 Solution Overview Solution Components The proposed solution is a password manager external to the applications whose purpose is automating the authentication process of the user with different services, without the user having to remember the passwords for those. The system is composed by two major components. The first is the password manager server. This component runs inside the personal computer of the user and is responsible for receiving requests from client applications to store and retrieve their passwords and to communicate with the smart card. The second component is the password manager applet running inside the card which stores the passwords of the user and answers to commands sent from the server. Trust Model In order to properly design the proposed solution a trust model must be defined for the system on each of its components. The following defines the trust assumptions defined for the considered system. 172

187 Fig. 1. Password Manager Architecture Application Assumptions The system start-up configuration is trustworthy - The system configuration assures the Password Manager Server is launched before other applications of the user Password Manager Server Assumptions The current user space is secure - If an application runs in the same user space as the server, it is not malicious An authenticated card is reliable - A card which proved its identity is reliable Password Manager Applet Assumptions The card is tamperproof - It is not possible for an attacker to access the passwords without authentication No other application internal to the card can access the passwords - If the card supports multiple applications, it also implements a proper firewall between applications Only the user knows the smart card access password - If somebody authenticates with the user password, he is the expected user Components Technologies Different technologies have been chosen to achieve the desired functionalities and the properties required by the trust model. For the communication between client applications and the password manager, an inter-process communication (IPC) technology is required. It is important for the chosen technology to assure the legitimacy of the service being accessed and provide secure point to point communication. For this purpose, the DBUS technology has been chosen. When an application accesses DBUS it can either access the system bus or the session bus. While the system bus allows any application to connect, the session bus only grants access to applications running over the same user space as that session. DBUS also provides service name registration. When registering a name, this name can not be re-used. This property, together with assumption 1.1, which grants that the Password Manager Server is registered before other applications of the user, allows applications accessing 173

188 the passwords to assure the legitimacy of the Password Manager Server. By registering on the session-bus, it also assures that only applications running in the same user space as the user can access the service. Regarding the communication between the PC and the SC, it is important to be independent of the manufacturers of the card and the reader. The communication between the password manager server and the smart card is performed using the PCSC library, providing an abstraction over the used peripherals. The password manager applet is developed in Java Card Technology and runs inside a Java Card, a SC which runs Java Card applications. This allows the applet to be deployed in SC from different manufacturers as long as they provide a Java Card virtual machine. The Java Card specification allows multiple applets to be deployed inside the same card. Although multiple applets can be deployed on the same card, Java Cards implement a firewall, allowing applets to access only data their own, providing the assumption Communication Security In the previous sections no trust assumption for the communication channel between the password manager server and the smart card have been specified. While in some smart card solutions this secure channel is not required, since there is no confidential information flowing from or to the card, as is the case of an application in which the card would only encrypt an hash of a message with its private key. In the case of the proposed system there is confidential information flowing to and from the card. Another important property to take into account in the considered scenario is that the connection with the smart card cannot be trusted. As in the previously example, when sending an hash value to the card, no confidential information would be leaked. Herein, if the user smart card is replaced by a malicious card, either by physically replacing it, or by a logical channel, this malicious card would be able to receive the user credentials. This allows us to conclude that in this case, as opposed to other common smart card scenarios, mutual authentication is needed. This means that besides the card demanding user authentication, the user application must also be assured of the smart card identity. Assuming a non secure communication channel also implies that the authentication process must be protected, thus the pin or password cannot be sent in clear text. To achieve this the proposed solution uses Encryption Key Exchange[16] as the authentication protocol. This authentication protocol is used since it provides mutual authentication, assuring the identity of both the user and the card, while protecting the secrecy of the user authentication Pin/Password, which is never sent in clear text. After user authentication the data must be transferred by a secure channel. This is achieved by encrypting the data in order to avoid message leaking. Besides authentication, the previously specified authentication protocol also generates a temporary session key. This session key is used to cipher the messages when sending or receiving the passwords from the SC, assuring the confidentiality of the messages. 174

189 In addition to confidentiality, it is also important to assure freshness of the messages, avoiding replay attacks, and message authentication, assuring the message was not modified in the communication channel. To provide the first property, a nonce field is added to the messages. This nonce is a randomly generated value which is returned by the applet in each message. For the second property, a digest of the whole message is added at the end of the message. The resulting format of the messages is depicted in figure 2. Fig. 2. Message Security 4 System Deployment To evaluate the proposed solution, an extension for Mozilla Firefox has been implemented, replacing the default password manager. To access the password manager server, the extension uses C++ stubs automatically created by the qdbusxml2cpp tool, allowing access to the service as a common C++ object which abstracts DBUS technology. For a developer to integrate the proposed solution with a different application, several tools are available that create stubs for different technologies and programming languages, providing easier integration. In terms of usability, the usage of the implemented extension is transparent. Users interact with the password manager functionalities of the browser as if it was not replaced, having its default usability. The performance of the system was measured with the applet installed in a JCOP31 card. Two benchmarks were used to measure access times comparing the proposed solution and Firefox default password manager. Table 1 presents the average access time calculated from each of the benchmarks. These results conclude that the infrastructure associated with the proposed solution affects the performance. Although, the measured results are still inferior to one second, not affecting the usability of the system. Benchmark Proposed Solution (ms) Default (ms) Password insertion Password Access Table 1. Benchmark results 175

190 5 Conclusions To avoid the memorization of multiple passwords, users tend to reuse the same password over different services, causing a possible vulnerability for those. Several solutions have been proposed to allow the authentication of multiple services keeping the memorization effort of a single password. SSO are responsible for authenticating the user for different systems, but are susceptible to DOS attacks, and in case of password leaking, an attacker is able to access all the services of the user. Hash based password generators generate different passwords from a master password. In case of disclosure of one of those, an attacker may perform a brute force attack to obtain the master password. Password managers are applications that store passwords, usually on a database in the user computer. Although being encrypted, these passwords can be target of brute force attacks By protecting the passwords inside the card, the proposed solution is a password manager able to avoid brute force attacks to those. It implements mutual authentication to avoid leaking the password to non legit cards, and assures confidentiality, authentication and freshness to the messages. Acknowledgements This work was partially supported by national funds through Fundação para a Ciência e a Tecnologia (FCT) under project Threads: Multitask System Framework with Transparent Hardware Reconfiguration (reference number PTDC/EEAELC/ /2010), project PEst-OE/EEI/LA0021/2013, and by the PROTEC Program funds under the research grant SFRH/PROTEC/49763/2009. References 1. O Gorman, L.: Comparing passwords, tokens, and biometrics for user authentication. Proceedings of the IEEE 91(12) (2003) Chang, C.C., Wu, T.C.: Remote password authentication with smart cards. Computers and Digital Techniques, IEE Proceedings E 138(3) (may 1991) Florencio, D., Herley, C.: A large-scale study of web password habits, New York, NY, USA, ACM (2007) 4. Ives, B., Walsh, K.R., Schneider, H.: The domino effect of password reuse. Commun. ACM 47(4) (April 2004) Pashalidis, A., Mitchell, C.J.: A taxonomy of single sign-on systems. In: Information Security and Privacy, Springer (2003) Halderman, J.A., Waters, B., Felten, E.W.: A convenient method for securely managing passwords 7. Huth, A., Orlando, M., Pesante, L.: Password security, protection, and management (2012) 8. Suoranta, S., Tontti, A., Ruuskanen, J., Aura, T.: Logout in single sign-on systems. In: Policies and Research in Identity Management. Springer (2013)

191 9. Zhao, R., Yue, C.: All your browser-saved passwords could belong to us: a security analysis and a cloud-based new design, New York, NY, USA, ACM (2013) HUBER, M.: Agente secreto. Linux magazine (72) (2011) Larsson., A.: Proposal for inclusion in desktop: gnome-keyring (2003) 12. Staikos, G.: Kwallet-the kde wallet system (2003) 13. Markantonakis, K., Mayes, K.: Smart Cards, Tokens, Security and Applications. Springer, Dordrecht (2008) 14. IBM: Jcop - the ibm globalplatform javacardtm implementation 15. Husemann, D.: Standards in the smart card world. Computer Networks 36 (2001) 16. Bellovin, S., Merritt, M.: Encrypted key exchange: password-based protocols secure against dictionary attacks. In: Research in Security and Privacy, Proceedings., 1992 IEEE Computer Society Symposium on. (1992)

192 Sistemas Embebidos e de Tempo-Real 178

193 Fault Detection in Time- and Space-Partitioned Systems Kleomar Almeida, Ricardo C. Pinto, and José Rufino University of Lisbon - Faculty of Sciences - LaSIGE Abstract. The next generation of space vehicles will integrate different mission functions on a shared computing platform using the advanced principle of Time and Space Partitioning (TSP). Improving the survivability of space vehicles requires reacting promptly on fault events, which implies timely fault detection. This paper addresses the definition and design of fault-detection mechanisms for TSP hypervisors, covering both time and space domains. In spite of our focus in aerospace applications, the safety attributes and cost-effectiveness of TSP systems have a wider potential scope of applicability to other safety-critical environments, namely those involving autonomous vehicles in automotive, airborne and underwater applications. Keywords: Fault Detection, Dependable Hypervisors, Time and Space Partitioning, Real-Time Systems, Mixed-Criticality 1 Introduction Future space mission demand for innovative computing architectures and onboard software systems, meeting strict requisites of size, weight and power consumption (SWaP). To address SWaP requisites, functions which traditionally received dedicated resources are now integrated in a shared computing platform, using the advanced principle of Time and Space Partitioning (TSP). In TSP architectures the logical separation of applications in criticality domains, named partitions permits hosting several functions in the same computing platform, thus fulfilling the SWaP requirements. With partitioning one can achieve two main results: containment of faults in their domain of occurrence; enable independent software verification and validation, thus easing the mandatory certification process required by safety-critical applications. This work was partially supported: by the EC, through project IST-FP7-STREP (KARYON); by FCT/DAAD, through the transnational cooperation project PROPHECY; and by FCT, through the project PTDC/EEI-SCR/3200/2012 (READAPT), the Multiannual Funding Program, and the Individual Doctoral Grant SFRH/BD/72005/

194 Although TSP systems conceptually guarantee that the partitions do not interfere with each other in the time and space domains, they do not guarantee per se that a partition may not exhibit faults - only that faults will not propagate to other partitions. Therefore effective fault detection mechanisms are needed to ensure correct operation on the overall system. Given the two dimensions of TSP, fault detection needs to be performed on both time and space domains. This paper is organized as follows: Section 2 provides an overview of the AIR Technology and its components; Section 3 details the mechanisms for performing fault detection, both in the temporal and spatial domains; Section 4 concludes this paper and discusses future research work. 2 AIR Technology Overview The ARINC 653 In Space Real-time operating system (AIR) technology was developed in an international consortium sponsored by European Space Agency (ESA) with the requirements of the aerospace industry in mind [9, 5]. Its scope, however, is not limited to aerospace but can be extended to domains with mixedcriticality applications, e.g. automotive [3, 6]. The AIR architecture was initially designed to implement and fulfill the TSP requirements of the ARINC 653 specification [1, 8]. It has since been improved, aiming at flexibility and offering features which are not covered by the ARINC 653 specification. An example of the improvements is the work being currently carried out to extend the AIR architecture to safely schedule applications over multiple processor cores [4]. 2.1 System Architecture The architecture of an AIR-based TSP system is depicted in Figure 1. The AIR architecture relies on the Partition Management Kernel (PMK), a component supporting the whole system and enforcing robust TSP. Robust TSP ensures that partitions do not mutually interfere w.r.t. the fulfillment of real-time and addressing space encapsulation requirements. The PMK efficiently handles functionalities such as: partition scheduling and dispatching; low-level interrupt management; inter-partition communication support [9]. The AIR design foresees the possibility of hosting different Operating Systems (OSs) within different partitions, as is the case of Real-Time Operating Systems (RTOSs) and generic, non-real-time OSes. The Partition Operating System (POS) is encapsulated inside the AIR POS Adaptation Layer (PAL) allowing a more flexible integration of each POS. The APEX Interface component provides a standard programming interface derived from the ARINC 653 specification [1], with the possibility of being subsetted and/or extended for certain partitions. Additionally the AIR architecture contains a Health Monitor (HM) component responsible for monitoring components at the different layers of the architecture: hardware; system; partition; application layers. Upon the occurrence of 180

195 Fig. 1. AIR system architecture an error (like a task deadline miss, memory protection violation, or even some hardware failure) an exception is raised. A handler provided by the application developer may be executed. This helps to confine errors within their domain of occurrence and prevent failures from propagating. The HM component is spread virtually in all AIR architecture components to ensure fault monitoring at all layers. Therefore the HM component does not appear in Figure Temporal Partitioning Temporal partitioning is concerned with ensuring that the activities in one partition do not affect the timeliness of the activities in other partitions. Temporal partitioning is achieved through a two-level hierarchical scheduling scheme. The first level corresponds to schedule partition execution. Partition execution scheduling is performed over a predetermined sequence of time windows. These windows are cyclically repeated over a Major Time Frame (MTF). Partition activation corresponds to allocating one or more windows within the MTF. The order of activation is defined off-line at design time using appropriate tools, and a Partition Scheduling Table (PST) is created. The usage of PSTs provides deterministic execution, since partitions have allocated a predefined amount of time to access processor resources [9]. The second level corresponds to scheduling performed inside each partition. Tasks (processes, in the ARINC 653 terminology) are scheduled e.g., according to the native POS scheduler rules. 2.3 Spatial Partitioning The other attribute of a TSP system is spatial partitioning. This attribute ensures that applications sharing the computing platform do not interfere with each other with regard to memory (code, data and execution context). The enforcement of spatial partitioning provides guarantees regarding the isolation of partitions, allowing self-contained and safe application execution. 181

196 This enforcement is tightly coupled with the underlying computer architecture, needing additional mechanisms. The AIR technology exploits hardware-based memory protection mechanisms to provide spatial partitioning, and also spatial fault detection. 2.4 Health Monitoring The AIR Health Monitor (HM) is responsible for detecting and handling hardware and software errors occurring at the different layers of an AIR-based system. An error - e.g., task deadline miss, memory protection violation, bound violation or hardware failure - is detected by the AIR HM entities. It is handled by a default Error Handler (EH) or one provided by the application developer. As much as possible, the HM will confine the error propagation within its domain of occurrence: task level errors will cause an application error handler to be invoked; partition level errors trigger a response action defined by the Partition Health Monitor Table in the ARINC 653 configuration [1]. The response action may be shutting down the entire partition, reinitializing the partition again or simply ignoring the error (see Figure 2). Partition errors may stem from task level errors that cannot be handled by the application error handler. Errors detected at system level may lead the entire system to stop or reinitialize. Fig. 2. AIR Health Monitoring scheme 3 Fault Detection in Time and Space Partitioning The detection of faults on a TSP system must cover both domains: time and space. On the time domain, the detection of faults draws from the rigorous knowledge of the system timeliness. This knowledge is embodied by the PST, which 182

197 defines the partition schedule. On the spatial domain, it draws from AIR/ARINC 653 system configuration and the computer architecture mechanisms providing memory protection. In both cases the information pertaining to faults must be handed over to the Health Monitoring entity, which will trigger the correct handlers to deal with them. 3.1 Temporal Domain Fault Detection An AIR-based system is composed by a set of partitions, where a partition (P m ) is defined as an application container. Each partition (P m ) contains a task set (τ m ), composed by individual tasks (τ m,q ) holding the following properties: Period (T m,q ) - dictated by application requirements and/or environment; Deadline (D m,q ) - dictated by the application and/or environment requisites; Capacity (C m,q ) - obtained through WCET analysis of the task source code. A temporal fault may occur due to a variety of factors. One of the factors may be the underestimation of the Worst-Case Execution Time (WCET) value during system design time. All estimations are susceptible to error, WCET analysis is no exception. In critical real-time systems the analysis cannot be underestimated, otherwise the result may be catastrophic. To avoid underestimation of the WCET analysis and to cope with the variance in computer programme execution time, the WCET analysis tools tend to overestimate the results (i.e., some pessimism is introduced into the analysis). To ensure that all deadlines of a given partition task set are met, the system developer and/or integrator performs a schedulability analysis over the task set. This analysis makes use of: the estimated task capacity (C m,q ) through WCET analysis; a given scheduling algorithm; and the interference time of the other tasks in the task set and/or the other partitions. The result of the analysis is a computed Worst-Case Response Time (WCRT) for each task (W CRT m,q ). Given the nature of the analysis, two outcomes are possible: if any task τ m,q does not fulfil the conditions of equation 1, the task set is deemed unschedulable; otherwise is deemed schedulable. W CRT m,q D m,q T m,q (1) When the task set is unschedulable, is the duty of the system developer and/or integrator to re-evaluate the temporal constraints of the given task set. In the case of the task set being schedulable, the WCRT analysis ensures that for each task τ m,q of the task set, its execution will be finished before the given W CRT m,q for the respective task - based on the assumptions made by the system developer/integrator. However, a change on the environment or in the assumptions made by the system developer/integrator or even an insufficient pessimism introduced during the WCET analysis may lead a task to violate its W CRT m,q. Having this into account we propose the creation of a Pseudo-Deadline (P D m,q ) for each task of a given task set. The P D m,q is the trigger for a reactive mechanism that aims 183

198 at prompt detection and reaction over potential fault occurrences (task deadline miss). Its value stems from the W CRT m,q of the task, as depicted in Figure 3. Fig. 3. Pseudo-deadline diagram The relation between the P D m,q and W CRT m,q is represented in the equation 2, which shows how is the P D m,q value calculated. τ m,q τ m P D m,q = W CRT m,q (2) Analysis and Discussion The advantages introduced by the P D m,q mechanism overcomes the disadvantages introduced. It possesses the following advantages: it permits to promptly react and detect the occurrence of faults; permits to improve the survivability of the space vehicles; and, no significant overhead w.r.t. the existent AIR task deadline violation monitoring mechanism [9]. A disadvantage of the P D m,q is when the system is configured with a poor WCET analysis. This may lead to an erroneous placement of the P D m,q and also lead to an overload of warnings to the application coming from HM component, and therefore adding overhead to the whole system. This may occur when the C m,q of a task is underestimated, therefore the P D m,q could be constantly violated. 3.2 Spatial Domain Fault Detection Another domain of segregation on a TSP system is the address space. On a shared computing platform, the space domain segregation implies that one application cannot access the addressing space of any other, either for reading or writing purposes. This partitioning is enforced by memory protection mechanisms. The existence of memory protection mechanisms does not preclude the existence of faults - just the occurrence of errors. A misbehaving application may - intentionally or accidentally - try to access another application s addressing space. An example of an intentional address space violation is a rogue payload application in a dual-use satellite; an accidental violation is a wrongly valued pointer. In any scenario, the memory protection mechanisms would hinder the misbehaving application s intention, and raise an exception signalling such event. An example is shown in Figure 4. On this example the Partition P2 accesses correctly its address space. Partition P1 tries to access the address space of P2, and the access is not validated. 184

199 (a) Correct access (c) Faulty access Fig. 4. Memory access and protection mechanisms The usage of memory management signalling mechanisms is the crux of both spatial domain fault detection and partitioning in TSP systems. An indication from these mechanisms is the signal that a space-domain fault occurred, which can then be dealt with by the appropriate functions, e.g. Health Monitoring. Memory Protection Architectural Support The enforcement of space partitioning must be supported by auxiliary hardware mechanisms offering memory protection. Any memory access involves the hardware mechanism, which validates such access. In recent computer architectures these mechanisms assume the shape of Memory Protection Unit (MPU), e.g. ARM Cortex-M3 [2] or Memory Management Unit (MMU), e.g. SPARC V8 [10] processors. Functionally, an MMU is an extended MPU. The purpose of memory protection is to confine an application into an assigned region of the memory. The application is loaded into that region, and is only allowed to access that region, with any attempt to access another region being regarded as an exception. An example of this scheme is depicted in Figure 5, with Partitions being physically separated in memory regions. Fig. 5. Memory Segmentation In the simplest case, a Partition is composed just by a compiled application. A compiled binary is composed by several sections: code, which must be immutable and contains the instructions to be executed; data, contains the (initialized) variables; bss, which contains zero-initialized and uninitialized global variables; stack, defined on a per task basis, which is used to store return information and local variables [7]. Such an organization raises issues w.r.t. memory protection, e.g. securing read-only sections. These are adressed by the hardware mechanisms, providing a set of permissions to protect memory areas - read, write and execute. 185

200 Memory Protection Fault Detection A spatial domain fault (memory protection) can take two forms: an attempt to write to a read-only region; an attempt to access an area outside the application s segment. In any case an exception is raised by the MMU, which notifies the processor of the event. In both cases, the auxiliary hardware mechanisms support fault detection. Upon an exception, the appropriate Health Monitoring mechanisms and handlers can be invoked to deal with the fault (see Figure 2). The information pertaining to the fault depends on the hardware architecture, e.g. the SPARC reference MMU [10] provides information regarding the offending address being accessed. 4 Conclusion and Future Work This paper discusses fundamental ideas of how to achieve Fault Detection Mechanisms in Time- and Space-Partitioned systems. Our approach consists in enhancing TSP-based systems with the ability of promptly detect and react to the faults, thus improving the survivability of the space vehicles. The solution is performed differently at temporal and spatial domains. At the time domain we have to monitor application (processes) and partitions. At space domain we have to monitor the memory and input/output (e.g., memory mapped) spaces. Our future work will be focused in the verification and validation of the proposed solution, and to provide the extension of the proposed mechanisms to introduce Proactive Fault Tolerance in the TSP-based systems. References 1. Airlines Electronic Engineering Committee (AEEC): Avionics Application Software Standard Interface - ARINC 653 (Mar 2006) 2. ARM Limited: ARM v7-m Architecture Reference Manual (2010) 3. Consortium, A.: AUTOSAR: Specification of Operating System. Tech. rep., AU- TOSAR Consortium (2006) 4. Craveiro, J., Rufino, J., Singhoff, F.: Architecture, mechanisms and scheduling analysis tool for multicore time- and space-partitioned systems. ACM SIGBED Review 8(3), (Sep 2011) 5. ESA TSP Working Group: Avionics time and space partitioning user needs. Tech. Rep. 1, ESA/ESTEC, Technical Note TEC-SW/09-247/JW (2009) 6. Nóbrega Da Costa, P., Craveiro, J., Casimiro, A., Rufino, J.: Safety Kernel for Cooperative Sensor-Based Systems. In: Workshop on Architecting Safety in Collaborative Mobile Systems (ASCoMS) (Sep 2013) 7. On-Line Applications Research: RTEMS C User s Guide. Tech. rep., OAR (2011) 8. Rufino, J., Filipe, S., Coutinho, M., Santos, S., Windsor, J.: ARINC 653 interface in RTEMS. In: Proc. of the Data Systems In Aerospace Conf. Naples, Italy (2007) 9. Rufino, J., Craveiro, J., Verissimo, P.: Architecting Robustness and Timeliness in a New Generation of Aerospace Systems. In: Casimiro, A., de Lemos, R., Gacek, C. (eds.) Architecting Dependable Systems VII, Lecture Notes in Computer Science, vol. 6420, pp Springer Berlin / Heidelberg (2010) 10. SPARC International Inc.: The SPARC Architecture Manual (1992) 186

201 SPARK-BMC: Checking SPARK Code for Bugs Cláudio Belo Lourenço, Victor Cacciari Miraldo, Maria João Frade, and Jorge Sousa Pinto HASLab/INESC TEC & Universidade do Minho, Portugal Abstract. The standard SPARK deductive verification tools, based on contracts, are not practical in early stages when the idea is only bug catching. We discuss the implementation of a bounded model checker for SPARK, focusing on specific challenges of this language. Our tool is fully automatic, complementing the existing tools for SPARK. 1 Introduction Program verification techniques can be grouped in two main families. While deductive verification based on the use of a program logic and the design-bycontract principle gives full guarantees and allows for expressing properties using a rich behavior specification language, it is not automatic: it is the user s responsibility to provide contracts and other information required for verification to proceed, such as loop invariants. Such information requires a lot of effort from the user since it is often difficult to write. The second family of techniques is based on model checking, more precisely model checking of software, which typically allows only for simpler properties, expressed as assertions in the code, but is fully automated. The fundamental idea is to create a model from the source program, and then, given a property, check if it holds in that model. However, such an approach has a main downside: state space explosion. This problem is common to all applications of model checking, but the presence of data makes it worse in the case of software. Bounded Model Checking (BMC) [1] is an approach that can be used to overcome this limitation by only checking execution paths with size up to a fixed (user-provided) bound, sacrificing soundness. The general idea is that only a partial exploration of the state space is performed. Even so, BMC is useful as long as it finds bugs that would otherwise be missed. SPARK is a programming language and tool set designed for the development of high-assurance software [2]. The SPARK language is a subset of Ada, complemented by an expressive system of contracts (inserted as Ada comments) to describe the specification and design of programs. The existing tools 1 for verification of SPARK programs are mainly based on deductive verification, which implies that someone has to write the contracts and loop invariants that will be used to generate verification conditions, which is in general far from straightforward. To fill this gap, we propose here an automated verification tool for SPARK 1 Mainly commercialized by Altan Praxis, 187

202 code: a bounded model checker inspired by the success of the CBMC tool for bounded model checking of C programs [3]. 2 Background BMC of software. The key idea of BMC of software is to encode bounded behaviors of the program that enjoy some given property as a logical formula whose models, if any, describe execution paths leading to a violation of the property. The properties to be established are assertions on the program state, included in the program through the use of assert statements. For every execution of the program, whenever a statement assert φ is met, the assertion φ must be satisfied by the current state, otherwise we say that the state violates the assertion φ. The verification technique assumes that a satisfiability-based tool is used to find models corresponding to property violations. At the heart of a BMC tool stands an algorithm that extracts a logical formula directly from the source code (including properties expressed as assertions), without user intervention. The algorithm begins with some preliminary simplification steps that may include the removal of side effects, or normalization into a subset of the target programming language. The next step is where information is lost, in the sense that only bounded behaviors are preserved. Given an entry-point provided by the user, the program is expanded by unwinding loops a fixed number of times, and inlining routine calls (in the presence of recursion, a bound is also applied on the length of this expansion). A program consisting of multiple routines is thus transformed into a monolithic program, which is both recursion-free and iteration-free. To enforce soundness of BMC, an unwinding assertion can be placed at the end of each expanded segment of code. If the unwinding assertion (negating the condition of the loop) is not violated by any execution, then checking the transformed (bounded) code is sound. Unwinding assertions can be omitted, in which case one must always bear in mind the unsoundness of the approach. In this case the unwinding assert φ statement is replaced by assume φ, to ignore execution paths requiring more iterations. In order to extract a logical formula from this monolithic program, we have to transform it into a form in which the values of the variables do not change once they have been used (so that they can be seen as logical variables). This is done by converting the program into a single-assignment (SA) form in which multiple indexed versions of each variable are used a new version is introduced for each assignment to the original variable, so that in every execution path, once a variable has been read or assigned it will not be assigned again. The next step is to normalize this program into conditional normal form (CNF): a sequence of single-branch conditional statements of the form if b then S, where S is an atomic statement, i.e. either an assignment, assert, or assume instruction. The idea is to flatten the branching structure of the program, so that every atomic statement is guarded by the path condition leading to it. At this point, two sets C and P can be extracted from the program: C includes a formula b x = e for every statement if b then x := e and a formula b θ 188

203 package Marray i s Array Size : constant : =10; subtype I n d i c e s i s I n t e g e r range 1.. A r r a y S i z e ; type VArray i s array ( I n d i c e s ) of I n t e g e r ; procedure MaxArray (V: in VArray ; M: out I n d i c e s ) ; # d e r i v e s M from V; # p o s t ( f o r a l l I i n I n d i c e s => (V( I ) <= V(M) ) ) ; end Marray ; package body Marray i s procedure MaxArray (V: in VArray ; M: out I n d i c e s ) i s I : I n t e g e r ; Max : I n d i c e s ; begin Max := I n d i c e s F i r s t ; I := I n d i c e s F i r s t +1; loop # a s s e r t ( f o r a l l J i n I n d i c e s range I n d i c e s F i r s t.. ( I 1) # => (V( J ) <= V(Max ) ) ) ; # a s s e r t ( I >= I n d i c e s F i r s t ) and ( I <= I n d i c e s Last + 1 ) ; exit when I > I n d i c e s Last ; i f V( I ) > V(Max) then Max := I ; end i f ; I := I + 1 ; end loop ; M := Max ; end MaxArray ; end MArray ; Fig. 1. SPARK program specification and body: the procedure receives an array of integer values and returns the index of the maximum element. for every statement if b then assume θ; P includes a formula b φ for every statement if b then assert φ. C captures logically the operational contents of the program, and P contains the properties to be established. If no assert statement fails in any execution of the program one has that P is a logical consequence of C. This can be determined by checking the satisfiability of the set of formulas C { P}. Any model found for it corresponds to an execution path that leads to an assertion violation. Of course, satisfiability checking is restricted to models that capture the properties of the data structures manipulated by the program, and that are specified by some background theory T (usually a combination of several theories). Therefore satisfiability should in fact be understood as T -satisfiability. It can be checked by a Satisfiability (SAT) or an Satisfiability Modulo Theory (SMT) solver: the main difference is the way numeric values and arrays are modelled. SPARK. Although SPARK [2] is based on a heavily restricted subset of Ada together with a set of annotations, it should be considered in its own right as a full language for the development of annotated high-assurance software. Annotations in SPARK code (lines starting with --#) must be written as comments, ignored by compilers but not by the SPARK verification tools. 189

204 A SPARK program is composed by one or more units. There exist two different kinds of program units: packages and subprograms. Subprograms define computations, which may have parameters with mode in, out or in out and are divided into functions and procedures. Functions are routines with only mode in parameters, that may not have side effects, and always return a value. Each function must have exactly one return statement (the last statement in the function). Function calls occur inside expressions, while procedure calls occur as standalone statements (procedure may not contain return statements). Package, is used as a way of grouping related entities (e.g. data types and objects, subprograms or even nested packages). All program units are generally divided in two parts: specification (the program unit s interface) and body (the implementation details). Fig. 1 contains the package Marray s specification and body. Many features of Ada are not present in SPARK because they are considered dangerous or difficult to verify in the development of safety-critical systems. Some of these exclusions facilitate our work in the development of a BMC for SPARK, for instance there is no need to limit the number of times a function is inlined (recursion is not allowed); the same applies to pointer validity checks. SPARK is not just a language, but also a set of tools to check if a program respects all the restrictions imposed on valid SPARK programs, and also for program verification. The Examiner is a tool responsible for performing syntactic and static semantic analyses for checking the validity of SPARK programs, as well as generating verification conditions. The reader is referred to [2] for a full description of the SPARK tools, as well as SPARK restrictions. Types are organized into categories [2]. For instance, the discrete type hierarchy is devided into integer types and enumerations. Moreover, integer types are devided into signed and modular types. Operations over the former may result in overflow (which raise runtime exceptions), whereas operations over the later have wraparound semantics. A modular type is defined by giving a power of two integer N; its values range from 0 to N 1. In the example, T is a modular type. type T i s mod 4 ; type Nat i s range 0.. Integer Last ; type Day i s (Mon, Tue, Wed, Thur, Fri, Sat, Sun ) ; subtype Counter i s Nat range ; subtype Weekday i s Day range Day F i r s t.. F r i ; The range of the predefined integer type is defined in a default SPARK package, but it can also be given in a configuration file. It is also possible to define new integer types, with range given by two static expressions (lower and upper bound), as for example as Nat shown above. Note the use of the expression Integer Last which makes use of an attribute over the integer type. An enumeration is defined using a list of identifiers (enumeration literals). In SPARK, as opposed to Ada, enumeration literals cannot be overloaded. Type Day is an example of a declared enumeration type. Comparison operators may be applied to enumeration types, except for type Boolean, where the only operators are equality and inequality. A subtype of a certain type is defined by giving a lower and upper bound over the base type. One can define subtypes of both enumeration types and 190

205 integer types, but not of modular types. For instance, Counter and Weekday are examples of subtypes of the types Nat and Day respectively. In addition to discrete types there exist also composite types, divided into records and arrays. A record is a structure consisting of named components. As in many other languages, an array consists of an indexed list of elements of the same type. The index must be a discrete type and may possibly be constrained. Tuple in the example below, is an unconstrained array (note the use of <>) while WorkHours is a constrained array. Objects of an array type must always have a static bound, therefore the types Tuple and Matrix cannot be used directly to create new objects, since they have unconstrained indexes. type Tuple i s array ( I n t e g e r range <>) of Day ; type WorkHours i s array ( Weekday ) of Nat ; type Matrix i s array ( Counter, I n t e g e r range <>) of C i r c l e ; Turning now to SPARK statements, the most primitive form of iteration is implemented by an infinite loop control structure and an explicit abrupt exit command which should always occur under an if statement without else branch, or alternatively within a when clause. An exit statement always refers to the innermost loop. Every while or for loop can be converted into a primitive loop. 3 SPARK-BMC SPARK-BMC is a prototype bounded model checker for SPARK programs, that follows closely the BMC algorithm described before. The tool checks valid SPARK programs for property violations as will be explained below. It assumes, without checking, that the input program passes the Examiner validity checks. The tool is being developed in Haskell and uses as backend the SMTsolver Z3 [4]. SPARK-BMC is open source; it is available from the repository https://bitbucket.org/vhaslab/spark-src. The tool parses the SPARK program and creates an Abstract Syntax Tree (AST) with the program representation. The program is then transformed, simplified, and normalized (by multiple traversals of the AST) and two sets of logical formulas are extracted, describing logically the operational contents of the program, and the properties to be established. Finally, the SMT solver is used to check if there exists a property violation; if so, a counter-example is shown. The tool checks for properties annotated in the code which are inserted as comments beginning with --%, distinct from SPARK annotations. A program annotated for SPARK-BMC is still a valid SPARK program that can be checked by the usual SPARK toolset. Our tool works with the following annotations: % a s s e r t C; % assume C; % notoverflow ( op, type, e1, e2 ) ; The two basic annotations assert C and assume C, with C a quantifier-free formula, are similar to those used in CBMC: assert C means that the assertion C must be satisfied by the current state, and assume C means that all paths violating the property are ignored. The notoverflow is used to check if overflow 191

206 occurs and is translated into an assert with a formula that depends on the model used for numeric values (bit-vectors or unbounded integers). % notoverflow (+,ITER, INDICES FIRST, 1 ) ; I := I n d i c e s F i r s t +1;... % a s s e r t ( I >= VARRAY FIRST ( 1 ) ) and ( I <= VARRAY LAST ( 1 ) ) ; % a s s e r t (MAX >= VARRAY FIRST ( 1 ) ) and (MAX <= VARRAY LAST ( 1 ) ) ; i f (V( I ) > V(MAX) ) then... % notoverflow (+,ITER, I, 1 ) ; I := I + 1 ; Fig. 2. Annotated program Similarly to CBMC, these annotations can be inserted by the user to express properties that should hold (very helpful for instance for debugging purposes), or else added automatically by an instrumentation tool that analyses the program and inserts obvious annotations. In SPARK code it is particularly useful to check statically for runtime exceptions; the SPARK Examiner certainly does this, but it requires annotating loop invariants in the code. These properties (in particular overflow, array out of bound access and division by zero) can be instrumented automatically, and with SPARK-BMC they can be checked without requiring invariants, as will be illustrated later in the paper. For overflow, the instrumentation inserts a notoverflow annotation for each arithmetic operation that can possibly cause overflow; for division by zero it inserts an assert to check that the denominator is different from zero; for array out of bounds access, it inserts an assert to check the validity of each index. Fig. 2 shows some properties that may be automatically inserted in the example of Fig. 1. The rest of this section presents the details of the several transformation steps on the original program, and the interaction with the SMT solver. Simplification. The first step is to rewrite the input program into an equivalent one that uses only a restricted set of statements, namely, loop, exit, if-then, if-then-else and assignment. case statements are translated into if statements. exit-when statements are rewritten using if and exit statements. Also if statements using the elsif keyword are translated into nested ifs. while and for loops are rewritten as discussed using loop, if and exit statements. Subprogram inlining. The inlining of routine calls consists of taking the entry point provided by the user and recursively remove subprogram calls. For subprograms used as standalone statements, this is done by simply replacing the subprogram call by the respective body. For function calls occurring as part of expressions, the function body is inserted exactly before the statement which contains the call, and an auxiliary variable is used to propagate the return value. Auxiliary variables are also used to propagate the values of parameters inside the callee and back to the caller subprogram, taking into account their modes 192

207 (in, out or in out). Since different contexts are being merged, identifiers are renamed to avoid conflicts, by adding as prefix the package and subprogram name (this is also useful to keep information about the identifier s context). The result of this transformation step is a monolithic program with no calls. Eliminating attributes and enumeration literals. SPARK attributes apply to types and subtypes. Since we assume that the program being verified is always a valid SPARK program, it is known beforehand that the enumeration literals are being used correctly. Moreover, SPARK forbids the overloading of enumeration literals. With this in mind and the information about declarations obtained in the last step, we translate enumeration literals into integer values (the respective position in the enumeration) and get rid of attributes, replacing them by equivalent expressions. The only exception is for literals of Boolean type, since they can be used as conditions and the Boolean type is not ordered. Loop unwinding. Loops can in general be seen as blocks of code containing backward-goto and forward-goto statements. Since the iteration schemes have been removed, only primitive loops are present at this stage, and the only way of exiting such a loop is through an explicit exit, equivalent to a forward-goto statement. On the other hand, reaching the end of a loop block produces a backward-goto to the beginning of the loop. In the present step, in order to produce a bounded model, each loop gets unwound a fixed number of times K. Loop headers are removed, and loop bodies are replicated K times. However, exit statements complicate this picture: the statements belonging to the loop body following a reached exit statement do not get executed. This is done by introducing an artificial loop unwind wrapper for the code standing between the exit statement and end of the unwound loop code. With this wrapper, reaching an exit statement means that none of the following statements inside the wrapper should get executed. Such wrappers have other uses as will be seen below, but will be removed in the final normalization step. An unwinding assertion or assumption (depending on the user choice) is placed at the end of the expanded code to produce the effect explained in Section 2. Single-assignment transformation. A crucial step towards the normalization of the program is its transformation into an SA form. In this transformation, multiple indexed versions of each variable are used a new version is introduced for each assignment to the original variable, so that in every execution path, once a variable has been read or assigned it will not be assigned again. While the transformation of straight-line code is quite straightforward, code with multiple branches poses some challenges. The only statement left with multiple branches at this stage of the transformation workflow is the if statement (exit statements inside loop wrappers will be discussed later). The two final versions of each variable (one from each branch) must be merged; this is achieved by inserting, immediately after the conditional, an assignment to each modified variable, making use of conditional expressions, as used in C. 193

208 Our conversion algorithm traverses the AST and appends an appropriate index to each variable occurrence. To deal with multiple branch statements, the algorithm makes use of two counters for each variable; one family of counters (R) keeps the index that should be used when a variable is read, the other (W) keeps the last index of the variables that have been used for writing. Both R(v) and W(v) are incremented when variable v is assigned. However, when entering an else branch R(v) must be reset to the value it had immediately before the entering of the if conditional. At the merge point, the values of W at the end of both branches are used for inserting an assignment with the appropriate conditional expression. Consider the example R = {(X, 2 ), (Y, 4 ) } ; W = {(X, 3 ), ( Y, 4 ) } i f (X#2 = Y#4) then X#4 := X#2 + Y#4; R = {(X, 4 ), (Y, 4 ) } ; W = {(X, 4 ), ( Y, 4 ) } e l s e X#5 := X#2 + 5 ; R = {(X, 5 ), (Y, 4 ) } ; W = {(X, 5 ), ( Y, 4 ) } end i f ; X#6 := (X#2 = Y#4)? X#4 : X#5; R = {(X, 6 ), (Y, 4 ) } ; W = {(X, 6 ), ( Y, 4 ) } The fact that R(X) and W(X) are different indicates that this is part of some else branch. Observe how the value of R(X) before entering the conditional is used in both branches when X is read. Special attention must be given to assignments involving arrays. For the purpose of obtaining a logical encoding, arrays are seen as aplicative: each array correspond to a single variable, updated through a store function. So an assignment of the form A(X) := Y is first transformed into A := store(a,x,y), and conversion to SA form then produces the instruction A2 := store(a1,x,y ), where X and Y correspond to X and Y with possible renaming of variables due to transformation to SA form. Fig. 3 presents the state of our running example after conversion to SA form. Note in particular that MAX#7 is not assigned in this iteration because its valued depends on the reached exit statement. Such assignments are added in the next iteration when removing exit statements. CNF normalization. The program is normalized into a sequence of statements of the form if b then S, where S must be an assignment, assert or assume instruction. To reach such form, exit statements must be removed. This step is divided in two parts: first, the program is normalized in the form described above, allowing S to be an exit statement; later this statement is removed. For the first part, if statements with else branch are rewritten into a sequence of two if statements with mutually exclusive conditions. This transformation is correct since in SA form the value of the Boolean expression cannot possibly be modified by subsequent instructions. Nested if statements are then pushed up in the AST, by traversing it and collecting the necessary path conditions for reaching each assignment, exit, assert or assume instruction, and then creating an if statement with the conjunction of the collected conditions. For the exit statements removal, recall that when such a statement is reached, none of the following instructions in the loop wrapper should be reached. Moreover, the values of the variables after the wrapper must be in accordance with the 194

209 ARRAY SIZE#1 := 1 0 ; MAX#2 := 1 ; % notoverflow (+,INTEGER, 1, 1 ) ; I#2 := (1 + 1 ) ; LOOP WRAPPER i f ( I#2 > ARRAY SIZE#1) then exit ; [ ( I, 2 ), (M, 1 ), (MAX, 2 ), ( V, 1 ) ] end i f ; % a s s e r t ( I#2 >= 1) and ( I#2 <= ARRAY SIZE#1); % a s s e r t (MAX#2 >= 1) and (MAX#2 <= ARRAY SIZE#1); i f (V#1( I #2) > V#1(MAX#2)) then MAX#3 := I #2; end i f ; MAX#4 := (V#1( I #2) > V#1(MAX#2))? MAX#3 : MAX#2; % notoverflow (+,INTEGER, I #2,1); I#3 := ( I#2 + 1 ) ; i f ( I#3 > ARRAY SIZE#1) then exit ; [ ( I, 3 ), (M, 1 ), (MAX, 4 ), ( V, 1 ) ] end i f ; % a s s e r t ( I#3 >= 1) and ( I#3 <= ARRAY SIZE#1); % a s s e r t (MAX#4 >= 1) and (MAX#4 <= ARRAY SIZE#1); i f (V#1( I #3) > V#1(MAX#4)) then MAX#5 := I #3; end i f ; MAX#6 := (V#1( I #3) > V#1(MAX#4))? MAX#5 : MAX#4; % notoverflow (+,INTEGER, I #3,1); I#4 := ( I#3 + 1 ) ; % a s s e r t F a l s e ; END LOOP WRAPPER; [ ( I, 5 ), (MAX, 7 ) ] M#2 := MAX#7; Fig. 3. Single-assignment program representation first exit statement reached. If no exit statement is reached then an assert or an assume annotation must be reached. The preparation for this step starts when the code is converted into SA form: for each exit statement, the current version of each variable at that point is kept, and at the end of each loop wrapper, a new version for each modified variable is reserved. This version is the one that is used immediately after the loop wrapper: its value reflects the exit statement that has been reached. This information is displayed as comments in Fig. 3. At this stage each exit statement is guarded by a condition C; the statement is reached if and only if C evaluates to true. To ensure that none of the subsequent statements (including other exits) are reached after an exit statement is, one has to ensure that none of the subsequent guards evaluate to true, by propagating the condition not C through them. In order for variables to hold the correct values after the wrapper, assignments to the reserved variables are inserted using the current variables that were kept together with the exit statement. The guard for these assignments is the exit guard. Loop wrappers may now be removed. Fig. 4 shows the CNF representation of our running example. Creating the logical encoding. There are no language-specific aspects in the next step. After all the previous transformations, the program is now a sequence of statements of the form if C then S, where S may only be an assignment or an instruction derived from an annotation (assert, notoverflow, or assume). As described in Section 2, one now has to extract two sets of formulas C and 195

210 ... True => NExit#1 := not ( ( I#2 > ARRAY SIZE#1)); ( I#2 > ARRAY SIZE#1) => MAX#7 := MAX#2; ( I#2 > ARRAY SIZE#1) => I#5 := I #2; NExit#1 => % a s s e r t ( I#2 >= 1) and ( I#2 <= ARRAY SIZE#1); NExit#1 => % a s s e r t (MAX#2 >= 1) and (MAX#2 <= ARRAY SIZE#1); NExit#1 and (V#1( I #2) > V#1(MAX#2)) => MAX#3 := I #2; NExit#1 => MAX#4 := (V#1( I #2) > V#1(MAX#2))? MAX#3 : MAX#2; NExit#1 => % notoverflow (+,INTEGER, I #2,1); NExit#1 => I#3 := ( I#2 + 1 ) ; True => NExit#2 := not ( ( I#3 > ARRAY SIZE#1)) and NExit #1; NExit#1 and ( I#3 > ARRAY SIZE#1) => MAX#7 := MAX#4; NExit#1 and ( I#3 > ARRAY SIZE#1) => I#5 := I #3; NExit#2 => % a s s e r t ( I#3 >= 1) and ( I#3 <= ARRAY SIZE#1); NExit#2 => % a s s e r t (MAX#4 >= 1) and (MAX#4 <= ARRAY SIZE#1); NExit#2 and (V#1( I #3) > V#1(MAX#4)) => MAX#5 := I #3; NExit#2 => MAX#6 := (V#1( I #3) > V#1(MAX#4))? MAX#5 : MAX#4; NExit#2 => % notoverflow (+,INTEGER, I #3,1); NExit#2 => I#4 := ( I#3 + 1 ) ; NExit#2 => % a s s e r t F a l s e ; True => M#2 := MAX#7; Fig. 4. CNF normalization (auxiliary variable _NExit may be propagated) P. This is straightforward, by traversing the list of statements, transforming if statements into implications and assignments into equalities. The formulas with assert statements are collected in P, and the remaining implications in C. Solver interaction. Now that we have C and P the satisfiability of C { P} modulo a background theory has to be checked. The simultaneous presence in the language of discrete types with modular semantics and of signed integers for which runtime overflow exceptions are raised led us to elect fixed-size bit-vectors for our primary encoding of discrete types: the modular semantics is directly captured by bit-vectors, and for signed integers, since overflow is protected by instrumented notoverflow annotations, it is indifferent to use bit-vectors or an unbounded integers encoding. Our choice was to use Z3 [4] as proof tool. Z3 is a high-performance SMT solver being developed at Microsoft Research. Open source bindings 2 are available for Haskell, which allow for the use of some convenient features, as well as a direct interaction with the solver. The first task is to create the adequate Z3 sorts for each SPARK predefined or user-defined type. A relation between these two classes must be kept for building Z3 expressions. One may then create one Z3 constant for each program variable. Since Z3 does not support multiple-index arrays, SPARK arrays with multiple indexes are represented using nested arrays in Z3. Formulas from C are interpreted and sent to the solver one by one, while formulas from P are used to build the expression P which is then also sent to Z3. The interpretation of SPARK expressions and creation of Z3 formulas is programmatic, using functions available in the Z3 bindings. The Z3 bindings also provide a function for checking satisfiability, and in the SAT case produces a model to be used as counterexample

211 4 Conclusion Although the development of SPARK-BMC is still in progress (some features of SPARK are not yet covered), the tool s workflow is entirely implemented, and we are able to successfully check programs manipulating arrays and discrete types. Our preliminary results are satisfactory, and sufficient to illustrate the advantages of automatic verification. Let us turn back to the example in Fig. 1 to show how the tool can discover subtle bugs without the need for user annotations. One common error would be to write the exit condition as follows: exit when I > I n d i c e s Last + 1 ; It is easy to see that this alternative condition would cause an array out of bounds exception in the array access contained in the expression V(I) > V(MAX), but such a bug can be easily missed. Our tool detects it automatically. The SPARK tools (based on deductive verification) would generate a verification condition (labelled as assert) stating that the loop invariant is preserved by iterations of the loop, and another VC (labelled as rtc check) to enforce that whenever V(I) > V(MAX) is evaluated the value of I lies within the range of the array. For the code of Fig. 1 both VCs are successfully discharged: no outof-bounds access takes place. But if the exit condition is modified to the above, then the invariant preservation condition can no longer be proved (it fails in the last iteration). The rtc check is still proved, because it is a consequence of the invariant. If the invariant is corrected to I <= Indices Last + 2, then the invariant preservation VC is discharged, but not the rtc check the invariant is now correct, but it does not prevent the out-of-bounds access. This example illustrates that with deductive verification it can be hard to detect exactly what went wrong is the program unsafe, or is the user-provided invariant wrong? To use SPARK-BMC, the program is first automatically instrumented as discussed in Section 3. Depending on the bound K provided by the user, SPARK- BMC will either indicate that the unwinding assertion fails, or else (for K > 10) that an assert violation occurs. In this case the tool displays the violated assertion, as well as the current values of the variables occurring in them. Safety violations like overflow and division by zero would also be detected if present. Even though not particularly optimized at the present stage, the tool seems to scale reasonably well (the array size in the example may well be increased up to thousands). Our current work focuses on covering aspects of SPARK that are still not handled, including support for floating and fixed point types and respective properties. In the near future we will work on optimizing the generation of Z3 expressions for scalability. At a later stage we intend to (i) extend the tool to handle concurrent programs, more precisely programs written in the RavenSPARK profile, by employing context-bounded analysis; and (ii) investigate how the tool can be used for coverage analysis of SPARK code, following work in this direction (for C code) using CBMC [5]. 197

212 References 1. Biere, A., Cimatti, A., Clarke, E.M., Strichman, O., Zhu, Y.: Bounded model checking. Advances in Computers 58 (2003) Barnes, J.: High Integrity Software: The SPARK Approach to Safety and Security. Addison-Wesley Longman Publishing Co., Inc, Boston, MA, USA (2003) 3. Clarke, E.M., Kroening, D., Lerda, F.: A Tool for Checking ANSI-C Programs. In Jensen, K., Podelski, A., eds.: Tools and Algorithms for the Construction and Analysis of Systems. Volume 2988 of Lecture Notes in Computer Science., Springer (2004) de Moura, L., Bjørner, N. In: Z3: An Efficient SMT Solver. Volume 4963/2008 of Lecture Notes in Computer Science. Springer Berlin (April 2008) Angeletti, D., Giunchiglia, E., Narizzano, M., Puddu, A., Sabina, S.: Using bounded model checking for coverage analysis of safety-critical software in an industrial setting. J. Autom. Reason. 45(4) (December 2010)

213 Requirements for Real-Time Embedded Systems: A study on semi-automated verification Nuno Silva 1, Rui Lopes 1 and Francisco Costa 1, 1 Critical Software, S.A., Parque Industrial de Taveiro, Lote 48, Coimbra, Portugal {nsilva, rmlopes, Abstract. The objective of this work is to map two complementary activities and conclude on requirements quality based on cross checks and results from a more manual independent verification of requirements and specifications, and a more automated natural language verification of the requirements text. For this purpose we use the results of Independent Verification and Validation activities performed on several safety-critical embedded systems where a set of issues have been collected and classified, and we perform a complementary automated requirements analysis with a simple text parsing and analysis tool (examples of such tools are E-Smart/ARM from NASA, QuARS, from CNR, Lexior, SAT...). We present and discuss the conclusions and results of these analysis and their level of usefulness for contributing to system dependability and safety. Keywords: Embedded systems, dependability, requirements engineering, requirements verification, automated verification, natural language requirements. 1 Introduction Embedded and Real Time systems are a class of important systems with growing usage and importance. These systems are usually very critical (safety-, mission-, or business-) and very particular in what concerns the definition, development and operation. These systems must be properly specified in all senses, but a particular attention must be given to interfaces with hardware, software and the operation environment. Since these interfaces are extremely difficult to control and to fully cover, the importance of complete, coherent and dependable specifications/requirements are in the front line when it comes to assess the quality and resilience of embedded and real-time systems. It is commonly accepted that 80% or more of rework is spent on requirements related defects corrections [3]. Moreover, requirements or specification engineering are among the techniques that are less precise and require extreme care, being currently covered by international safety critical standards, but quite limited when it comes to tools or V&V support. Some of the most common tools/techniques used for requirements engineering and V&V include CASE tools, manual verifications, traceabilities, formal 199

214 specification/verification, independent V&V, and so on. However, this is not enough since a lot of effort is still put on the requirements phase and many of the misunderstandings and incompleteness are still root-caused to the requirements/specifications. The objective of this preliminary work is to map two complementary activities (the traditional requirements reviews, and the natural language analysis) and conclude on requirements quality based on cross checks and results from comparing a more manual independent verification of requirements and specifications, and a more automated natural language verification of the requirements text. For this purpose we use the results of Independent Verification and Validation activities performed on selected safety-critical embedded systems where a set of issues have been collected and classified, and we perform a complementary automated requirements analysis with a simple text parsing and analysis tool. We present and discuss the lessons learned, conclusions and results of these analysis and their level of usefulness for contributing to system dependability and safety. Finally, we lay the road for the next steps of this research. 2 Requirements Verification (Techniques) Requirements verification is an essential part of the quality assurance and project success roadmaps. This activity is amongst the most important in the V&V processes, especially if we consider that requirements issues (Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise) account usually as the major cause of project failure [1]. Some studies show that over 50% of software defects are related to requirements problems [2] and that over 80% of rework is spent on requirements related defects corrections [3]. The requirements verification techniques are heavily dependent on the requirements analysis technologies and tools used. A large number of systems are still developed in an old fashioned way, with text based requirements, although some efforts have been made to introduce more and more modern techniques and tools (UML, SysML, AADL, formal requirements, model based, etc). This is why we present two main requirements verification techniques in this paper, since they are the most commonly used currently in our industrial reality, the traditional requirements verification methods, and the natural language assessments. 2.1 Traditional Requirements Verification The methodology presented in this paper represents briefly the methodology used by Critical Software, SA in the frame of its services of Requirements Verification (especially applied in the frame of Independent Software Verification and Validation (ISVV) projects). This methodology is a simplified subset of the one presented in section 5 of the ESA ISVV Guide [4]. 200

215 The requirements/specification verification activity aims to verify requirements for completeness, correctness, adequacy and technical feasibility. It is based on ECSS-E- ST-40C [5], and the ECSS-Q-ST-80 [6], and consists of manual analysis and verifications and construction/verification of traceabilities, including but not limited to: Verification of SW requirements correctness with respect to system requirements; Verification of consistency of the documentation of SW requirements; Verification of the dependability and safety of requirements; Verification of the readability of SW requirements; Verification of the timing and sizing budgets of SW requirements; Verification of the testability of the requirements; Verification of the SW requirements conformance with applicable standards. The software requirements are usually verified considering the following criteria: Software requirements are traceable to user/system requirements; Software requirements are externally and internally consistent; Software requirements are verifiable; Technical feasibility of software design, operations and maintenance; The software requirements related to safety, security, and critically are correct. The tracing criterion correlates outputs and inputs from a certain phase (for instance, software requirements and user/system requirements). Two types of traceability are considered: forwards and backwards. Forward traceability requires that each input to a phase (e.g. system requirements) shall be traceable to an output of that phase (e.g. software requirements). Traceability is normally achieved building cross-reference matrices. Holes in the matrix demonstrate incompleteness. Thus, the requirements document is analyzed for completeness and consistency; Backward traceability requires that each output of a phase shall be traceable to an input to that phase. Outputs that cannot be traced to inputs are superfluous, unless it is acknowledged that the inputs themselves were incomplete. Superfluous requirements are detected. The main sources of documentation used as inputs to the requirements verification analysis include specifications and requirements, the associated traceabilities and interface control specifications/documents. All identified errors, problems and inconsistencies resulting from the verification analysis contribute to a list of issues under the form of Review Item Discrepancies (RID) where the problem type uses the categories presented in Table

216 Table 1. Requirements RID Types RID Type ID Description External consistency EC The item presents an inconsistency against an item of an applicable or referenced document (e.g. the component design is not according to an applicable software requirement). What is implemented is not what is required. Internal consistency IC The item presents an inconsistency against another item in the same document (e.g. the description of the interface is not consistent between the interface user and the interface provider). Correctness CR The item is incorrectly implemented, technical issues are being violated. Consider for instance that an activity diagram that contains a deadlock condition. That would be a case to which correctness will apply. Technical feasibility TF This item is not technically feasible taking into account the applicable constraints (e.g. the architecture makes extensive use of advanced object oriented techniques but the application is to be written in C language). Readability and R&M This item is hard to read and/or to maintain. An individual Maintainability other than the author will have serious difficulties in implementing and/or maintaining the item. The information provided is confuse and therefore may lead to wrong interpretations. Completeness CP The item is not completely defined or the provided information is not sufficient (e.g. the description of the service 5 telemetry packet provided in the user manual do not allow for a clear identification of the error cause). If an item do not completely implements a requirement or interface defined in an applicable or reference document, one shall use external consistency instead. 2.2 Natural Language Assessments As identified previously, ambiguity analysis, consistency and completeness verification are usually carried out by reviewers that read the requirements documents and try to find inconsistencies. These manual activities are time consuming, boring for the engineer and often inefficient and ineffective. Also, commonly specifications/requirements are written in natural language, this text is rarely perfect. All stakeholders have to rely on the specifications/requirements text (engineers, users, designers, testers, operators, vendors, policy makers). 202

217 So, what is exactly Natural Language (NL) analysis? NL analysis can be decomposed in: Lexical Analysis By using words and phrases By classifying sentences/words: vague, subjective, that imply choice or options Syntactical Analysis By analyzing the syntax or grammar constructions By identifying weak phrases, multiplicity, implicit, under- and over-spec Statistical Analysis By considering statistical properties of language structure and usage Consistency check By checking areas such as units of measure We can consider some examples in each of these areas: Lexical examples Ambiguous words: low, bad, clear, easy, efficient, appropriate, sufficient, etc. Syntactical examples Multiple requirements: use of and / or Under-specification: e.g. reporting, what kind of reporting? Statistical Analysis Count frequency of words, such as safe-mode If it occurs many times in one document, this indicates an important concept (domain term) Consistency Check check units e.g. 5 Hz and 5kHz, 10 ft and 10 meters, temperature degrees Celsius, Fahrenheit The objective of this paper is not to use or scan all these points, but to present some preliminary results from the application of the NL analysis idea and to compare it with the manual verification activity and results. Quite a large community and researchers have already studied and presented results related to Natural Language automated analysis, such as [10], [11] and [12], for example. The following table presents some examples of tools that have been developed in the past (several have been discontinued) in order to automated and promote the NL automated analysis [7]. This table is not exhaustive but presents a good view of available tools. 203

218 Tool Name NASA E- Smart/ARM Lexior QuARS Requirements Assistant (RA) Specification Analysis Tool (SAT) Table 2. Example of Tools to support assessments Description The Automated Requirement Measurement (ARM) Tool was developed by the Software Assurance Technology Center (SATC) at NASA Goddard Space Flight Center. It was able to assess requirements specified in natural language. The Objective of the ARM tool was to measure the quality or requirements documents/srs based on a specific set of rules. This tool has been discontinued for quite some time, but reached some popularity. Lexior (LEXIcal analysis for Improvement Of Requirements) objective is to provide a means for improving requirements documents with lexical analysis. The tool provides data pre-processing of multiple input document formats, lexical analysis of requirements, domain-based rule checking for a variety of general requirements formulation rules, interactive mode enabling requirements engineers to validate requirements on the fly, batch mode enabling complete requirements documents validation, and automatic generation of analysis reports. The Quality Analyzer for Requirements Specifications (QuARS) is a tool that enables the user to analyse natural language requirements automatically. QuARS performs a lexical and syntactical parsing of software requirements expressed in NL, and provides defective sentence identification (Expressiveness Evaluation), including: the property of having a unique interpretation (non-ambiguity), the property of being fully comprehensible both when used by the software developer and when read by the user in the Requirements Specification Document (understandability), and the ability of each requirement to uniquely identify its object or subject (specification completion). The Requirements Assistant (RA) tool takes domain information specific to the system into consideration, allows for creation of a domain corpus to define known information about the system, is able to identify missing or inconsistent requirements. RA analyses starting at the sentence level, paragraph level then entire document as a whole. It utilizes knowledgebase of rules developed since the 1980 s on various systems. The Specification Analysis Tool (SAT) augments existing Computer Automated Software Engineering (CASE) and Requirement Management Tools such as DOORS to fill the important need to help organizations create requirement text. SAT replaces check lists, classroom instruction, on the job training, and personal research at the company library with a tool that helps the professional and the young technologist to write good specifications by codifying and using the organizations own rules. 204

219 TEKChecker Sift RT TEKChecker is a tool that helps improving accuracy, precision, and clarity or textual requirements. It identifies missing, incorrect, incomplete, and ambiguous information by using more than a thousand patterns to scour technical writing, highlight potential problems, and describe risks. TEKChecker identifies problem types by examining words in eleven grammatical classes. TEKchecker is no longer available. Sift RT is a web application (can also be installed locally) that allows verification of NL requirements by simple copy-paste into an online form. It allows configuration and detection of Imperatives, Continuances, Directives, Options, Weak phrases and Incompletes, and provides a report concerning each occurrence of these types in the requirements. 3 Overview of Case Studies The case studies considered for this paper are four systems of the Space domain. These systems have been classified as highly critical and, therefore, were subject of ISVV activities. Hereafter, some metrics that help in characterizing the systems, are presented. For confidentiality purposes, references to the project names and costumers are omitted. Table 3. Case studies characteristics System name Domain Segment Type # of Requirements SYS1 Aerospace Space Start-up SW 464 SYS2 Aerospace Space Start-up SW 53 SYS3 Aerospace Space Start-up SW 134 SYS4 Aerospace Space Start-up SW 46 The selected systems are part of a satellite payload and are responsible for the boot of different science instruments. Despite some differences inherent to the functionality of each instrument, the Boot SW is responsible for a standard set of tasks that can be generalised as follows: Verification of the health of the instrument; Checking of the system status; Verification of the Application SW consistency; Execution of Application SW. The selection of very similar systems was intentional. This reduces the probability of the results from being influenced by different approaches into Requirements Engineering, different types of systems and different applicable standards. The selection of systems in very mature domains such as Space also provides a certain degree of confidence in the quality of the requirements being analysed. The identification of issues in requirements that have been produced based in strict 205

220 engineering and quality standards can only be achieved by effective verification methodologies. Therefore, the selected systems are the ideal case studies for the study presented in this paper. We do acknowledge that the current sample is short, and this represents an opportunity to improve this work and the related study in the upcoming months, by adding more systems to the sample. 4 Results This section presents the results of the Requirements Verification obtained thorough the two different approaches described in section 2.1 and Results from Traditional Requirements Verification This section presents the results of several requirements verification activities, performed over the years on embedded and real-time safety critical systems Main Requirements Assessment Results The Requirements Assessment followed the typical ISVV methodology defined by the ESA ISVV Guide [4]. The analysis has been performed by several experts with the support of internal checklists. Several discrepancies have been identified and characterised according to their severity. All the discrepancies have been analysed by the SW development team, and a final list with all the accepted discrepancies has been agreed by all parts (SW developer, ISVV contractor and ESA). The following table provides an overview of the number of Review Item Discrepancies (RID) found (# of RIDs), including the number of RIDs classified as major, the number of accepted RIDs and their relation with the number of requirements analysed. Table 4. Requirements Assessments Results System # of RIDs # of Major RIDs # of RIDs accepted % of RIDs accepted Accepted RIDs per Req. SYS % 0,13 SYS % 0,17 SYS % 0,22 SYS % 0, Preliminary Conclusions The following conclusions have been taken from the analysis of the results obtained through the execution of the Requirements Verification using the traditional approach: 206

221 The results obtained through the traditional methodology represent a considerable added value to the systems dependability; The number of RIDs identified per requirement is considerable, demonstrating the effectiveness of the methodology; The percentage of accepted RIDs is high, showing that the methodology identified issues that needed to be tackled; The methodology is based mostly on manual inspection (with the support of some internal tools such as checklists), requiring a considerable amount of effort; Due to its manual nature, the quality of the final results is highly dependent on the level of expertise of the engineers involved in the activity. 4.2 Results from Automated Requirements Verifications For the Natural Language Verification activity, an assessment was performed on the case studies presented previously, using the Sift RT tool. Sift RT is an open-source browser-based server-side requirements analysis tool, based largely on the NASA ARM tool. It automates the process of searching for certain known keywords and phrases that commonly indicate strong or weak requirements. The tool s website [8] is running an instance of Sift RT which can be used immediately or a user may download and setup a local web server. Being able to quickly run a requirements list through this tool provides an immediate overview of the overall quality of the requirements specification. As NASA s ARM tool, the tool is not intended to evaluate the correctness of the requirements. It is an aid to "writing the requirements right," not "writing the right requirements" Main Automated Requirements Verification Assessment Results Sift RT provides a list of words and phrases it looks for in various lexical classifications. Below are listed the categories along with some examples for the list of words and phrases that are default for the tool: Imperatives - shall; Continuances according to, as follows, in particular, below; Directives e.g., i.e., associated, for example; Options can, could, may, should, will; Weak phrases a great deal, abruptly, almost, also, commonly, enough, eventually, from time to time, maybe, often, potentially, safely; Incompletes not defined, TBD, but not limited to, as a minimum,?. The list of words and phrases can be easily customisable or tailored as necessary. Upon extracting the requirements from each of the case studies and run them through the Sift RT tool, the results presented in Table 5 were obtained. 207

222 Lexical analysis Table 5. Automated Requirements Assessments Results System Imperatives Continuances Directives Options Weak phrases Weak phrases per Req. SYS ,91 SYS ,39 SYS ,04 SYS ,06 Note: The number of incompletes found in the requirements sets was very low, so these have been added to the weak phrases column Preliminary conclusions The following conclusions have been taken from the analysis of the results obtained through the execution of the Requirements Verification using the automated approach: The tool outputs provided useful to identify a high rate of weak phrases per requirement in every system, especially SYS2 this should be due to this specific case study requirements text being particularly long and not clearly expressed; Tools of Natural Language Verification such as Sift RT are very easy and fast to run, providing a quick assessment of the quality of the requirements this analysis can be run throughout the requirements specification phase effortlessly; Customisation and tailoring of words and phrases to search for allows flexibility; Initial work on providing the tool with clear text requirements can be troublesome on the four case studies we had, all of them presented the requirements specification using a different style and format, providing it difficult to automate the task of extracting the requirements text; Some features lacking from Sift RT that may be present in other Natural Language Verification tools that could increase analysis value include: Measurement of a requirement length; Count frequency of terms, to identify important concepts; Consistency checks (e.g. units being used in the specification); 208

223 5 Conclusions and Future Work The analysis of the results obtained by applying the two methodologies described in sections 2.1 and 2.2 has demonstrated that: The results obtained from the automated requirements verification regarding SYS2 revealed a high occurrence of weak phrases per requirements (5,39). Further research on the requirements specification revealed these are too long and complex. Many requirements should be split in smaller, simpler requirements, which would also reduce the occurrence of weak phrases. The fact that these requirements are long and complex may have disguised potential issues that didn t show up during the manual requirements verification (only 11 RIDs). Automated requirements activities provide a quick, measurable and objective assessment to the quality of the requirements. Automated requirements activities provide a certain degree of formalisation of the requirements verification, while the manual inspection capitalises the historical knowledge and experience of the engineers that is difficult to formalise in an automated way. Automated analysis can be easily applied throughout the requirements development and analysis and allow the requirements engineers to improve the quality of the requirements on the fly. Manual activities are essential for the identification of complex issues, which require contextual knowledge and expertise in the system s domain. The combination of automated and manual activities is considered the best approach, bringing the benefits of both strategies and mitigating their weaker points. Future work identified for this effort includes: Improvement of the analysis process, the tool selection/configuration, and support both semantic and syntactic analysis; Inclusion of a much larger and complete set of requirements documents; Addition of different types of applications and domains; Provide concrete examples and map the results from the more traditional requirements reviews and the automated natural language analysis; Definition of a weighted measure in order to rank/compare/normalise the results obtained from the automatic verification, and allow the drawing of clusters of measured quality to compare and rank different sets of requirements documents, different domains or different maturities of software engineering. The formalisation of the requirements is considered a key aspect for evaluating the completeness and correctness of a system specification. As a future work, some formal methods techniques will be assessed in order increase the degree of requirements formalisation. 209

224 6 Acknowledgement This work has been partially supported by the European Project FP CECRIS (CErtification of CRItical Systems) [9]. 7 References 1. CIO analysis: Why 37 percent of projects fail, visited June 25 th, CMU SEI QuARS Presentation and James Martin, INCOSE 21 June CMU SEI QuARS Presentation and Dean Leffingwell, INCOSE 21 June ESA Guide for Independent Verification & Validation, issue 2.0, 29 December ECSS-E-ST-40C, Space engineering - Software, 06/03/ ECSS-Q-ST-80, Space Product Assurance - Software Product Assurance, 06/03/ Evaluation of Current Requirements Analysis Tools Capabilities for IV&V in the Requirements Analysis Phase, SAS 2007 Executive, Galaxy Global Corporation, Valerie Jones & Jennifer Murray, Jeffrey Northey. 8. Sift RT Web site, visited June 25 th, CECRIS website, visited June 25 th, Mohammad Ubaidullah Bokhari and Shams Tabrez Siddiqui, Metrics for Requirements Engineering and Automated Requirements Tools, Proceedings of the 5 th National Conference; INDIACom-201, Computing For Nation Development, March 10 11, Leonid Kof, Natural Language Processing: Mature Enough for Requirements Documents Analysis?, Natural Language Processing and Information Systems Lecture Notes in Computer Science Volume 3513, 2005, pp F. Fabbrini, M. Fusani, S. Gnesi, G. Lami, An Automatic Quality Evaluation for Natural Language Requirements (2001), Proceedings of the Seventh International Workshop on RE: Foundation for Software Quality (REFSQ 2001) 210

225 Wireless Platform to Acquire Biosignals for Human Stress Detection Paulo Simões Margarida Urbano José Fonseca Universidade de Aveiro Instituto de Telecomunicações Instituto de Telecomunicações Campus Univ. de Santiago Campus Univ. de Santiago Campus Univ. de Santiago Abstract. This paper introduces a non-invasive wireless system capable of acquiring simultaneously cardiac changes and the galvanic skin response (GSR) signal and register, in a friendly way, occurrences which can lead to changes in the stress level of the persons under observation. The final purpose of this work is to add stress signals to an Artificial Recognition System (ARS) based platform, developed at the Vienna University of Technology, to aid severely impaired persons in driving electric wheelchairs and to serve as the base to a stress detection system to be used in vehicular applications, in particular to detect dangerous points in roads. The system includes commercial sensors, a Bluetooth interface and an Android based platform to perform processing and data storage. Currently the data collected is object of an off-line processing to verify the adequacy of the stress detection system. Acknowledgements: The authors thank ISR (Institute of Systems and Robotics - Coimbra) for the possibility to use the wireless sensors. The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7) under grant agreement n The Financial contribution of Portuguese National Science Foundation (FCT). 1 Introduction Nowadays, the continuous growth of technology has enabled many ways to study the physio-psychological changes in humans, in particular with non-invasive methods. The monitoring of these changes can be applied in multiple areas as the medical and vehicular navigation. A simple example in the medical area is the study of the apnea [1] and, in the vehicular navigation case, it can have a helpful impact in the safety of drivers if they are in stress. For instance, if a person is driving with a negative feeling as anxiety or tiredness, accidents can happen. So, in this case, it would be useful that a system incorporated in the car could detect the stress level and therefore alert the driver, e. g., recommending the adjustment of the car velocity. This situation, in accordance with [2], could be extended to the study of black spots (road locations prone to accidents) in road maps, i. e., associate the road location with high stress levels exhibited by some drivers previously. Another similar context is related with 211

226 tetraplegic persons who move in wheelchairs and have difficulties to achieve some daily routines as passing through a doorway. These difficulties can be identified by the stress level and, using the stress information, a semi-autonomous control of the wheelchair could be implemented to help the person [3]. In a first stage, this project presents a wireless and non-invasive platform that acquires ECG (Electrocardiogram) and GSR (Galvanic Skin Response) biosignals and allows to register those signals in association with time marks identifying the specific occurrences. All data is saved for posterior analysis in order to classify stress according to the circumstances the subject was dealing with. In this paper, a resume of the state of the art is given followed by the system overview, technical solution and ongoing work, preliminary tests and finally a description of work in progress and future work. 2 State of the art 2.1 Stress sensors and features selection Generally, stress is associated to a negative feeling as discomfort, headaches or even panic attacks and it can be prejudicial to human s health if it is daily or systematically present. Stress can be originated by different causes as troubles in work, illness or death of a family member and so on. These occurrences are called stressors. Stress involves a threat to the organism s homeostasis due to the actuation of a stressor. In consequence a response is issued by the body in order to return back to a state of equilibrium or to maintain it. This state can be reached by several physiological and behavioral adaptive responses [4]. The measurement of stress can be done by medical/biological measures [5] and, with the advances in electronic sensors and in medicine, it is possible to access and interpret in an easier way some physiological signals which contain good information about the stress level. Relevant biosignals as GSR, ECG, blood pressure, electromyogram, electroencephalogram, respiration rate, skin temperature [6], pupil dilation [7], oxygen saturation [8] and even hormonal changes [9] are very useful to identify and classify stress levels. For example, it is known, that under specific stress situations, the GSR, electromyogram, heart rate and blood pressure increase, the skin temperature decreases and the pupil becomes wider as well as the eye moves faster [6] [7] [9]. According to the literature, it can be noticed that it is commonly performed a fusion of sensor types from which the GSR and ECG are most commonly included. After the selection of stress sensors, different features of each type of sensor signals must be extracted. Feature selection is a crucial step because the goal is to reduce the data amount while maintaining or enhancing the vital information. There are statistical and signal-specific features and they can be obtained from different ways of processing the signals. Features as mean and standard deviation are two examples of statistical features and they can be calculated for any biosignal. The signal-specific features or syntactic features are unique for each type of signal and can be derived from the geometry of the waveform [10]. Table 1 summarizes some works where different GSR features selection are made. 212

227 Concerning the ECG features, the Heart Rate (HR) is the most used when dealing with stress situations: HR variability has been considered as a stress marker in human body [11] [12]. Author Healey, J. et all June 2005 Alexander D. et all Jan 2005 Sun, Feng-Tso et all Jan 2010 Benedek M. et all Apr 2010 Singh, R.R. et all Oct 2011 Features Mean, variance, total number of the onset, sum of startle magnitude, response duration and estimated areas. On-set latency, rise time, peak amplitude. Mean and standard deviation, total number of startle responses in the segment, sum of response magnitude and response duration. On-set, amplitude peak, difference between amplitude peak and amplitude on-set. Six GSR statistical feature and nine GSR Syntactic Features. Table 1. GSR selection features 2.2 Stress detection systems In [2] the authors presented methods to assemble and analyze four biosignals during real-world driving tasks to determine a driver s stress level. Four types of physiological sensors were used during the experiment: electrocardiogram (ECG); electromyogram (EMG); skin conductivity (also known as galvanic skin response) and respiration. The sensors were connected to a FlexComp unit. In [13], a Nonin pulse oximeter, a GSR, a respiration and a Lead-II ECG sensory device were mounted in the driver body. These sensors communicated with a Mind Media BV s Nexus device and through it to an HP Compaq Tablet via IEEE (Bluetooth). The collected data is then processed offline in MATLAB. In [14], a real-time method to detect stress while driving was presented. The method was based on Bayesian theory, ECG, GSR and respiration signals, the Biopac MP- 100 system for stress sensors. Authors refer the usage of GPS and CAN (maybe the OBD-2 embedded interface standard in most cars) for environment extraction features. In [7], a fuzzy logic algorithm working on the HR and GSR signals was used. The signals were measured by the device I-330-C2 Physiolab (J & J Engineering). In this work the context was different from a driving situation. In all these related works, the sensors were connected with the processing unit by a significant amount of cables which could proportionate discomfort or limited movements to the subject. Also, in the majority of these works, the events detection is made by a co-pilot or by a questionnaire fulfillment. In [14], the annotation of stress events is done by a microphone and a voice recognition software. At this point, the purpose of this work is to merge the biosignals data collection and the registering of events in the same processing unit in order to make the system portable, reliable and simple to the user. For the moment, as it is described in the preliminary tests section, we focused our work in the vehicular navigation area. 213

228 3 System Overview The solution presented in this paper offers significant advantages as it works wirelessly and, in our opinion, it is very user-friendly. It can be adapted to various situations and it also permits that more persons use it on their own. This will help to create a larger and consistent database for subsequent stress analysis. This solution makes possible that the person uses the devices during daily routines without concerns. This is an extremely important issue because the influence on the stress level of the monitored persons will be reduced when compared to a laboratory test where he/she is conscious of being under constant observation. Car or powered wheelchair navigation are two examples of daily routines where this system can be applied. As all drivers know, for a driving experience, the conduction stress level depends largely on the volume of traffic. For example, in the case of a city, the stress level increases if there is traffic, pedestrians, traffic lights that require high concentration and almost spontaneous reaction by the driver. In the sequence of the work done in [3] it was verified with patients driving adapted powered wheelchairs (APWs) that the psychic condition affects and is affected by the way the wheelchairs users interact with their APW, which implies that a wheelchair control unit that works only on the base of environmental sensor data is not sufficient. In both cases, the car control system or the APW control system must have the capacity of processing sensors data in real time, reacting on unknown environmental situations, as well as reacting to the eventual changes of the wheelchair user s welfare. As figure 1 illustrates, the system consists in three main blocs: the person in which the wireless sensors are applied, the processing unit and the analyzing unit. The system s core is the processing unit which establishes a wireless communication with N sensors, registers occurrences and localizations (Global Positioning System) and, after, sends all acquired data to a database. Fig. 1. System Overview This database allows the analysing unit to extract the relevant biosignals features and to obtain graphical representation of the signals. This off-line processing allows also to import data from each person that belongs to the database and to observe which occurrences (marked by the processing unit during the experiment) were the origin of high stress levels. 214

229 Also, the database will be used to test algorithms for stress detection and classification such as Support Vector Machine (SVM), Fuzzy Logic or ANOVA Analyses [7]. After the algorithms have been tested, the system should be able to detect the user stress level in real time. 4 Technical Solution and ongoing work As a starting point, it was decided to measure only cardiac changes and the GSR signal because they contain reliable information about stress and, according to [7], it is possible to detect stress only by those signals. However, the use of a wireless network enables the easy addition of other sensors, if required, to better characterize the stress level. So, the proposed system architecture consists in a mobile application running in a tablet which communicates via Bluetooth with two different sensors placed in the person. Besides that, the application allows the user to register by voice or typing depending on the internet connection - an indeterminate number of occurrences that happen during the reading. The application gives the possibility to mark two types of occurrences: normal activities, which have a beginning and an end, and spontaneous events. As short examples, driving in a highway or in a city are normal activities and braking the car suddenly due to a pedestrian crossing the road is a spontaneous event. This will easily permit to associate certain events as origins of stress. When the tablet has Internet connection, the user can send all acquired data saved in a comma-separated values (csv) format - to Dropbox servers, specifically to the user space account that makes possible to access data everywhere in an easy way. Figure 3 illustrates each module of the solution. Fig. 2. Technical Solution 4.1 Data Acquisition The application runs on Android OS and, at this moment it, is used the tablet Asus Nexus 7 with Android 4.2. For marking occurrences by voice, it is used the Android speech recognition API, and, for each event, it is calculated the elapsed time between 215

230 the start of reading from sensors and the marking moment. To upload data to Dropbox, the application uses the Dropbox API. The wireless sensors used were developed by Shimmer Research being favorable to mobility situations. Each sensor incorporates an accelerometer, not used for now, and a Bluetooth module. These sensors can be easily configured. The GSR sensor has two inputs and is able to measure skin resistance levels with a resolution of 12 bits from 10kΩ to 4.7MΩ. The GSR sensor samples at 10Hz. The ECG sensor has three inputs (right-arm, left-arm and left-leg). It sends the values of lead II (right-arm, leftleg) and lead III (left-arm, left-leg) with the same resolution of the GSR sensor. These values are sampled at 250Hz which already gives a good signal quality in order to detect the typical PQRST wave. The value of lead I is calculated by software as well as the instantaneous heart rate in beats per minute (bpm). This is an important feature extracted from the ECG signal that can be included later in a real-time stress level algorithm. 4.2 Analyzing unit - feature Extraction The offline analysis of ECG and GSR biosignals is done using a Matlab interface specifically developed for this purpose. Using the open source BioSig project library [15], the instantaneous heart-rate and also its variability are extracted from the ECG signal. To analyse the GSR signal, the interface uses the free software Ledalab library [16] to extract the on-set and peak timings, allowing the measurement of relative amplitudes - difference Fig. 3. Matlab interface developed between peak and on-set amplitudes - and their rising-times. Additionally, a filter can be applied to detect only relative amplitudes above a chosen threshold. As is said in [17], the amplitude is the main clinical parameter of GSR due to its dependence on the surprise effect of the stress stimulus. Moreover, the interface list all occurrences that have been marked by the user in the Android application during the biosignals reading, with their elapsed times and easily permits to zoom specific temporal areas with a beginning and an end time. 216

231 Furthermore, maximum, minimum and averages of HR and GSR are calculated to each of these temporal regions, allowing a better recognition of human stress in several contexts as driving in different cities. 5 Preliminary tests For illustrative purposes, figure 4 shows the appearance of the Android application when it is in the modus operandi. Fig. 4. Appearance of the Android Application 5.1 Platform validation To validate this platform, two preliminary tests were done to check if it acquires data and registers occurrences properly. So the first test consisted in simulating some occurrences from both types at specific timings. The ECG sensor was normally placed in the body. The GSR sensor was used to create pulse responses by pulling-in and pulling-out fingers from the electrodes (the GSR electrodes are mounted as a sort of rings in two fingers). Using this procedure one pulse with a small duration was triggered for each occurrence in order to check the synchronism between the biosignal and the occurrences. In this test, it was followed the procedure described in the table 2. The Wi-Fi was turned off before starting the acquisition from the sensors and thus the occurrences a, b and c were registered by typing their letters. After activity b, the Wi-Fi was turned on to enable the voice registering mode in order to say the portuguese word experiência which means experiment. The experiment was stopped fifteen seconds after registering this last occurrence. Elapsed Times (ms) Occurrences Registering mode Spontaneous: a Typing Begin Activity: b Typing Spontaneous: c Typing End Activity: b Typing Spontaneous: experiência Voice Table 2. Platform validation procedure 217

232 Fig. 5. Results of the validation tests Figure 5 shows the skin conductivity signal and each registered occurrence marked with a vertical blue line. It is clear that the intended synchronism exists although it has to be remarked that there is a small delay see zoomed area - due to the human reaction when pressing the button. However, the delay was approximately 500ms for each step response which is not critical to associate the biosignal to an occurrence along the time. Concerning the data coming from the ECG sensor, it can be verified that the signals are acquired properly as shown in figure 6. The top graphic represents the Lead II (mv), the middle one is the heart-rate (bpm) calculated in real-time and the bottom one is the heart-rate (bpm) calculated by the Biosig function off-line. The elapsed time of the last skin conductivity sample was approximately ms and for the last ECG sample was approximately ms which are coherent with the expected value if the configured sampling rates and the time delay of pressing the button are taken into consideration. Also the name of registered occurrences were well marked specially the last one since it was done by voice. Fig. 6. Results of the validation tests The second test was to check how much time one experience could take before resources were exhausted. So, both sensors and the tablet were fully charged and a new experiment was started. Always with Wi-Fi off and no other applications running in parallel, some occurrences were marked to check again the same issues done in the first test and it was obtained the intended synchronism as before. The test started at 15:27 and it has to be terminated at 23:38 since it was the moment when the tablet only had 10% of battery left. So, it can be said that for outdoor experiments the system can only acquire data during a bit more than 8 hours approximately which is sufficient for vehicular context. 218

233 5.2 Tests in vehicular context After these validation tests, real car driving experiments with four different subjects were done in the city of Aveiro, all of them in different days, with the same routine, starting approximately at 11h00 in the morning with a duration of nearly 45 minutes. The experimental procedure was very simple: at the beginning the driver stayed five minutes in the car relaxing and trying to get used to the car; then he/she started to drive in the city for some minutes; the next step was to drive in a highway in direction to the beach named Barra, return back and finally do the inverse route, i. e. driving in the city and then park the car. The experiment was only finished after five minutes of relaxing seated in the car. The second city driving phase was shorter (about 2 minutes) when compared with the first. During all these phases, spontaneous events as traffic lights changes, pedestrian crossing road suddenly, passing roundabouts were marked by a co-pilot. Theoretically, it is expected that the stress level of persons is higher when driving in the city, lower in resting phases and intermediate in the highway. As an example, one of the results is in table 3. Concerning the number of detected (GSR) peaks, they were chosen to be above a threshold of 0.1µS. As expected, the heart-rate mean value is higher when the subject is in city phases. Analysing the mean value of the skin conductivity its evolution is similar to the heart-rate. --- Rest 1 City 1 Highway City 2 Rest 2 Mean HR (bpm) Maximum HR (bpm) Minimum HR (bpm) Mean Conductivity (µs) Max. Conductivity (µs) Min. Conductivity (µs) Number Detected Peaks Mean Peaks Amplitude (µs) Mean Peaks Rising Time (s) Table 3. Global results of one subject In order to make a comparison between all subjects, the table 4 shows, for each driver, the values of the entire experience: mean of heart-rate, total number of detected peaks above the previous mentioned threshold, mean amplitude and rising times of all peaks. --- Driver 1 Driver 2 Driver 3 Driver 4 Mean HR (bpm) Total Number of Peaks Mean All Peaks Amplitude (µs) Mean All Peaks Rising Time (s) Table 4. Comparison between all subjects 219

234 It is concluded that drivers 1 and 2 present higher heart-rate mean values, total number of peaks as well as mean amplitude of peaks. On the other hand, drivers 3 and 4 present the higher rising time. This seems that the adaptation to stress responses differs from person to person. Some examples of occurrences that were happening during the driving are shown in figure 7: green traffic-light and pedestrian crossing the road. Figure 8 illustrates three events: green traffic-light, roundabout and a crossing with another car. Figures 7 and 8 show that the relevant events can be identified by the GSR signal and that some of them cause more stress. Those are the ones that intuitively would indeed justify the stress state in the driver. The tests presented enabled us to verify that it is simple to equip drivers with this acquisition system even when it is in a preliminary version as the current one. Fig. 7. Association occurrences-biosignal (GSR)1 Fig. 8. Association occurrences-biosignal (GSR)2 We believe then that, through the use of probe vehicles in which drivers are willing to be monitored, it will be possible to identify the road spots that cause systematically more stress to drivers. These are normally called black spots when systematic accidents occur and in this case they can be identified before accidents happen. It should be referred that this work has connections with the European Project ICSIS that deals with vehicular communications and looks in particular to the WAVE and p standard as the possible technology to be adopted in this field. In this case, the data obtained by the probe vehicles can be immediately uploaded to a server where it can be processed and used to increase the driver s safety. 220

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Tese / Thesis Work Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Licenciatura em Engenharia Informática Degree in Computer Science Engineering Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java Performance analysis of large distributed

Leia mais

Digital Cartographic Generalization for Database of Cadastral Maps

Digital Cartographic Generalization for Database of Cadastral Maps Mariane Alves Dal Santo marianedalsanto@udesc.br Francisco Henrique de Oliveira chicoliver@yahoo.com.br Carlos Loch cloch@ecv.ufsc.br Laboratório de Geoprocessamento GeoLab Universidade do Estado de Santa

Leia mais

INFORMATION SECURITY IN ORGANIZATIONS

INFORMATION SECURITY IN ORGANIZATIONS INFORMATION SECURITY IN ORGANIZATIONS Ana Helena da Silva, MCI12017 Cristiana Coelho, MCI12013 2 SUMMARY 1. Introduction 2. The importance of IT in Organizations 3. Principles of Security 4. Information

Leia mais

A Cloud Computing Architecture for Large Scale Video Data Processing

A Cloud Computing Architecture for Large Scale Video Data Processing Marcello de Lima Azambuja A Cloud Computing Architecture for Large Scale Video Data Processing Dissertação de Mestrado Dissertation presented to the Postgraduate Program in Informatics of the Departamento

Leia mais

Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures

Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures GeoInfo - 2006 Interoperability through Web Services: Evaluating OGC Standards in Client Development for Spatial Data Infrastructures Leonardo Lacerda Alves Clodoveu A. Davis Jr. Information Systems Lab

Leia mais

Project Management Activities

Project Management Activities Id Name Duração Início Término Predecessoras 1 Project Management Activities 36 dias Sex 05/10/12 Sex 23/11/12 2 Plan the Project 36 dias Sex 05/10/12 Sex 23/11/12 3 Define the work 15 dias Sex 05/10/12

Leia mais

CMDB no ITIL v3. Miguel Mira da Silva. mms@ist.utl.pt 919.671.425

CMDB no ITIL v3. Miguel Mira da Silva. mms@ist.utl.pt 919.671.425 CMDB no ITIL v3 Miguel Mira da Silva mms@ist.utl.pt 919.671.425 1 CMDB v2 Configuration Management IT components and the services provided with them are known as CI (Configuration Items) Hardware, software,

Leia mais

Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas)

Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas) Information technology specialist (systems integration) Especialista em tecnologia da informação (integração de sistemas) Professional activities/tasks Design and produce complex ICT systems by integrating

Leia mais

ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS

ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS ESTRUTURA DE CAPITAL: UMA ANÁLISE EM EMPRESAS SEGURADORAS THE CAPITAL STRUCTURE: AN ANALYSE ON INSURANCE COMPANIES FREDERIKE MONIKA BUDINER METTE MARCO ANTÔNIO DOS SANTOS MARTINS PAULA FERNANDA BUTZEN

Leia mais

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5

Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Course Computer Science Academic year 2012/2013 Subject Social Aspects of Computers ECTS 5 Type of course Compulsory Year 2º Semester 2nd sem Student Workload: Professor(s) Natalia Gomes, Ascensão Maria

Leia mais

Easy Linux! FUNAMBOL FOR IPBRICK MANUAL. IPortalMais: a «brainware» company www.iportalmais.pt. Manual

Easy Linux! FUNAMBOL FOR IPBRICK MANUAL. IPortalMais: a «brainware» company www.iportalmais.pt. Manual IPortalMais: a «brainware» company FUNAMBOL FOR IPBRICK MANUAL Easy Linux! Title: Subject: Client: Reference: Funambol Client for Mozilla Thunderbird Doc.: Jose Lopes Author: N/Ref.: Date: 2009-04-17 Rev.:

Leia mais

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco

Software product lines. Paulo Borba Informatics Center Federal University of Pernambuco Software product lines Paulo Borba Informatics Center Federal University of Pernambuco Software product lines basic concepts Paulo Borba Informatics Center Federal University of Pernambuco Um produto www.usm.maine.edu

Leia mais

User interface evaluation experiences: A brief comparison between usability and communicability testing

User interface evaluation experiences: A brief comparison between usability and communicability testing User interface evaluation experiences: A brief comparison between usability and communicability testing Kern, Bryan; B.S.; The State University of New York at Oswego kern@oswego.edu Tavares, Tatiana; PhD;

Leia mais

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho

Banca examinadora: Professor Paulo N. Figueiredo, Professora Fátima Bayma de Oliveira e Professor Joaquim Rubens Fontes Filho Título: Direção e Taxa (Velocidade) de Acumulação de Capacidades Tecnológicas: Evidências de uma Pequena Amostra de Empresas de Software no Rio de Janeiro, 2004 Autor(a): Eduardo Coelho da Paz Miranda

Leia mais

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS

TURMA 10 H. CURSO PROFISSIONAL DE: Técnico de Multimédia RELAÇÃO DE ALUNOS Técnico de Multimédia 10 H 7536 Alberto Filipe Cardoso Pinto 7566 Ana Isabel Lomar Antunes 7567 Andreia Carine Ferreira Quintela 7537 Bruno Manuel Martins Castro 7538 Bruno Miguel Ferreira Bogas 5859 Bruno

Leia mais

DPI. Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office

DPI. Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office DPI Núcleo de Apoio ao Desenvolvimento de Projetos e Internacionalização Project Development And Internationalization Support Office Apresentação/Presentation Criado em 1 de março de 2011, o Núcleo de

Leia mais

Geração automática de suíte de teste para GUI a partir de Rede de Petri

Geração automática de suíte de teste para GUI a partir de Rede de Petri Raquel Jauffret Guilhon Geração automática de suíte de teste para GUI a partir de Rede de Petri Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo

Leia mais

design para a inovação social

design para a inovação social design para a inovação social mestrado em design - 15 16 universidade de aveiro gonçalo gomes março de 2016 s.1 ergonomia ergonomia > definição Ergonomia A ergonomia (do grego "ergon": trabalho; e "nomos":

Leia mais

T Ã O B O M Q U A N T O N O V O

T Ã O B O M Q U A N T O N O V O D I S S E R T A Ç Ã O D E M E S T R A D O M A S T E R I N G D I S S E R T A T I O N A V A L I A Ç Ã O D A C O N D I Ç Ã O D E T Ã O B O M Q U A N T O N O V O U M A A P L I C A Ç Ã O E N V O L V E N D O

Leia mais

Institutional Skills. Sessão informativa INSTITUTIONAL SKILLS. Passo a passo. www.britishcouncil.org.br

Institutional Skills. Sessão informativa INSTITUTIONAL SKILLS. Passo a passo. www.britishcouncil.org.br Institutional Skills Sessão informativa INSTITUTIONAL SKILLS Passo a passo 2 2 British Council e Newton Fund O British Council é a organização internacional do Reino Unido para relações culturais e oportunidades

Leia mais

ESCOLA E.B. 2,3 DE LAMAÇÃES 2013-2014

ESCOLA E.B. 2,3 DE LAMAÇÃES 2013-2014 5º1 1 ANA CATARINA R FREITAS SIM 2 BEATRIZ SOARES RIBEIRO SIM 3 DIOGO ANTÓNIO A PEREIRA SIM 4 MÁRCIO RAFAEL R SANTOS SIM 5 MARCO ANTÓNIO B OLIVEIRA SIM 6 NÁDIA ARAÚJO GONÇALVES SIM 7 SUNNY KATHARINA G

Leia mais

Métodos Formais em Engenharia de Software. VDMToolTutorial

Métodos Formais em Engenharia de Software. VDMToolTutorial Métodos Formais em Engenharia de Software VDMToolTutorial Ana Paiva apaiva@fe.up.pt www.fe.up.pt/~apaiva Agenda Install Start Create a project Write a specification Add a file to a project Check syntax

Leia mais

egovernment The Endless Frontier

egovernment The Endless Frontier CENTRO DE GESTÃO DA REDE INFORMÁTICA DO GOVERNO (Management Center for the Electronic Government Network) egovernment The Endless Frontier Alexandre Caldas 29 th June 2010 Summary VISION AND LEADERSHIP

Leia mais

Analysis, development and monitoring of business processes in Corporate environment

Analysis, development and monitoring of business processes in Corporate environment Analysis, development and monitoring of business processes in Corporate environment SAFIRA is an IT consulting boutique known for transforming the way organizations do business, or fulfil their missions,

Leia mais

INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL

INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL INTRODUÇÃO ÀS BOAS PRÁTICAS DE ENGENHARIA APLICADAS À GESTÃO DOS SISTEMAS INSTRUMENTADOS DE SEGURANÇA: UMA ABORDAGEM DE SIL Ana Cristina Costa Almeida Risk and Reliability Senior Consultant DNV Energy

Leia mais

Normalização e interoperabilidade da informação geográfica

Normalização e interoperabilidade da informação geográfica Normalização e interoperabilidade da informação geográfica perspetivas para a formação em Engenharia Geográfica João Catalão Departamento de Engenharia Geográfica, Geofísica e Energia Faculdade de Ciências

Leia mais

Corrida da Saúde. Infantis A - Feminino

Corrida da Saúde. Infantis A - Feminino Corrida da Saúde Classificação geral do corta-mato, realizado no dia 23 de Dezembro de 2007, na Escola E.B. 2,3 de Valbom. Contou com a participação dos alunos do 4º ano e do 2º e 3º ciclos do Agrupamento

Leia mais

Ministério da Ciência, Tecnologia e Ensino Superio Resultados da 1ª Fase do Concurso Nacional de Acesso de 2011

Ministério da Ciência, Tecnologia e Ensino Superio Resultados da 1ª Fase do Concurso Nacional de Acesso de 2011 14286394 ALBANO LUIS ANDRADE PEREIRA Não colocado 14388714 ANA BEATRIZ MARTINS MACHADO Colocada em 3133 9104 14371141 ANA CATARINA MOREIRA LEAL Colocada em 7003 14319342 ANA CATARINA SOUSA RIBEIRO Colocada

Leia mais

Transportes. Transportation. Semestre do plano de estudos 1

Transportes. Transportation. Semestre do plano de estudos 1 Nome UC Transportes CU Name Código UC 706 Curso MEC Semestre do plano de estudos 1 Área científica Engenharia Civil Duração Semestral Horas de trabalho 120 ECTS 4.5 Horas de contacto T - 22,5; TP - 22,5

Leia mais

MIT Portugal Program Engineering systems in action

MIT Portugal Program Engineering systems in action MIT Portugal Program Engineering systems in action Paulo Ferrão, MPP Director in Portugal Engineering Systems: Achievements and Challenges MIT, June 15-17, 2009 Our knowledge-creation model An Engineering

Leia mais

151713 - Agrupamento de Escolas de Mosteiro e Cávado 346652 - Escola E.B.2,3 do Cávado. Relação de Alunos

151713 - Agrupamento de Escolas de Mosteiro e Cávado 346652 - Escola E.B.2,3 do Cávado. Relação de Alunos 3452 - Escola E.B.2,3 do Cávado : A 137 1 Adriana Manuela Gomes Pinheiro 14 S S 20 2 Alexandra Pereira Ferreira 28 3 Ângelo Rafael Araújo Gomes S 28 4 Beatriz da Costa Oliveira S 2 5 Domingos Gonçalo Ferreira

Leia mais

Desenvolvimento Ágil 1

Desenvolvimento Ágil 1 Desenvolvimento Ágil 1 Just-in-Time Custo = Espaço + Publicidade + Pessoal De que forma poderiamos bater a concorrência se um destes factores fosse zero? 2 Just-in-time Inventory is waste. Custo de armazenamento

Leia mais

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012

Universidade do Minho. Escola de Engenharia. UC transversais Programas Doutorais 1º semestre 2012-13. 11 de outubro 2012 Universidade do Minho Escola de Engenharia UC transversais Programas Doutorais 1º semestre 2012-13 11 de outubro 2012 1 2 2 courses offered in the first semestre: Métodos de Investigação em Engenharia

Leia mais

Interactive Internet TV Architecture Based on Scalable Video Coding

Interactive Internet TV Architecture Based on Scalable Video Coding Interactive Internet TV Architecture Based on Scalable Video Coding Pedro Gomes Moscoso Dissertação para obtenção do Grau de Mestre em Engenharia de Redes de Comunicações Presidente: Orientador: Co-Orientador:

Leia mais

ISO 9001:2015 e ISO 14001:2015 versão DIS Principais alterações

ISO 9001:2015 e ISO 14001:2015 versão DIS Principais alterações ISO 9001:2015 e ISO 14001:2015 versão DIS Principais alterações Raquel Silva 02 Outubro 2014 ISO 9001:2015 e ISO 14001:2015 ISO 9001:2015 e ISO 14001:2015 PUBLICAÇÃO DIS: - Draft International Standard

Leia mais

Easy Linux! FUNAMBOL FOR IPBRICK MANUAL. IPortalMais: a «brainmoziware» company www.iportalmais.pt. Manual Jose Lopes

Easy Linux! FUNAMBOL FOR IPBRICK MANUAL. IPortalMais: a «brainmoziware» company www.iportalmais.pt. Manual Jose Lopes IPortalMais: a «brainmoziware» company www.iportalmais.pt FUNAMBOL FOR IPBRICK MANUAL Easy Linux! Title: Subject: Client: Reference: Funambol Client for Microsoft Outlook Doc.: Author: N/Ref.: Date: 2009-04-17

Leia mais

UNIVERSIDADE DE LISBOA FACULDADE DE LETRAS SECRETARIADO DE CIÊNCIAS DOCUMENTAIS

UNIVERSIDADE DE LISBOA FACULDADE DE LETRAS SECRETARIADO DE CIÊNCIAS DOCUMENTAIS UNIVERSIDADE DE LISBOA FACULDADE DE LETRAS SECRETARIADO DE CIÊNCIAS DOCUMENTAIS A WEB 2.0 NAS BIBLIOTECAS UNIVERSITÁRIAS PORTUGUESAS: UM ESTUDO DA IMPLEMENTAÇÃO DO PARADIGMA DA BIBLIOTECA 2.0 Helena Sofia

Leia mais

BIBLIOGRAFIA. Faupel, A. & Sharp, P. (2003). Promoting emotional literacy. Guidelines for schools, local authorities and

BIBLIOGRAFIA. Faupel, A. & Sharp, P. (2003). Promoting emotional literacy. Guidelines for schools, local authorities and RESUMO EXPANDIDO Pode definir-se Literacia Emocional como a capacidade para reconhecer, compreender, expressar e gerir estados emocionais, do próprio e de outras pessoas, existindo associações entre esta

Leia mais

NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos

NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos NCE/10/00806 Decisão de apresentação de pronúncia - Novo ciclo de estudos Decisão de Apresentação de Pronúncia ao Relatório da

Leia mais

RESULTADOS. Nome Global ( /100) PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1

RESULTADOS. Nome Global ( /100) PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1 PT1840719 ADÃO AZEVEDO MALHEIRO MATOS BARBOSA 94 B1 PT1840720 ADRIANA MORAIS SOUSA 52 A1 PT1840721 ADRIANA XAVIER DA SILVA FERNANDES 38 Pré-A1 PT1840722 ALEXANDRA FILIPA AZEVEDO SANTOS 52 A1 PT1840723

Leia mais

Serviços: API REST. URL - Recurso

Serviços: API REST. URL - Recurso Serviços: API REST URL - Recurso URLs reflectem recursos Cada entidade principal deve corresponder a um recurso Cada recurso deve ter um único URL Os URLs referem em geral substantivos URLs podem reflectir

Leia mais

ALCATEIA ACAGRUP 2014 - SIERRA NORTE - MADRID - ESPANHA PARTICIPANTES: 26 60% INCIDÊNCIA NO GRUPO 20%

ALCATEIA ACAGRUP 2014 - SIERRA NORTE - MADRID - ESPANHA PARTICIPANTES: 26 60% INCIDÊNCIA NO GRUPO 20% ALCATEIA Sec NIN NOME NIN NOME Lob 1215050143005 Alice Neto Santos Nascimento 1215050143015 Afonso da Fonseca Machado Lob 1215050143010 Amélia Maria Mesquita Aleixo Alves 1115050143010 Afonso Jesus Dias

Leia mais

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt.

NORMAS PARA AUTORES. As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. NORMAS PARA AUTORES As normas a seguir descritas não dispensam a leitura do Regulamento da Revista Portuguesa de Marketing, disponível em www.rpm.pt. COPYRIGHT Um artigo submetido à Revista Portuguesa

Leia mais

CENTRO UNIVERSITÁRIO METROPOLITANO DE SÃO PAULO CURSO ADMINISTRAÇÃO DE EMPRESAS

CENTRO UNIVERSITÁRIO METROPOLITANO DE SÃO PAULO CURSO ADMINISTRAÇÃO DE EMPRESAS CENTRO UNIVERSITÁRIO METROPOLITANO DE SÃO PAULO CURSO ADMINISTRAÇÃO DE EMPRESAS UMA VANTAGEM COMPETITIVA COM A TERCEIRIZAÇÃO DE SERVIÇOS AMANDA ZADRES DANIELA LILIANE ELIANE NUNES ELISANGELA MENDES Guarulhos

Leia mais

Luciana da Silva Almendra Gomes. Proveniência para Workflows de Bioinformática

Luciana da Silva Almendra Gomes. Proveniência para Workflows de Bioinformática Luciana da Silva Almendra Gomes Proveniência para Workflows de Bioinformática Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do título de Mestre pelo Programa de Pós-

Leia mais

UNIVERSIDADE CATÓLICA PORTUGUESA. A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação. Por. Ana Margarida Nisa Vintém

UNIVERSIDADE CATÓLICA PORTUGUESA. A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação. Por. Ana Margarida Nisa Vintém UNIVERSIDADE CATÓLICA PORTUGUESA A Reputação e a Responsabilidade Social na BP Portugal: A importância da Comunicação Relatório de estágio apresentado à Universidade Católica Portuguesa para obtenção do

Leia mais

Design de Armazéns: uma revisão sistemática da literatura.

Design de Armazéns: uma revisão sistemática da literatura. Nayara Nogueira da Costa Design de Armazéns: uma revisão sistemática da literatura. Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa

Leia mais

Integrated Network Operations Support System ISO 9001 Certified A Plataforma Integradora Integrated Platform O INOSS V2 é uma poderosa plataforma de operação e gestão centralizada de redes e serviços de

Leia mais

CIRCUITO PORTUGAL TOUR 2015 4ª ETAPA BIATLE - ABRANTES - 04.07.2015. APRENDIZ - 2007 + NOVOS Prova- corrida 200 mts + natação 50 mts + corrida 200 mts

CIRCUITO PORTUGAL TOUR 2015 4ª ETAPA BIATLE - ABRANTES - 04.07.2015. APRENDIZ - 2007 + NOVOS Prova- corrida 200 mts + natação 50 mts + corrida 200 mts CIRCUITO PORTUGAL TOUR 0 ª ETAPA BIATLE - ABRANTES - 0.0.0 APRENDIZ - 00 + NOVOS Prova- corrida 00 mts + natação 0 mts + corrida 00 mts A LUISA CUNHA Casa Benfica de Abrantes 00 0:: A0 INÊS IACHIMOVSCHI

Leia mais

JOSE GABRIEL REGO. Resumo. Especializações. Experiência. Assistant Card Manager at Grupo Banco Popular jgrego@netcabo.pt

JOSE GABRIEL REGO. Resumo. Especializações. Experiência. Assistant Card Manager at Grupo Banco Popular jgrego@netcabo.pt JOSE GABRIEL REGO jgrego@netcabo.pt Resumo My main objective is to develop my career in order to deepen the experience I accumulated over the years based in the development of practical and theoretical

Leia mais

UNIVERSIDADE DE ÉVORA

UNIVERSIDADE DE ÉVORA UNIVERSIDADE DE ÉVORA MESTRADO EM INTERVENÇÃO SÓCIO-ORGANIZACIONÀL NA SAÚDE Curso ministrado em parceria com a Escola Superior de Tecnologia da Saúde de Lisboa (DR Série, n.. 250 de 29 de Outubro de 2002)

Leia mais

Ministério da Ciência, Tecnologia e Ensino Resultados da 2ª Fase do Concurso Nacional de Acesso de 2011

Ministério da Ciência, Tecnologia e Ensino Resultados da 2ª Fase do Concurso Nacional de Acesso de 2011 14320023 ALEXANDRE VAZ MARQUES VASCONCELOS Colocado em 1105 Universidade do Porto - Faculdade de Engenharia 9897 Ciências de Engenharia - Engenharia de Minas e Geoambiente 13840715 ANA CLÁUDIA DIAS MARTINS

Leia mais

METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO

METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO METODOLOGIA DE AVALIAÇÃO DAS STARTUPS DO MIDI TECNOLÓGICO RESUMO As incubadoras de empresas são ambientes dotados de competência gerencial, técnica e administrativa que impulsionam a promoção do nascimento

Leia mais

Multicriteria Impact Assessment of the certified reference material for ethanol in water

Multicriteria Impact Assessment of the certified reference material for ethanol in water Multicriteria Impact Assessment of the certified reference material for ethanol in water André Rauen Leonardo Ribeiro Rodnei Fagundes Dias Taiana Fortunato Araujo Taynah Lopes de Souza Inmetro / Brasil

Leia mais

Simulação Gráfica e Visão Computacional. Soraia Raupp Musse

Simulação Gráfica e Visão Computacional. Soraia Raupp Musse Simulação Gráfica e Visão Computacional Soraia Raupp Musse Objetivo Analisar exemplos comerciais e do estado-da-arte científicos que utilizam dados reais para aprimorar a qualidade de simulações e animações.

Leia mais

USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 USPTO No. 15143095 WORK PLAN FOR IMPLEMENTATION OF THE UNITED STATES PATENT AND

Leia mais

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional!

A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! ii A meus pais, Ari e Célia, sempre presentes, todo o meu amor incondicional! iii Agradeço à Deus, esta força maior, pela vida, pela sabedoria e pelo amor. Mas, sobretudo, por me ensinar saber fazer ser

Leia mais

Software reliability analysis by considering fault dependency and debugging time lag Autores

Software reliability analysis by considering fault dependency and debugging time lag Autores Campos extraídos diretamente Título Software reliability analysis by considering fault dependency and debugging time lag Autores Huang, Chin-Yu and Lin, Chu-Ti Ano de publicação 2006 Fonte de publicação

Leia mais

A tangibilidade de um serviço de manutenção de elevadores

A tangibilidade de um serviço de manutenção de elevadores A tangibilidade de um serviço de manutenção de elevadores Tese de Mestrado em Gestão Integrada de Qualidade, Ambiente e Segurança Carlos Fernando Lopes Gomes INSTITUTO SUPERIOR DE EDUCAÇÃO E CIÊNCIAS Fevereiro

Leia mais

MFIG - TRABALHO Codigo Nome turma Nota Trabalho 110402106 Adriana Castro Valente 2 15,0 110402107 Alex da Silva Carvalho 3 14,9 70402122 Alexandre

MFIG - TRABALHO Codigo Nome turma Nota Trabalho 110402106 Adriana Castro Valente 2 15,0 110402107 Alex da Silva Carvalho 3 14,9 70402122 Alexandre MFIG - TRABALHO Codigo Nome turma Nota Trabalho 110402106 Adriana Castro Valente 2 15,0 110402107 Alex da Silva Carvalho 3 14,9 70402122 Alexandre Jorge Costelha Seabra 2 18,2 110402182 Ana Catarina Linhares

Leia mais

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law

e-lab: a didactic interactive experiment An approach to the Boyle-Mariotte law Sérgio Leal a,b, João Paulo Leal a,c Horácio Fernandes d a Departamento de Química e Bioquímica, FCUL, Lisboa, Portugal b Escola Secundária com 3.º ciclo Padre António Vieira, Lisboa, Portugal c Unidade

Leia mais

Lista de Contactos do Departamento de Engenharia Informática

Lista de Contactos do Departamento de Engenharia Informática Lista de Contactos do Departamento de Engenharia Informática Gabinete/Cargo Nome Extensão E-mail Diretor Luiz Felipe Rocha de Faria 1450 lef@isep.ipp.pt Sub-diretor(es) António Constantino Lopes 1462 acm@isep.ipp.pt

Leia mais

Addition of Fields in Line Item Display Report Output for TCode FBL1N/FBL5N

Addition of Fields in Line Item Display Report Output for TCode FBL1N/FBL5N Addition of Fields in Line Item Display Report Output for TCode FBL1N/FBL5N Applies to: Any business user who uses the transactions FBL1N and FBL5N to display line item reports for vendors and customers.

Leia mais

COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA

COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA COMÉRCIO INTERNACIONAL CURSO DE ECONOMIA CLASSIFICAÇÕES DO SEGUNDO TESTE E DA AVALIAÇÃO CONTINUA Classificações Classificação Final Alex Santos Teixeira 13 13 Alexandre Prata da Cruz 10 11 Aleydita Barreto

Leia mais

A. Situação / Situation

A. Situação / Situation A. Situação / Situation A Assembleia Mundial da Saúde (OMS) aprova em 1969 o Regulamento Sanitário Internacional, revisto pela quarta vez em 2005. Esta última versão entrou em vigor no plano internacional

Leia mais

Solicitação de Mudança 01

Solicitação de Mudança 01 Solicitação de Mudança 01 Refatorar a especificação da linha de produtos Crisis Management System permitindo que o suporte ao registro de LOG seja opcional. Isso significa que o comportamento descrito

Leia mais

Wiki::Score A Collaborative Environment For Music Transcription And Publishing

Wiki::Score A Collaborative Environment For Music Transcription And Publishing Wiki::Score A Collaborative Environment For Music Transcription And Publishing J.J. Almeida 1 N.R. Carvalho 1 J.N. Oliveira 1 1 Department of Informatics, University of Minho {jj,narcarvalho,jno}@di.uminho.pt

Leia mais

LISTA ORDENADA POR GRADUAÇÃO PROFISSIONAL - DGAE

LISTA ORDENADA POR GRADUAÇÃO PROFISSIONAL - DGAE Nome da Escola : Agrupamento de Escolas de Almancil, Loulé Horário n.º: 27-18 horas 2013-10-09 Grupo de Recrutamento: 420 - Geografia LISTA ORDENADA POR GRADUAÇÃO PROFISSIONAL - DGAE Ordenação Graduação

Leia mais

ONLINE SUBMISSION Revisor

ONLINE SUBMISSION Revisor ONLINE SUBMISSION Revisor O Brazilian Journal of Medical and Biological Research é parcialmente financiado por: LOG IN Log In REVISOR Brazilian Journal of Medical and Biological O Brazilian Journal Research

Leia mais

APRESENTAÇÃO. ABNT CB-3 Comitê Brasileiro de Eletricidade Comissão de Estudo CE 03:064.01 Instalações Elétricas de Baixa Tensão NBR 5410

APRESENTAÇÃO. ABNT CB-3 Comitê Brasileiro de Eletricidade Comissão de Estudo CE 03:064.01 Instalações Elétricas de Baixa Tensão NBR 5410 APRESENTAÇÃO ABNT CB-3 Comitê Brasileiro de Eletricidade Comissão de Estudo CE 03:064.01 Instalações Elétricas de Baixa Tensão NBR 5410 Instalações elétricas de baixa tensão NBR 5410:1997 NBR 5410:2004

Leia mais

Curso CP100A - Google Cloud Platform Fundamentals (8h)

Curso CP100A - Google Cloud Platform Fundamentals (8h) Curso CP100A - Google Cloud Platform Fundamentals (8h) Este curso virtual liderado por um instrutor, com 8 horas de duração, introduz os participantes aos produtos e serviços do Google Cloud Platform.

Leia mais

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16

Mestrado em Ciências Jurídicas Especialização em História do Direito 2015-16 Mestrado em Ciências Jurídicas Especialização em História do Direito Unidade curricular História do Direito Português I (1º sem). Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais

MT BOOKING SYSTEM BACKOFFICE. manual for management

MT BOOKING SYSTEM BACKOFFICE. manual for management MT BOOKING SYSTEM BACKOFFICE manual for management BACKOFFICE BACKOFFICE Últimas Reservas Latest Bookings 8 7 6 3 2 2 Configurações Configuration - pag. 3 Barcos Boats - pag.8 Pessoal Staff - pag.0 Agentes

Leia mais

Semestre do plano de estudos 1

Semestre do plano de estudos 1 Nome UC Inglês CU Name Código UC 6 Curso LEC Semestre do plano de estudos 1 Área científica Gestão Duração Semestral Horas de trabalho 54 ECTS 2 Horas de contacto TP - 22,5 Observações n.a. Docente responsável

Leia mais

Escola sede: Escola Secundária de S. Pedro do Sul Alunos Matriculados - 2015/2016

Escola sede: Escola Secundária de S. Pedro do Sul Alunos Matriculados - 2015/2016 13948 5 A 2.º Ciclo do Ensino Básico Ana Gabriela Pedro Fernandes Escola Básica n.º 2 de São Pedro do Sul 13933 5 A 2.º Ciclo do Ensino Básico Ana Júlia Capela Pinto Escola Básica n.º 2 de São Pedro do

Leia mais

Participatory Map of Rio de Janeiro

Participatory Map of Rio de Janeiro Leandro Gomes Souza Geographer Luiz Roberto Arueira da Silva Director of City Information Pereira Passos Institute - City of Rio de Janeiro About us Pereira Passos Institute (IPP) is Rio de Janeiro municipal

Leia mais

OVERVIEW DO EAMS. Enterprise Architecture Management System 2.0

OVERVIEW DO EAMS. Enterprise Architecture Management System 2.0 OVERVIEW DO EAMS Enterprise Architecture Management System 2.0 NETWORKS @arqcorp_br #eamsrio http://arquiteturacorporativa.wordpress.com/ WE MANAGE KNOWLEDGE, WITH YOU Arquitetura Empresarial Repositório

Leia mais

UNIVERSIDADE FEDERAL DO AMAZONAS DEPARTAMENTO DE COMUNICAÇÃO SOCIAL PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS DA COMUNICAÇÃO

UNIVERSIDADE FEDERAL DO AMAZONAS DEPARTAMENTO DE COMUNICAÇÃO SOCIAL PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS DA COMUNICAÇÃO UNIVERSIDADE FEDERAL DO AMAZONAS DEPARTAMENTO DE COMUNICAÇÃO SOCIAL PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS DA COMUNICAÇÃO A VEICULAÇÃO, CIRCULAÇÃO E QUALIDADE DAS INFORMAÇÕES SOBRE CIÊNCIA NOS BLOGS BRASILEIROS

Leia mais

MESTRADOS E DOUTORAMENTOS - 2015

MESTRADOS E DOUTORAMENTOS - 2015 MESTRADOS E DOUTORAMENTOS - 2015 2ª FASE - ECT SUPLENTE EXCLUÍDO LISTA DE CANDIDATOS SERIAÇÃO CARLA MARIA CARNEIRO ALVES Doutoramento em Didática de Ciências e Tecnologias 3,9 de 5 4 CARLOS EDUARDO DOS

Leia mais

Criando diferenciais competitivos e minimizando riscos com uma boa. Claudio Yamashita Country Manager Intralinks Brasil

Criando diferenciais competitivos e minimizando riscos com uma boa. Claudio Yamashita Country Manager Intralinks Brasil Criando diferenciais competitivos e Informação minimizando riscos com uma boa Governança da Claudio Yamashita Country Manager Intralinks Brasil PESQUISA GLOBAL DE SEGURANÇA DA INFORMAÇÃO 2014 - EY Pensando

Leia mais

Dealing with Device Data Overflow in the Cloud

Dealing with Device Data Overflow in the Cloud Jaumir Valença da Silveira Junior Dealing with Device Data Overflow in the Cloud Dissertação de Mestrado Dissertation presented to the Programa de Pós- Graduação em Informática of the Departamento de Informática,

Leia mais

Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios

Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios UNIVERSIDADE DE LISBOA FACULDADE DE LETRAS DEPARTAMENTO DE GEOGRAFIA Capital Humano e Capital Social: Construir Capacidades para o Desenvolvimento dos Territórios Sandra Sofia Brito da Silva Dissertação

Leia mais

Universidade do Porto

Universidade do Porto O Estado da Arte em Projectos de Investimento - A Importância da Análise Não Financeira Na Prática das Empresas Portuguesas Nuno Filipe Lopes Moutinho Tese de Mestrado em Ciências Empresariais Área de

Leia mais

aelousada.net AE Lousada Ministério da Educação e Ciência Resultados da 2ª Fase do Concurso Nacional de Acesso de 2014

aelousada.net AE Lousada Ministério da Educação e Ciência Resultados da 2ª Fase do Concurso Nacional de Acesso de 2014 ALBERTINO CLÁUDIO DE BESSA VIEIRA Colocado em 3138 Instituto Politécnico do Porto - Escola Superior de Tecnologia e Gestão de Felgueiras ALBERTO RAFAEL SILVA PEIXOTO Colocado em 3064 Instituto Politécnico

Leia mais

CULTURAS, POLÍTICAS E PRÁTICAS INCLUSIVAS NO SECTOR PÚBLICO E PRIVADO UM ESTUDO DE CASO EM DUAS ESCOLAS DO 1.º CICLO, DO CONCELHO DE SINTRA

CULTURAS, POLÍTICAS E PRÁTICAS INCLUSIVAS NO SECTOR PÚBLICO E PRIVADO UM ESTUDO DE CASO EM DUAS ESCOLAS DO 1.º CICLO, DO CONCELHO DE SINTRA UNIVERSIDADE TÉCNICA DE LISBOA FACULDADE DE MOTRICIDADE HUMANA CULTURAS, POLÍTICAS E PRÁTICAS INCLUSIVAS NO SECTOR PÚBLICO E PRIVADO UM ESTUDO DE CASO EM DUAS ESCOLAS DO 1.º CICLO, DO CONCELHO DE SINTRA

Leia mais

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática

UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO. Diálogo e interatividade em videoaulas de matemática UNIVERSIDADE DE SÃO PAULO FACULDADE DE EDUCAÇÃO JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática São Paulo 2010 JOÃO FÁBIO PORTO Diálogo e interatividade em videoaulas de matemática

Leia mais

Informática e Programação. Computer Science and Programming. Semestre do plano de estudos 1

Informática e Programação. Computer Science and Programming. Semestre do plano de estudos 1 Nome UC Informática e Programação CU Name Código UC 4 Curso LEC Semestre do plano de estudos 1 Área científica Informática Duração Semestral Horas de trabalho 135 ECTS 5 Horas de contacto TP - 67,5 Observações

Leia mais

Ficha de unidade curricular Curso de Doutoramento

Ficha de unidade curricular Curso de Doutoramento Ficha de unidade curricular Curso de Doutoramento Unidade curricular História do Direito Português I (Doutoramento - 1º semestre) Docente responsável e respectiva carga lectiva na unidade curricular Prof.

Leia mais

IBM Rational Quality Manager. Felipe Freire IBM Rational pfreire@br.ibm.com

IBM Rational Quality Manager. Felipe Freire IBM Rational pfreire@br.ibm.com Gerenciamento de Qualidade IBM Rational Quality Manager Felipe Freire IBM Rational pfreire@br.ibm.com Introdução Jazz Rational Quality Manager Demonstração Agenda 2 Teste de software?!? O que é? Para que

Leia mais

Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações

Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações Adolfo Guilherme Silva Correia Uma arquitetura baseada em agentes de software para a automação de processos de gerênciadefalhasemredesde telecomunicações Dissertação de Mestrado Dissertação apresentada

Leia mais

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico

Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico Winston Carvalho Santana Proposta de Modelo de Desenvolvimento de Sistema de Medição de Desempenho Logístico DISSERTAÇÃO DE MESTRADO DEPARTAMENTO DE ENGENHARIA INDUSTRIAL Programa de Pós-Graduação Profissional

Leia mais

XI Torneio Inter Escolas de Pista Coberta. Escola Mestre Domingos Saraiva (Lisboa) Centro de Formação EB 2;3 S. Bartolomeu dos Mártires (Viana)

XI Torneio Inter Escolas de Pista Coberta. Escola Mestre Domingos Saraiva (Lisboa) Centro de Formação EB 2;3 S. Bartolomeu dos Mártires (Viana) XI Torneio Inter Escolas de Pista Coberta Escolas Inscritas EB 2;3 de EB 2;3 Sec. Sá de Miranda Colégio Teresiano EB 2;3 Prof. G. Sampaio EB 2;3 de Externato Delfim Ferreira Escola Mestre Domingos Saraiva

Leia mais

Planejamento de Comunicação Organizacional: uma releitura da estrutura, enriquecida pelos modelos de análise de marketing.

Planejamento de Comunicação Organizacional: uma releitura da estrutura, enriquecida pelos modelos de análise de marketing. Universidade de São Paulo Escola de Comunicações e Artes - ECA Departamento de Relações Públicas, Propaganda e Turismo Programa de Pós-Graduação em Ciências da Comunicação Planejamento de Comunicação Organizacional:

Leia mais

Online Collaborative Learning Design

Online Collaborative Learning Design "Online Collaborative Learning Design" Course to be offered by Charlotte N. Lani Gunawardena, Ph.D. Regents Professor University of New Mexico, Albuquerque, New Mexico, USA July 7- August 14, 2014 Course

Leia mais

Certificado de Presença em Evento no ISEP

Certificado de Presença em Evento no ISEP *** Adam Silva *** ***c527078fe56b04280dcae9cc3541593d73d82015c12f65f060135ed5*** *** Adulcínio Adulcínio Duarte Rodrigues *** ***09d09b00214962ffdfefa4e2473001b55ffba6c7bbdc74ef3063ec95*** *** Alberto

Leia mais

A METHOD OF STRATEGIC MANAGEMENT AND PLANNING TO OBTAIN COMPETITIVENESS IN FARMING BUSINESS

A METHOD OF STRATEGIC MANAGEMENT AND PLANNING TO OBTAIN COMPETITIVENESS IN FARMING BUSINESS A METHOD OF STRATEGIC MANAGEMENT AND PLANNING TO OBTAIN COMPETITIVENESS IN FARMING BUSINESS Mr. Frederico Fonseca Lopes MARKESTRAT ffflopes@markestrat.org Ms. Janaína Gagliardi Bara USP / FEARP / MARKESTRAT

Leia mais

2 Categorias Categories Todas as categorias de actividade são apresentadas neste espaço All activity categories are presented in this space

2 Categorias Categories Todas as categorias de actividade são apresentadas neste espaço All activity categories are presented in this space 1 Próximas Actividades Next Activities Visualiza as próximas actividades a ter inicio, com a indicação do tempo restante Displays upcoming activities and indicating the remaining time 2 Categorias Categories

Leia mais

Lista de Resultados da 6ª Fase de Seleção - Curso de Tripulante de Ambulância de Socorro - TAE-INEM 01/2015 NOTA 1ª F NOTA 2ª F

Lista de Resultados da 6ª Fase de Seleção - Curso de Tripulante de Ambulância de Socorro - TAE-INEM 01/2015 NOTA 1ª F NOTA 2ª F Lista de Resultados da ase de Seleção - Curso de Tripulante de Ambulância de Socorro - TAE-INEM 01/2015 106 2165 02291253122165975318 Abílio Fernando Bragança Milheiro 15,250 14,050 18,400 12,000 12,900

Leia mais

ORGANIZAÇÃO DA INFORMAÇÃO NOTICIOSA EM COMUNIDADE ONLINE PARA O SÉNIOR RENATO MIGUEL SILVA COSTA. Departamento de Comunicação e Arte !!!!!!!!!

ORGANIZAÇÃO DA INFORMAÇÃO NOTICIOSA EM COMUNIDADE ONLINE PARA O SÉNIOR RENATO MIGUEL SILVA COSTA. Departamento de Comunicação e Arte !!!!!!!!! Universidade de Aveiro 2012 Departamento de Comunicação e Arte RENATO MIGUEL SILVA COSTA ORGANIZAÇÃO DA INFORMAÇÃO NOTICIOSA EM COMUNIDADE ONLINE PARA O SÉNIOR RENATO MIGUEL SILVA COSTA Universidade de

Leia mais

Protective circuitry, protective measures, building mains feed, lighting and intercom systems

Protective circuitry, protective measures, building mains feed, lighting and intercom systems Tecnologia de instalações electrónicas Training systems / trainers for electrical wiring/building management systems: Protective circuitry, protective measures, building mains feed, lighting and intercom

Leia mais