Enunciado de Projecto Integrador 2012/2013

Transcrição

1 Enunciado de Projecto Integrador 2012/2013 Adriano Lopes Ana Moreira Fernando Birra João Lourenço João Moura Pires Departamento de Informática FCT/UNL 28 de Fevereiro de Introdução As conferências de carácter científico continuam a reunir desde uma centena a muitos milhares de participantes. A organização destes eventos varia de acordo com a área científica, mas em geral é uma atividade complexa que envolve muitas pessoas com competências diferentes, que se estende por períodos significativos de tempo, desde meses até vários anos, e que tem o seu culminar algumas semanas ou meses depois da realização do evento. A duração dos eventos varia entre um e sete dias, tipicamente. Um evento pode estar confinado a uma única sala, disperso por vários pontos de um edifício, por vários locais de um campus e, muito raramente, por vários edifícios de uma cidade. Em todos os eventos, a experiência dos participantes depende de muitos fatores e um deles é o acesso à informação adequada no momento próprio e de forma clara e adaptada a cada participante. Quanto mais complexo for o evento, mais importante é este aspeto. A experiência da participação no evento dependerá igualmente da interação entre os participantes, destes com a organização do evento, e com os oradores das sessões. Há alguns anos a informação era distribuída em papel e, mais recentemente, através de sites de suporte ao evento (muito acedido ainda antes da participação). Hoje em dia, o acesso à informação e a experiência de participação no evento pode (deve) assentar igualmente na Internet móvel, na possibilidade de geolocalização e acesso a mapas, no tempo real e nas capacidades multimédia disponíveis nos smartphones, tablets e laptops. As redes sociais são essenciais para permitir partilha, integração e amplificação das experiências individuais. Para além da visibilidade para o público em geral, a organização de uma conferência científica disponibiliza serviços e funcionalidades que se destinam exclusivamente aos participantes registados no evento. Só após a inscrição, acompanhada por norma do respetivo pagamento pecuniário, é que os participantes podem ter acesso ao material de apoio, assistir às apresentações científicas dos vários oradores, participar em discussões sectoriais ou ainda estar presente nos eventos sociais da conferência. Há conferências que envolvem milhares de participantes (SIGRAPH, ICSE), podem incluir múltiplos tracks (Euro-Par, ACM SAC), incluir eventos paralelos (MODELS, ECSE/FSE), ou terem um carácter mais regional (INForum, CAPSI). Tipicamente as conferências repetem-se anualmente, mantendo estrutura idêntica, o mesmo tipo de atividades, de inscrições, participantes e necessidades idênticas de comunicação e informação a transmitir. Tendo em conta a variedade de aspetos descritos acima, espera-se que os grupos adotem estratégias e objetivos diferenciados. Na dimensão expectável para este trabalho, é possível enquadrar sistemas que se dedicam apenas a uma única edição de um evento específico, como é o caso do INForum 2013; sistemas que se dedicam a uma série de eventos que se repetem anualmente, como é o caso do INForum ou do EPIA; ou uma plataforma que permita a construção de soluções costumizadas para uma variedade de conferências. 1

2 Na secção 1.1 serão apresentados alguns cenários motivadores do que se pretende. Na secção 1.2 é apresentada uma perspetiva geral da solução do sistema a construir para tornar reais alguns desses cenários. 1.1 Cenários para a motivação Vamos considerar os cenários seguintes como ilustrativos. Estes cenários são situações representativas e são encarados como possibilidades interessantes, mas não são, de todo, um conjunto de casos de utilização. Cenário 1: Amanhã é o primeiro dia da conferência. Chego ao aeroporto e verifico que transportes apanhar para o hotel reservado. O transporte mais económico é um mini-autocarro que parte de outro terminal. Como a distância até à paragem é curta, consulto o mapa e vejo o caminho a percorrer. Cenário 2: Está na hora de ir para a cama, para não chegar atrasado logo no primeiro dia. A viagem foi cansativa e preciso consultar o horário do transporte para o local da conferência. Enquanto navego na aplicação reparo que posso definir os tópicos que mais me interessam e recebo logo uma proposta de agenda para os dias do evento. Cenário 3: Acabo de chegar ao local da conferência. A aplicação mostra-me onde me devo dirigir para efetuar o registo e levantar a pasta com todo o material (proceedings, blocos de notas, programa em papel, folhetos com sugestões turísticas de locais a visitar e restaurantes recomendados). Sim! Está tudo na aplicação, mas há sempre quem prefira andar a carregar a pasta durante toda a conferência... Cenário 4: Nunca vi um registo tão fácil! Chegado ao local escolho a opção de checkin e enconsto o telefone a um leitor de QR codes. Imediatamente, vejo sair na impressora um badge com o meu nome, assim como uma série de senhas personalizadas para trocar por refeições nos diversos bares disponíveis durante o evento. As senhas de refeição indicam claramente as minhas preferências: Menu Vegetariano e Chá! Cenário 5: Tenho um poster para colocar e pergunto onde poderei fazê-lo. A organização indica-me o local e eu partilho a localização do mesmo na aplicação, ficando assim disponível para todos os participantes e utilizadores da aplicação. Cenário 6: Na sessão de abertura consulto o programa e aproveito para satisfazer a curiosidade e saber quem são algumas daquelas caras desconhecidas presentes na mesa. Leio um pequeno resumo biográfico de cada um deles, assim como um pouco dos factos história da Universidade que acolhe o evento. Cenário 7: A sessão de um dos keynote speakers teve uma mudança de sala devido a um problema técnico com o sistema de som. No meu calendário já está tudo atualizado e até tenho uma mensagem a chamar a atenção para o facto. Cenário 8: Na primeira sessão de technical papers houve também uma mudança na ordem das apresentações. Abro o portátil e vejo os artigos da sessão dispostos já pela ordem correta. Abro o artigo da apresentação corrente e associo-lhe umas quantas notas para não perder umas ideias que me surgiram durante a apresentação. O autor fez um trabalho impressionante e o nome não me é totalmente estranho... Consulto a lista de outros artigos por ele já publicados e, de facto, o número de citações no google scholar é bastante bom. Click, click, click, e fico com a lista dos que pretendo ler mais tarde. Cenário 9: Mais um orador cheio de boas ideias. Desta vez até tenho a possibilidade de me ligar a ele no LinkedIn, de o seguir no Twitter, assim como a página do grupo dele no Facebook. 2

3 Cenário 10: Uma sessão estimulante e outro orador com trabalho interessante, mas como não parece ser muito adepto das redes sociais, resta-me marcá-lo para um eventual contacto futuro. Mais tarde, cruzo-me com ele no intervalo para o café e trocamos cartões de visita usando a app do telemóvel. Cenário 11: Estou no intervalo de uma das sessões e acabo de receber a notificação de que ainda há vagas para o evento social da conferência. Calha bem! Na altura do registo não tinha a certeza de poder ir, mas agora que aqui estou vem mesmo a calhar. Felizmente o menu do jantar é flexível e, como sou vegetariano, aproveito logo para dar a indicação enquanto reservo. Pouco depois, reparo que na minha agenda já existe a entrada do jantar, e até vem com indicações para o transporte. Cenário 12: É comum atribuir prémios de participação em diferentes categorias: melhor artigo de jovem investigador, melhor apresentação, melhor demo, etc. Em alguns casos apenas um grupo restrito de elementos pode votar, mas também há votações menos elitistas. Para votar no melhor orador da conferência, um simples click de like basta para alterar os rankings. Cenário 13: Com a permissão dos respetivos autores, os slides de cada apresentação e demais materiais multimédia podem ser gravados. Com a sua autorização, esses materiais estão já disponíveis para consulta e anotação nos meus dispositivos. Cenário 14: Tenho uma questão importante a colocar ao orador. Uso a aplicação e inscrevo-me para perguntas no final da apresentação. O moderador da sessão tem a lista de inscrições à sua frente atualizada em tempo real. Cenário 15: Está quase na hora do almoço. Por acaso um colega meu veio também à conferência, mas está a assistir a uma sessão que decorre em paralelo. Verifico rapidamente a sua agenda partilhada e constato que a posição atual dele é exatamente na sala onde decorre essa sessão. Peço instruções e ponho-me a caminho para ir ter com ele. Cenário 16: Esse meu colega também vai apresentar um artigo e o mais curioso é que a sessão em que ele vai participar está já na minha agenda! Deve ser porque está na minha lista de colaboradores... Cenário 17: São 15h30 e estou no meio de mais uma sessão. Não é muito elegante entrar e sair da sala com uma sessão a decorrer, mas acabo de sentir o telefone a vibrar. Estou a ser avisado que tenho uma reunião dentro de minutos com um colega investigador de outra Universidade. Já estava esquecido que lhe tinha enviado um convite para uma pequena conversa. Este documento especifica, com bastantes graus de liberdade, um sistema que possa dar resposta a algumas das necessidades sugeridas pelos cenários anteriores. Na próxima secção faz-se uma apresentação genérica do que se pretende neste projeto. Recordamos que a especificação e a implementação do sistema estará a cargo de cada um dos grupos de 3 ou 4 alunos e que deverá decorrer durante cerca de 18 semanas. 1.2 Apresentação geral Pretende-se uma solução de distribuição de informação e conteúdos para utilização em eventos científicos sobre plataformas móveis (smartphones, tablets e laptops) que ofereça aos participantes dos eventos, entre outras, as seguintes características e funcionalidades: Agenda: Acesso a uma agenda interactiva, detalhada, pesquisável, navegável e personalizável. Marcações: Possibilidade de marcação de reservas de bilhetes para actividades que o requeiram (e.g., o banquete da conferência). 3

4 Localização: Acesso a mapas e/ou plantas interactivas relevantes para os participantes, com pontos de interesse, e capacidade de obter indicações de como ir do ponto actual para um dos pontos de interesse. Acesso em Tempo Real: Acesso a informação em tempo real produzida pela organização, pelas actividades, ou pelos participantes, tendo em consideração a limitação dos recursos da plataforma utilizada pelo participante. Participação: Possibilidade de participar no evento através de acções directas e voluntárias como, por exemplo, votar, enviar imagens, comentários e respostas, participar em inquéritos, etc. Partilha de Informação: Partilhar a informação e a experiência do evento, nomeadamente através de redes sociais e correio electrónico ou mesmo através da plataforma do evento. Partilha de Localização: Partilhar a informação de localização do próprio ou de locais de interesse com amigos através da plataforma. Requisitos não funcionais: Usabilidade, Segurança, Multi-acesso, Disponibilidade, Desempenho, Interoperabilidade (descritos na secção 2.3). A secção 2 apresenta, informalmente, o sistema que se presente desenvolver. A secção 3 discute os aspectos mais relevantes do âmbito e dos requisitos funcionais e não funcionais. A secção 4 apresenta algumas considerações sobre a arquitectura e tecnologias a utilizar, salientando algumas opções, oportunidades e limitações que deverão ser consideradas. Finalmente, a secção 5 apresenta algumas reflexões sobre o enquadramento desta unidade curricular de Projecto Integrador na Licenciatura em Engenharia Informática da FCT. 2 Apresentação informal Este projeto admite vários tipos de abordagens, onde podem e devem ser equilibrados os graus de especialização e profundidade no tratamento dos eventos, por um lado, e a generalidade do sistema na adaptação do mesmo a diversos tipos de plataforma, por outro. Por exemplo, ao definir e restringir o tipo de eventos abrangido pelo sistema, torna-se mais possível e mais eficiente o suporte para um maior número de detalhes e diferentes tipos de interfaces e informação processada (imagens, vídeos, etc.). É previsível que ao alargar o espectro de eventos suportados (e.g. quantidade e variedade de eventos satélite), fornecendo assim uma plataforma genérica, se perca alguma especialização a nível da interface oferecida. Na realização do trabalho está subjacente um compromisso entre uma e outra vertente. É da responsabilidade de cada grupo definir e limitar o âmbito do seu trabalho, propondo uma solução concreta para um tipo ou vários tipos de conferência. Seja qual for a abordagem seguida na resolução do problema, é inevitável que o sistema a desenvolver seja capaz de lidar com uma multiplicidade de conceitos associados a eventos de conferências (participantes, localização, agenda, etc.). Nesta secção discutem-se alguns destes conceitos. Em primeiro lugar, os conceitos envolvidos e como podem ser interligados/combinados na solução proposta; depois, as funcionalidades e requisitos que devem ser tomados como centrais no desenvolvimento do sistema; e finalmente as qualidades que o sistema deve satisfazer, as que devem ser obrigatoriamente cumpridas, bem como os graus de liberdade admitidos. 4

5 2.1 Conceitos Uma conferência é um evento associado a uma determinada área científica, que se realiza num local (campus, cidade, edifício, etc.), durante um período de tempo (tipicamente de 1 a 7 dias) e onde os especialistas da área se reúnem para partilhar experiências. Alguns destes especialistas são autores dos trabalhos científicos, ou artigos científicos, que são apresentados no decorrer do evento. Outros são apenas participantes. A apresentação dos vários trabalhos é organizada em sessões, constituindo uma parte fundamental do programa da conferência. Cada sessão decorre numa sala, tem um moderador e uma duração típica de 90 minutos para a apresentação de 3 trabalhos, no entanto são possíveis outras configurações. Há conferências que permitem a organização simultânea de múltiplas sessões. Há sessões plenárias típicas, como a sessão de abertura e fecho, e as sessões dedicadas a palestrantes convidados de renome internacional, os chamados keynotes ou invited speakers. Estas sessões têm um moderador e duração variável, mas no total nunca ultrapassa mos 90 minutos. Os participantes de uma conferência, autores ou não, têm que se inscrever previamente pagando valores monetários que são variáveis, dependendo do seu estatuto de participante (ex: estudante, afiliado numa organização profissional, etc.) e da data em que a inscrição é feita. O programa de uma conferência pode incluir, para além das sessões para apresentação dos artigos, a organização de eventos satélite em paralelo (e.g. demos, tutoriais, workshops, ações de divulgação comercial). Uma parte relevante da participação numa conferência são os eventos sociais (banquete oficial, receção de boas-vindas, etc.) a que os acompanhantes dos participantes podem ter acesso mediante registo. Os eventos sociais são por norma pagos autonomamente. 2.2 Funcionalidades As atividades desenvolvidas pelos participantes numa conferência podem ser divididas em duas categorias: ativas, por exemplo comentar uma apresentação, ou colocar fotografias do evento no Facebook; ou passivas, apenas recebendo e acedendo a informação do evento. No contexto da definição de um objetivo global, pretende-se uma solução de distribuição de informação e conteúdos para utilização em eventos científicos, sobre plataformas móveis (smartphones, tablets e laptops) que melhore a experiência de participação em eventos científicos. Para isso, o sistema deverá fornecer três grandes tipos de funcionalidades: consulta, personalização e contribuição. Consulta. O sistema ou plataforma a desenvolver tem por objetivo principal disponibilizar informação aos participantes no evento. O participante deverá ter a possibilidade de consultar, visualizar e navegar em variadas informações disponíveis, como o programa, mapas do edifício onde se realiza o evento ou da cidade, edições anteriores da conferência, eventos sociais, etc. A caracterização do espaço do evento decorre da composição dos espaços das várias atividades, como por exemplo workshops, demos, tutoriais, sessões. Seria útil oferecer aos participantes a possibilidade de aceder a um mapa geral do evento, onde se conseguem localizar as atividades, e ainda outros pontos de interesse (saídas, casas de banho, estacionamentos, posto médico, etc.), rotas aconselhadas, ou salas de eventos satélite. Assim, elementos primordiais da plataforma serão uma agenda, um mapa, uma lista de atividades, possivelmente organizada por tipos de atividades e uma interface de pesquisa. Deve ser possível a partir de qualquer um dos tipos de atividade, navegar e chegar a toda informação e conteúdos sobre atividades e seus intervenientes. O sistema poderá oferecer acesso a mapas e/ou plantas interativas relevantes para os participantes, com pontos de interesse, e capacidade de obter indicações para ir do ponto atual para um dos pontos de interesse. O acesso a mapas e o acesso a plantas interativas são duas funcionalidades bem distintas 5

6 e que possivelmente são abordadas tecnologicamente de forma diferente. Importa ainda salientar a necessidade de uma delas ser independente da necessidade da outra. Personalização. A agenda de um evento surge naturalmente da composição do horário das várias atividades que compõem o evento. Dessa composição podem surgir agendas de um ou mais dias, com um ou mais eventos em paralelo, onde aparecem as localizações dos eventos e uma descrição sumária. Uma agenda deverá ser interativa, detalhada, pesquisável, navegável, e personalizável. A agenda não deve ser apenas uma lista simples, e com várias formas de navegar na agenda, filtrar, ordenar, etc. Detalhada significa que deve ter acesso a informação detalhada de cada atividade, sobre o seu conteúdo, sobre as pessoas envolvidas, etc. Deve ser pesquisável por palavras chave e pode ser algo mais inteligente que a simples pesquisa de sub-string. Personalizável significa que cada utilizador deve poder construir a sua agenda. A agenda deve ser tanto mais poderosa e fácil de usar quanto mais rico for o evento em termos do número de atividades e atividades simultâneas, e atividades com horários e locais distintos. Para além da agenda, outros elementos podem ser alvo de personalização, como por exemplo o utilizador anotar uma cópia privada dos slides do orador, agrupar fotografias disponibilizadas pela organização em pastas definidas pelo utilizador, guardar artigos ou outros documentos em pastas para consultar mais tarde, associar notas tipo post-it a documentos, etc. Contribuição. O participante pode contribuir para o evento através de ações diretas e voluntárias, nomeadamente, votar, enviar fotos, comentários, respostas, participar em inquéritos, jogos, etc. Algumas destas formas de participação são fortemente dependentes das atividades enquanto que outras são aplicáveis a qualquer atividade, como por exemplo, comentar ou atribuir um rating a uma atividade. É interessante que a solução proposta considere alguma forma de participação. Outro aspeto relevante está associado á partilha de informação e experiência no evento, nomeadamente através de redes sociais e correio eletrónico ou mesmo através da plataforma do evento. A partilha de informação através das redes socais, tipicamente Facebook, Twitter e outras rede similares em que o utilizador tem uma conta, deve permitir uma publicação com um ou dois passos. A abordagem pode permitir estender o conjunto de redes sociais em que se permite a publicação. Já a partilha de informação através da plataforma requer que de algum modo se construa uma rede social sobre a plataforma e no contexto do evento. Também a partilha de informação de localização com amigos através da plataforma é útil. Tal como o ponto anterior, requer que de algum modo se construa uma rede social sobre a plataforma e no contexto do evento. 2.3 Atributos de qualidade Os atributos de qualidade são requisitos não-funcionais que definem restrições globais sobre um sistema ou sobre uma parte deste. Frequentemente não é possível satisfazer estas restrições a 100%, pelo que é necessário encontrar um nível de compromisso aceitável. Importa referir que estes atributos são subjetivos. Para o sistema a desenvolver, considera-se importante a existência dos seguintes atributos de qualidade: Acesso em Tempo Real: Acesso a informação em tempo real produzida pela organização, pelas atividades, ou pelos participantes, tendo em consideração a limitação dos recursos da plataforma utilizada pelo participante. 6

7 Usabilidade: Facilidade com a qual um participante pode aprender a operar com o sistema ou os seus componentes, e com que consegue introduzir informação no sistema/componentes, ou recolher e interpretar a informação que estes produzem. Segurança: Controlo dos riscos de utilização indevida por parte de entidades não autorizadas. Multi-acesso: Possibilidade de acesso à mesma informação, por parte de vários participantes, e em simultâneo. Disponibilidade: Grau em que o sistema, ou os seus componentes, estão operacionais e acessíveis para utilização. Desempenho: Grau com que o sistema, ou suas componentes, cumpre as suas funções dentro das restrições, ou limitações, definidas como velocidade, uso do espaço (memória, ou disco), ou da bateria. Interoperabilidade: Capacidade de dois ou mais sistemas ou componentes trocarem informação e de utilizarem essa informação trocada. 3 Elementos Orientadores Apesar das soluções que as equipas virão a apresentar serem seguramente diferenciadas quanto ao âmbito e forma de abordar o problema, nesta seção iremos apresentar de forma mais sistemática qual o âmbito em termos das componentes a desenvolver de uma arquitetura de referência (secção 3.1), em termos dos tipos de soluções (secção 3.2), em termos das plataformas móveis consideradas (secção 3.3). Na secção 3.4 são brevemente discutidos alguns aspetos que podem ser complementares. Importa referir que nesta secção não serão discutidos de novo aspetos funcionais ou outro tipo de requisitos (ver secção 2.2 e secção 2.3). 3.1 Arquitectura de referência Considere a Figura 1 que apresenta o quadro de referência da solução que se pretende que venham a implementar. O bloco identificado como SI-Científico, Sistema de Informação da Gestão Científica do Evento, representa o conjunto de sistemas de informação que suportam a atividade dos comités de programa do evento, abarcando um conjunto de atividades relativas à submissão, avaliação e seleção dos trabalhos que serão aceites, mas que estão fora do âmbito do sistema a desenvolver, e mesmo fora do âmbito deste documento. O bloco identificado como SI-Org+Pub é o responsável por todos os aspetos organizativos do evento e pela preparação e distribuição de informação e conteúdos para o público em geral e em particular para os participantes no evento. Este bloco (SI-Org+Pub) está igualmente fora do âmbito do sistema a desenvolver. Finalmente o bloco identificado como SI-M deverá assegurar por um lado a comunicação com os smartphones e tablets, interação assinalada com 1, e por outro lado a comunicação com bloco SI- Org+Pub, assinalado com 3, que poderá corresponder à simples entrega de ficheiros, ou de algo mais sofisticado e eventualmente dinâmico. De modo idêntico a interação, assinalada com 4, entre o SI-M e o bloco SI-Científico provavelmente consiste apenas na entrega da informação relativa aos autores e relativa aos diferentes artigos, podendo em alguns casos ser acompanhada da entrega dos artigos em formato PDF. Deverá certamente estar prevista uma interface com utilizadores para configuração, administração e manutenção do bloco SI-M, assinalado como 2. Não deve haver qualquer dúvida de que a definição, desenho e implementação do bloco SI-M, assim como a interação com os smartphones e tablets são partes centrais do âmbito deste trabalho. Marginalmente a interação assinalada como 2 poderá existir em maior ou menor expressão. Por 7

8 SI-Cienífico SI-Org+Pub 4 3 SI-M 2 M 1 Figura 1: Arquitectura de Referência exemplo, poderá haver uma pequena interface web para realizar algumas destas atividades, ou apenas a possibilidade de carregar ficheiros de administração e configuração. A eventual interação com o bloco SI-Org+Pub, assinalada como 3, está fora do âmbito deste trabalho devendo no entanto prever a capacidade de vir a integrar de forma o mais fácil possível com um qualquer sistema SI-Org+Pub que venha a ser conhecido posteriormente. Assim, em alternativa à integração com um sistema concreto SI-Org+Pub, deve ser definida, desenhada e implementada uma abstração, assinalado com 3 na Figura 2, que permita a posterior integração a um eventual sistema SI-Org+Pub concreto. Esta abstração irá permitir que cada equipa desenvolva e teste todo o trabalho semse estar na presença de um verdadeiro SI-Org+Pub. Deve ser esta abstração a responsável pelo fornecimento de informação relativa ao evento. Além disso, se no desenho da solução se considerar que uma fotografia, um vídeo, um comentário ou um rating de um participante devem subir para serem publicados noutros canais, tal deve igualmente ficar a cargo desta abstração. A comunicação com o SI-Científico, apesar de eventualmente mais simples, deverá igualmente ser definida, desenhada e implementada uma abstracção dessa comunicação, assinalada com 4 na Figura 2. Importa deixar claro o papel essencial do bloco SI-M. Tal como já foi anteriormente referido a componente móvel pode ser considerada como web móvel ou nativa móvel. De qualquer dos modos, mesmo num cenário de uma aplicação nativa móvel, será sempre necessário o carregamento de informações sobre o evento, a atualização dessas mesmas informações, a disponibilização de informação tempo real no caso de existir, de informação multimédia. Além disso no caso de ser necessário subir alguma informação para o SI-Org+Pub os dispositivos móveis apenas comunicam com o SI-M. É agora possível indicar quais as componentes desta arquitetura que pertencem ao âmbito deste 8

9 4 SI-M 3 2 M 1 Figura 2: Arquitectura macro do sistema a implementar projeto. Estão claramente dentro do âmbito deste projeto a definição, desenho e implementação de: (i) Cliente(s) móveis; (ii) SI-M; (iii) interface de administração do SI-M, 2 ; (iv) abstração da integração do SI-Org+Pub, 3 ; (v) abstração da integração do SI-Científico, 4. Naturalmente que a extensão de cada um destes componentes será dependente da solução proposta por cada equipa e tendo em conta os aspetos identificados nas próximas secções. 3.2 Tipo de Sistema Na dimensão expectável para este trabalho, é possível enquadrar um sistema que se dedica apenas a uma conferência especifica, como por exemplo o INForum (suportando uma ou várias edições), uma plataforma genérica para conferências de uma determinada área científica, como por exemplo Medicina, ou ainda plataforma genérica para quaisquer tipo de conferências. É ainda possível conceber uma plataforma que se destina a permitir a construção de diferentes soluções para diferentes conferências. Por outro lado, a escolha de um ramalhete apropriado de funcionalidades coerentes e adequadas é, talvez, a maior dificuldade para o desenho da solução que cada equipa vai apresentar. É expectável que cada grupo adote uma estratégia um objetivo próprios. No entanto, é absolutamente essencial reconhecer que a solução deve providenciar uma experiência de qualidade aos principais utilizadores da solução, isto é, aos participantes das conferências científicas. 3.3 Plataformas Móveis A identificação das plataformas móveis a considerar é essencialmente de ordem tecnológica, mas é essencial adequar desde cedo ao alvo, ao tempo, às competências disponíveis e à qualidade da interação que se pretende atingir. Os aspetos a considerar são, nomeadamente: (i) Sistema operativo: ios, Android, Windows 8, outro; (ii) Web móvel (recorrendo a bibliotecas que abstraem o browser específico), aplicação nativa (usando as ferramentas próprias) ou ainda aplicação nativa recorrendo essencialmente a Web móvel; (iii) tipo de dispositivo smartphones e tablets. Atenção que, em relação a este último aspeto pode ser necessário / conveniente identificar modelos específicos. 9

10 Mais uma vez caberá a cada equipa fazer a identificação clara qual o alvo tecnológico. No entanto o alvo de referência é no mínimo a Web móvel e preferencialmente aplicação nativa recorrendo essencialmente a Web móvel, para pelo menos um smartphone e preferencialmente igualmente para um tablet. 3.4 Aspetos complementares Nesta secção são referidos alguns aspetos que, ou são preocupações que devem ter presente durante o processo de desenho da vossa solução, ou são possibilidades que podem eventualmente enriquecer a experiência dos participantes. Em qualquer dos cenários, Web Mobile ou aplicação nativa, é possível e desejável alguma forma de persistência, quer seja do lado do dispositivo quer seja do lado do servidor (neste caso o SI-M referido na Figura 2), que permita por exemplo guardar a informação de favoritos, ou de histórico, informação parcial ou completa (e cifrada) de registos em redes sociais, etc. Note que é possível garantir essa persistência (local ou remota) sem registo do utilizador através de um par identificador / senha. No entanto significa que essa persistência ficará associada ao dispositivo. Alternativamente, a persistência pode ficar associada um registo prévio e desse modo ser função do utilizador e não do dispositivo e, consequentemente, estar disponível tanto no seu smartphone como no seu tablet. Além disso o registo parece ser essencial para outras questões, tal como partilha de informação através da plataforma, seja globalmente (evitando o anonimato) seja através de redes de amigos no âmbito do evento. Cada equipa deverá fazer uma escolha ponderada e consistente destes aspetos. No caso de a equipa optar por uma solução técnica que permita o acesso franco ao dispositivo (câmara, microfone, bússola, acelerómetro, etc) abre-se um conjunto de possibilidades tais como a captura de imagens e vídeos, o reconhecimento de QRcodes, captura de som (por exemplo som ambiente e com isso determinar o contexto), etc.. Cada equipa deve libertar a sua criatividade e tentar identificar algum forma que explore as plataformas para melhorar a experiência dos participantes do evento. 4 Tecnologias O trabalho aqui proposto deve ser implementado segundo a arquitectura descrita na secção 3, e deve no entanto ser balizado por um conjunto de restrições tecnológicas, umas obrigatórias, outras apenas aconselhadas. Como grupo de trabalho terão algum espaço de manobra. A primeira diferença, em relação à vossa experiência passada de desenvolvimento de aplicações, está na existência de dois ambientes de trabalho potencialmente bastante diferentes: uma máquina de desenvolvimento, que neste caso serão as vossas máquinas pessoais; e uma máquina de produção, que neste caso será uma máquina virtual Linux. A máquina de produção será disponibilizada pela equipa docente a seu tempo, com uma instalação básica de Linux (Debian 5 ou 6) muito simples, sendo da responsabilidade de cada grupo a instalação dos pacotes necessários e a sua devida configuração, para que suporte o sistema desenvolvido. Quanto aos restantes aspetos tecnológicos, a componente base de dados deve ser assegurada por um (ou mais) sistemas de gestão de bases de dados, em que as opções recomendadas, mas não exclusivas, são MySQL ou PostgreSQL. Para a programação na parte do sistema que corre no servidor, sugere-se a utilização do Ruby on Rails. Quanto às plataformas móveis, existem essencialmente duas maneiras distintas de criar aplicações para dispositivos móveis, através da produção de aplicações nativas ou através de aplicações web based. 10

11 Neste trabalho pretende-se que seja desenvolvida uma solução que usa tecnologias típicas de ambientes Web HTML5, css e javascript. Na solução a desenvolver será necessário aceder às características mais sofisticadas dos dispositivos e que normalmente não são acessíveis diretamente a partir de um browser, como a gravação/reprodução de conteúdos multimédia, a geo-localização, a orientação portrait ou landscape, guardar dados localmente no browser, ou a interação multitouch. Para poder aceder a estas funcionalidades sugere-se a utilização da framework phonegap 1 em conjunto com a jqmobi 2 ou JQuery mobile 3. Enquanto o phonegap permite ter acesso às funcionalidades avançadas dos dispositivos móvies, o jqmobi/jquery mobile permite desenvolver interfaces gráficas avançadas de forma mais simples. Devido a razões de segurança, as aplicações puramente web mobile têm algumas limitações, nomeadamente no acesso ao dispositivo, câmara, microfone e outros sensores. Frameworks como o phonegap fornecem soluções para criar aplicações que, apesar de usarem tecnologias web, executam como uma aplicação nativa, devendo ser instaladas antes de ser executadas. A aplicação cliente pode então ser criada com recurso a esta solução e deste modo ter acesso a todos os sensores do dispositivo. As soluções tecnológicas apresentadas nesta secção são apenas sugestões. Os alunos poderão usar outras opções, desde que tal seja apresentado, discutido e autorizado pela equipa docente. Na tomada de decisão relativa a este ponto, os alunos devem estar conscientes que o suporte dado pela equipa docente na resolução de problemas que surjam específicos às tecnologias escolhidas será limitado. 5 Notas Finais Este documento pretende ser uma base para a especificação do trabalho a realizar. É apenas um ponto de partida (que será certamente revisitado ao longo do tempo) para um caminho que cada grupo terá que trilhar. O conhecimento profundo do sistema a desenvolver depende do grau de empatia e intimidade que com o mesmo conseguirem estabelecer. Não se esqueçam que, durante uma boa parte do semestre, o sistema apenas estará nas vossas cabeças e deverá por isso fazer parte integrante de cada um de vós! Para que no final possam ter um trabalho do qual se orgulhem verdadeiramente, terão que o ter sentido e ter sido capazes de ter a visão do mundo a partir do interior do mesmo, e não o contrário a visão de um qualquer outsider... Nas próximas semanas terão que grokar o problema. Terão que responder a duas perguntas essenciais: o quê? e o como?. Para responderem à pergunta o quê? tem que tentar construir uma imagem mental do que pretendem para o vosso produto final, a interação que este terá com o utilizador, que ramalhete de funcionalidades é uma oferta adequada ao tipo de solução que vão propor. Enfim, têm que o ter a funcionar no poderoso simulador que é a vossa mente. Como se trata de um trabalho em equipa, têm que conseguir comunicar e partilhar esse o quê?, e certamente este será um processo com várias iterações. Quanto ao o como?, terão que imaginar como as coisas irão funcionar, quais os componentes, as camadas, as formas de interação entre eles, as APIs que serão requeridas, como se assegura a persistência no SI-M, etc.. Também aqui irão ocorrer várias iterações e mais importante iram detalhar cada vez mais o o como? O mais provável é que venham a saltitar entre o o quê? e o como?. Haverá mesmo alturas em que o o como? irá obrigar a rever o o quê?. Não se esqueçam de que: Rien ne sert de penser, il faut réfléchir avant. Dac Pierre 11