OVERVIEW DE METODOLOGIAS PARA COMPUTAÇÃO UBÍQUA RELACIONANDO COM MPS.BR Adolfo Guimarães Daniel Barreto Kharylim Machado Letícia Gindri
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
INTRODUÇÃO "  As tecnologias mais profundas e duradouras são aquelas que desaparecem. Elas se mesclam na vida cotidiana até tornarem-se indissociáveis desta “  (Mark Weiser )
INTRODUÇÃO O termo Computação Ubíqua, foi definido pela primeira vez por Mark Weiser, no seu artigo “O Computador do Século 21” ( The Computer for the 21st Century ).  A computação não seria exclusividade de um computador  e sim de diversos dispositivos conectados entre si
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
A Computação Ubíqua torna a interação pessoa-máquina invisível Move-se para fora dos computadores e torna-se pervasiva na nossa vida cotidiana.  Requer computadores pequenos e tecnologias de ligação a computadores maiores.  O QUE É COMPUTAÇÃO UBÍQUA?
Domótica
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
MODELO DE BANAVAR Banavar propõe um modelo focado numa mudança de paradigma, desafiando a comunidade a adotar uma nova visão de dispositivos, aplicações e ambientes. Esta reformulação de conceitos pode ser resumida em 3 idéias principais:
MODELO DE BANAVAR i.  Um dispositivo é um portal, num espaço de aplicação/dados, e não um repositório de software customizado gerenciado pelo usuário; ii.  uma aplicação é um meio pelo qual o usuário realiza uma tarefa, e não um trecho de código escrito para explorar as capacidades do dispositivo; iii.  o ambiente computacional é uma espaço de informação, estendido para o usuário. E não um espaço virtual que existe para armazenar e rodar softwares.
MODELO DE BANAVAR Para que seja possível modelar essas aplicações, Banavar que é necessário que o ciclo de vida de uma aplicação deve ser dividida em três partes: Tempo de projeto (design-time): É quando o desenvolvedor cria, mantém e aprimora a aplicação. Tempo de carga (load-time): O sistema compõe, adapta e carrega os componentes da aplicação em uma instância em um dispositivo de hardware em particular. Tempo de execução (run-time): Quando o usuário final invoca a aplicação e usa suas funcionalidades.
MODELO DE BANAVAR Tempo de projeto (design-time): Se o "dispositivo é um portal", então a aplicação não deve ser escrita com um determinado dispositivo em mente. O desenvolvedor fazer suposições sobre tamanho de tela ou capacidades de hardware (e se não houver tela?) A interface com usuário não deve ser definida como uma composição rígida da interação. Não se deve assumir que um determinado serviço está disponível. Podem vir a existir serviços disponíveis que não são conhecidos pelo desenvolvedor no design-time.
MODELO DE BANAVAR Tempo de projeto (design-time): Metodologia de desenvolvimento Não há uma metodologia ideal para o desenvolvimento deste modelo, mas é importante que seja qual for a metodologia escolhida, que o desenvolvimento da aplicação seja essencialmente focado na tarefa do usuário, ao invés da interação do mesmo com a interface.
MODELO DE BANAVAR Tempo de carga (load-time): Aplicações e serviços "vivem" em um ambiente físico e distribuído. É necessário um mecanismo para identificar e enumerar essas aplicações e serviços (Dynamic discovery). Dispositivos necessitam negociar requisitos e capacidades para rodar os serviços que dispõe. O sistema deve suportar a seleção dinâmica de uma interface apropriada para a aplicação baseada nos recursos do dispositivo. O sistema deve integrar-se com outras aplicações e serviços disponíveis no ambiente.
MODELO DE BANAVAR Tempo de execução (run-time): A aplicação deve sempre monitorar os recursos do portal (dispositivo), para adaptar-se a esses recursos. O run-time deve conduzir uma mudança de contexto quando ocorrer uma mudança de ambiente, durante uma tarefa (ex: do escritório para o carro) A aplicação também deve manipular erros não esperados, queda em serviços ou problemas no próprio portal.
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
MODELO DE GRIMM (ONE.WORLD) Robert Grimm apresenta outra proposta de modelo mais específica. Trata-se, de fato, de uma arquitetura para a construção de aplicações pervasivas. Chamada "One.world", ela define serviços básicos do "núcleo" de um sistema ubíquo, que supririam determinadas necessidades fundamentais.
MODELO DE GRIMM (ONE.WORLD) As principais necessidades seriam:
MODELO DE GRIMM (ONE.WORLD) Os fundamentos principais do one.world são: i.  uma máquina virtual, para lidar com a heterogeneidade de dispositivos e sistemas operacionais; ii.  tuplas, responsáveis por prover uma forma simplificada de armazenamento; iii.  eventos assíncronos, capazes de fornecer a notificação explícita de uma mudança de contexto; iv.  e os ambientes, tratando-se de contâiners para cada aplicação e seus respectivos dados.
MODELO DE GRIMM (ONE.WORLD) Aplicações de teste para o one.world: Chat : um sistema de mensagens de texto e áudio capaz de gerenciar mudanças de localização do usuário. Labscape : Assistente digital para laboratórios de biologia. “Segue” o pesquisador, descobrindo qual o dispositivo mais próximo dele, permitindo a transferência automática dos dados necessários.
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
CENTERED DESIGN IN USER
CENTERED DESIGN IN USER José Miguel Rubio L. Pontificia Universidad Católica de Valparaíso, Chile Design centrado no usuário  Importância da intervenção do usuário nas atividades de avaliação (pessoas, trabalho e ambiente delas)
CENTERED DESIGN IN USER Modelo de Processo Iterativo
Ciclo de vida em Cascata A avaliação não é interna, ocupando uma posição estrita no ciclo Mas ela acaba se tornando uma atividade em operação contínua.  Permite o feedback do processo de desenvolvimento. CENTERED DESIGN IN USER
Trabalho Relacionado : UFPE Framework que proporciona o desenvolvimento de artefatos ubíquos educacionais Técnicas: Etnografia Rápida e Cenários Etnografia rápida: observação mais direcionada e estreita para reduzir o tempo gasto no processo Cenários: criação de quatro cenários CENTERED DESIGN IN USER
O PROCESSO POCAP (Process for Ontological Context-aware Applications)
POCAP Desenvolvido em 2006 “ Um processo de software e um modelo ontológico para apoio ao desenvolvimento de aplicações sensíveis a contexto” – Renato Bulcão (Doutorado/USP) Empresa INNOLUTIONS (Ribeirão Preto/SP)
POCAP Computação Ubíqua Interfaces naturais Captura e acesso automatizado de atividades humanas Computação sensível a contexto Computação no cotidiano
POCAP Computação Ubíqua Interfaces naturais têm como objetivo facilitar a capacidade de comunicação entre usuários e computadores ao fornecer suporte a formas naturais de comunicação humana. Captura e Acesso automatizado são aquelas que registram de modo automático informações de experiências do cotidiano humano para acesso posterior.
POCAP Computação Ubíqua Computação sensível a contexto são aquelas que utilizam informações de contexto para fornecer serviços e informações relevantes a usuários e a outras aplicações na realização de alguma tarefa. Computação no cotidiano são aquelas que devem fornecer suporte computacional contínuo – 24 horas por dia, 7 dias por semana – a atividades que podem ocorrer de forma concorrente, sem início e término bem definidos, e que podem ser interrompidas repentinamente.
POCAP O trabalho estudado apresenta uma metodologia de desenvolvimento para aplicações ubíquas onde a computação sensível ao contexto é levada em consideração.
POCAP Computação sensível ao contexto Ontologias
POCAP Computação sensível ao Contexto (1994) “seriam informações de localização, de identidade de pessoas e de objetos próximos entre si e das mudanças nesses objetos”  [Schilit & Theimer, 2004] (2001) “é qualquer informação que possa ser utilizada para catacterizar uma entidade. Uma entidade é uma pessoa, lugar ou objeto considerado relevante para uma interação entre um usuário e uma aplicação, incluindo o usuário e a aplicação em questão” [Dey et al., 2001]
POCAP Computação sensível ao contexto Características Apresentação de informações e serviços para o usuário Execução automática de um serviço União de informações de contexto
POCAP Computação sensível ao contexto Informações de Contexto Who ➔ identificação Where ➔ localização When ➔ tempo What ➔ atividade Why ➔ motivação How ➔ modo de captura e acesso
POCAP Ontologias “ Ontologia  é uma especificação  explícita  e  formal  de uma  conceitualização   compartilhada ”
POCAP SeCoM (Semantic Context Model) Ontologia  Time Ontologia  Temporal Event Ontologia  Spatial Ontologia  Spatial Event Ontologia  Actor Ontologia  Device Ontologia  Activity
POCAP Processo de Desenvolvimento POCAp Análise e especificação  Projeto Desenvolvimento Verificação e validação Implantação Operação Manutenção Aposentadoria
POCAP Processo de Desenvolvimento POCAp Análise e especificação  Projeto Desenvolvimento Verificação e validação Implantação Operação Manutenção Aposentadoria
POCAP
POCAP Papéis Analista Projetista Desenvolvedor Validador Engenheiro de Ontologias
POCAP Análise e especificação É a atividade de estabelecer o que a aplicação sensível ao contexto deve fazer (requisitos funcionais), as restrições na operação e desenvolvimento da aplicação (requisitos não funcionais), e o conjunto de informações de contexto necessário.
 
POCAP Projeto é a atividade de produzir uma estrutura de software – por exemplo, um projeto arquitetural – que satisfaz a especificação da aplicação sensível a contexto.
 
POCAP Desenvolvimento é a atividade de traduzir a estrutura de software produzida na atividade de projeto para um programa executável.
POCAP Verificação e validação corresponde às atividades de checar, revisar e testar se a aplicação está em conformidade com sua especificação e se atende aos requisitos estabelecidos.
MODEL-DRIVEN DEVELOPMENT FOR PERVASIVE INFORMATION SYSTEMS (MDD para Sistemas de Informação Ubíquos)
MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS Objetivos Prover eficiência e eficácia no desenvolvimento de SW Ubíquo Formular uma metodologia para a construção de Sistemas de Informação Ubíquos
Características relevantes ao se desenvolver um SW Ubíquo Elevado número de dispositivos Inovações tecnológicas  A heterogeneidade dos dispositivos  A potencial complexidade das interações entre os dispositivos MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
Considerações sobre funcionalidade Novos dispositivos integrados ao sistema Nova função é adicionada a um dispositivo Troca de um dispositivo por um mais moderno   Considerações sobre desenvolvimento Interação objeto-objeto  Manutenção/Evolução do sistema acomodando novas funcionalidades ou tecnologias   O quão baixo deve ser o nível de abstração MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
O MDD (Model-Driven Development) Abordagem de desenvolvimento baseada em modelos Maior independência dos modelos em relação às características particulares e mudanças de plataforma Automatização da tranformação de modelos e geração de código  MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
O uso dos conceitos do MDD são importantes, mas não suficientes   É necessária uma abordagem que: Aborde conceitos, técnicas e ferramentas modernos e adequados  Estabeleça uma estratégia adequada de desenvolvimento considerando as características dos sistemas ubíquos MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
A metodologia desenvolvida apresenta três divisões de agrupamento dos disposítivos para o desenvolvimento     MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS Dimensão de Classe
MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS Dimensão de Função
MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS Dimensão de Abstração
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
MPS.BR Melhoria de Processo do Software Brasileiro Avaliação  Formação de um setor de software competitivo Utiliza padrões de qualidade existentes (internacionais) Foco nas micro, pequenas e médias empresas
MPS.BR Dividido em 3 componentes:
MR-MPS Define níveis de maturidade que caracterizam estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos.
MR-MPS São sete os níveis:
MR-MPS Cada nível possui um perfil de processos associados, e esses são: Análise de Causas de Problemas e Resolução – ACP Gerência de Projetos – GPR  Gerência de Riscos – GRI Desenvolvimento para Reutilização – DRU Análise de Decisão e Resolução – ADR Gerência de Reutilização – GRU (evolução) Verificação – VER Validação – VAL Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE
Gerência de Projetos – GPR (evolução) Gerência de Reutilização – GRU Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP Medição – MED Garantia da Qualidade – GQA Gerência de Configuração – GCO Aquisição – AQU Gerência de Requisitos – GRE Gerência de Projetos – GPR MR-MPS
MR-MPS Cada nível também possui medidas associadas que são os atributos de processos (AP): AP 1.1 - O processo é executado : medida do quanto o processo atinge seu propósito; AP 2.1 - O processo é gerenciado : medida do quanto a execução do processo é gerenciada; AP 2.2 - Os produtos de trabalho do processo são gerenciados ; AP 3.1 - O processo é definido ; AP 3.2 - O processo está implementado ; AP 4.1 - O processo é medido ; AP 4.2 - O processo é controlado ; AP 5.1 - O processo é objeto de inovações ; AP 5.2 - O processo é otimizado continuamente .
A – Em otimização B – Gerenciado Quantitativamente C – Definido D – Largamente Definido E – Parcialmente Definido F – Gerenciado G – Parcialmente Gerenciado AP 1.1 - O processo é executado; AP 2.1 - O processo é gerenciado; AP 2.2 - Os produtos de trabalho  do processo são gerenciados;  AP 3.1 - O processo é definido; AP 3.2 - O processo está  implementado; AP 4.1 - O processo é medido; AP 4.2 - O processo é controlado; AP 5.1 - O processo é objeto de  inovações; AP 5.2 - O processo é otimizado  continuamente.
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
APLICAÇÃO DO MPS.BR NO POCAP
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
TRABALHOS FUTUROS Arquitetura de HW/SW  Propor novos métodos X Adequar os já existentes Análise das metodologias existentes
AGENDA Introdução O que é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
WEISER, Mark. The Computer for the 21st Century. Disponível em: <http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html>. Acesso em: 16 nov. 2008. FALCÃO, Taciana Pontual da Rocha; GOMES, Alex Sandro. Modelagem de soluções ubíquas para uso em salas de aula do Ensino Fundamental. Disponível em: <http://www.ime.uerj.br/~raquel/wied/ihc2004/TFalcaoEtAl.pdf>. Acesso em: 17 nov. 2008. SACCOL, Amarolinda Zanela; REINHARD, Nicolau. Tecnologias de informação móveis, sem fio e ubíquas: definições, estado-da-arte e oportunidades de pesquisa. Disponível em: <http://www.scielo.br/scielo.php?pid=S1415-65552007000400009&script=sci_arttext>. Acesso em: 17 nov. 2008. REFERÊNCIAS
Fernandes, J.E.M.; MACHADO, R.J.; CARVALHO,J.A.; Model-Driven Methodologies for Pervasive Information Systems Development. Universidade do Minho, 2004. Disponível em: <http://piano.dsi.uminho.pt/~rmac/privatefiles/papers/2004_MOMPES_FernandesMachadoCarvalho.pdf>. Acesso em: 18 nov. 2008. G. D. Abowd. Software engineering issues for ubiquitous computing. In ICSE '99: Proceedings of the 21st international conference on Software engineering, pages 75-84, Los Alamitos, CA, USA, 1999. IEEE Computer Society Press. BANAVAR, Guruduth et al. Challenges: An Application Model for Pervasive Computing. Disponível em: <http://www.research.ibm.com/PIMA/Documents/Mobicom2000.pdf>. Acesso em: 17 nov. 2008. REFERÊNCIAS
REFERÊNCIAS R. Grimm. One.world: Experiences with a pervasive computing architecture. Pervasive computing, 2004. RUBIO, José Miguel. Knowledge Management in the Ubiquitous Software Development. Disponível em: <http://delivery.acm.org/10.1145/1370000/1363280/a51rubio.pdf?key1=1363280&key2=2964407221&coll=GUIDE&dl=GUIDE&CFID=8066182&CFTOKEN=21773650>. Acesso em: 17 nov. 2008. LEAL, Kelly; SERRANO, Milene. Framework Intencional para Testes na Computação Ubíqua centrado em Sistemas Multi-Agentes e Requisitos Ubíquos Não-Funcionais. Disponível em: <http://web.teccomm.les.inf.puc-rio.br/uploads/9/9f/KellyPositionPaper2008.2.pdf>. Acesso em: 16 nov. 2008. SCALET, Danilo et al. MPS.BR - Melhoria de Processo do Software Brasileiro:  Guia Geral (Versão 1.2). Disponível em: <http://www.softex.br/mpsBr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 30 nov. 2008

TEES - Apresentacao Final

  • 1.
    OVERVIEW DE METODOLOGIASPARA COMPUTAÇÃO UBÍQUA RELACIONANDO COM MPS.BR Adolfo Guimarães Daniel Barreto Kharylim Machado Letícia Gindri
  • 2.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 3.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 4.
    INTRODUÇÃO &quot; As tecnologias mais profundas e duradouras são aquelas que desaparecem. Elas se mesclam na vida cotidiana até tornarem-se indissociáveis desta “ (Mark Weiser )
  • 5.
    INTRODUÇÃO O termoComputação Ubíqua, foi definido pela primeira vez por Mark Weiser, no seu artigo “O Computador do Século 21” ( The Computer for the 21st Century ). A computação não seria exclusividade de um computador e sim de diversos dispositivos conectados entre si
  • 6.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 7.
    A Computação Ubíquatorna a interação pessoa-máquina invisível Move-se para fora dos computadores e torna-se pervasiva na nossa vida cotidiana. Requer computadores pequenos e tecnologias de ligação a computadores maiores. O QUE É COMPUTAÇÃO UBÍQUA?
  • 8.
  • 9.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 10.
    MODELO DE BANAVARBanavar propõe um modelo focado numa mudança de paradigma, desafiando a comunidade a adotar uma nova visão de dispositivos, aplicações e ambientes. Esta reformulação de conceitos pode ser resumida em 3 idéias principais:
  • 11.
    MODELO DE BANAVARi. Um dispositivo é um portal, num espaço de aplicação/dados, e não um repositório de software customizado gerenciado pelo usuário; ii. uma aplicação é um meio pelo qual o usuário realiza uma tarefa, e não um trecho de código escrito para explorar as capacidades do dispositivo; iii. o ambiente computacional é uma espaço de informação, estendido para o usuário. E não um espaço virtual que existe para armazenar e rodar softwares.
  • 12.
    MODELO DE BANAVARPara que seja possível modelar essas aplicações, Banavar que é necessário que o ciclo de vida de uma aplicação deve ser dividida em três partes: Tempo de projeto (design-time): É quando o desenvolvedor cria, mantém e aprimora a aplicação. Tempo de carga (load-time): O sistema compõe, adapta e carrega os componentes da aplicação em uma instância em um dispositivo de hardware em particular. Tempo de execução (run-time): Quando o usuário final invoca a aplicação e usa suas funcionalidades.
  • 13.
    MODELO DE BANAVARTempo de projeto (design-time): Se o &quot;dispositivo é um portal&quot;, então a aplicação não deve ser escrita com um determinado dispositivo em mente. O desenvolvedor fazer suposições sobre tamanho de tela ou capacidades de hardware (e se não houver tela?) A interface com usuário não deve ser definida como uma composição rígida da interação. Não se deve assumir que um determinado serviço está disponível. Podem vir a existir serviços disponíveis que não são conhecidos pelo desenvolvedor no design-time.
  • 14.
    MODELO DE BANAVARTempo de projeto (design-time): Metodologia de desenvolvimento Não há uma metodologia ideal para o desenvolvimento deste modelo, mas é importante que seja qual for a metodologia escolhida, que o desenvolvimento da aplicação seja essencialmente focado na tarefa do usuário, ao invés da interação do mesmo com a interface.
  • 15.
    MODELO DE BANAVARTempo de carga (load-time): Aplicações e serviços &quot;vivem&quot; em um ambiente físico e distribuído. É necessário um mecanismo para identificar e enumerar essas aplicações e serviços (Dynamic discovery). Dispositivos necessitam negociar requisitos e capacidades para rodar os serviços que dispõe. O sistema deve suportar a seleção dinâmica de uma interface apropriada para a aplicação baseada nos recursos do dispositivo. O sistema deve integrar-se com outras aplicações e serviços disponíveis no ambiente.
  • 16.
    MODELO DE BANAVARTempo de execução (run-time): A aplicação deve sempre monitorar os recursos do portal (dispositivo), para adaptar-se a esses recursos. O run-time deve conduzir uma mudança de contexto quando ocorrer uma mudança de ambiente, durante uma tarefa (ex: do escritório para o carro) A aplicação também deve manipular erros não esperados, queda em serviços ou problemas no próprio portal.
  • 17.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 18.
    MODELO DE GRIMM(ONE.WORLD) Robert Grimm apresenta outra proposta de modelo mais específica. Trata-se, de fato, de uma arquitetura para a construção de aplicações pervasivas. Chamada &quot;One.world&quot;, ela define serviços básicos do &quot;núcleo&quot; de um sistema ubíquo, que supririam determinadas necessidades fundamentais.
  • 19.
    MODELO DE GRIMM(ONE.WORLD) As principais necessidades seriam:
  • 20.
    MODELO DE GRIMM(ONE.WORLD) Os fundamentos principais do one.world são: i. uma máquina virtual, para lidar com a heterogeneidade de dispositivos e sistemas operacionais; ii. tuplas, responsáveis por prover uma forma simplificada de armazenamento; iii. eventos assíncronos, capazes de fornecer a notificação explícita de uma mudança de contexto; iv. e os ambientes, tratando-se de contâiners para cada aplicação e seus respectivos dados.
  • 21.
    MODELO DE GRIMM(ONE.WORLD) Aplicações de teste para o one.world: Chat : um sistema de mensagens de texto e áudio capaz de gerenciar mudanças de localização do usuário. Labscape : Assistente digital para laboratórios de biologia. “Segue” o pesquisador, descobrindo qual o dispositivo mais próximo dele, permitindo a transferência automática dos dados necessários.
  • 22.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 23.
  • 24.
    CENTERED DESIGN INUSER José Miguel Rubio L. Pontificia Universidad Católica de Valparaíso, Chile Design centrado no usuário Importância da intervenção do usuário nas atividades de avaliação (pessoas, trabalho e ambiente delas)
  • 25.
    CENTERED DESIGN INUSER Modelo de Processo Iterativo
  • 26.
    Ciclo de vidaem Cascata A avaliação não é interna, ocupando uma posição estrita no ciclo Mas ela acaba se tornando uma atividade em operação contínua. Permite o feedback do processo de desenvolvimento. CENTERED DESIGN IN USER
  • 27.
    Trabalho Relacionado :UFPE Framework que proporciona o desenvolvimento de artefatos ubíquos educacionais Técnicas: Etnografia Rápida e Cenários Etnografia rápida: observação mais direcionada e estreita para reduzir o tempo gasto no processo Cenários: criação de quatro cenários CENTERED DESIGN IN USER
  • 28.
    O PROCESSO POCAP(Process for Ontological Context-aware Applications)
  • 29.
    POCAP Desenvolvido em2006 “ Um processo de software e um modelo ontológico para apoio ao desenvolvimento de aplicações sensíveis a contexto” – Renato Bulcão (Doutorado/USP) Empresa INNOLUTIONS (Ribeirão Preto/SP)
  • 30.
    POCAP Computação UbíquaInterfaces naturais Captura e acesso automatizado de atividades humanas Computação sensível a contexto Computação no cotidiano
  • 31.
    POCAP Computação UbíquaInterfaces naturais têm como objetivo facilitar a capacidade de comunicação entre usuários e computadores ao fornecer suporte a formas naturais de comunicação humana. Captura e Acesso automatizado são aquelas que registram de modo automático informações de experiências do cotidiano humano para acesso posterior.
  • 32.
    POCAP Computação UbíquaComputação sensível a contexto são aquelas que utilizam informações de contexto para fornecer serviços e informações relevantes a usuários e a outras aplicações na realização de alguma tarefa. Computação no cotidiano são aquelas que devem fornecer suporte computacional contínuo – 24 horas por dia, 7 dias por semana – a atividades que podem ocorrer de forma concorrente, sem início e término bem definidos, e que podem ser interrompidas repentinamente.
  • 33.
    POCAP O trabalhoestudado apresenta uma metodologia de desenvolvimento para aplicações ubíquas onde a computação sensível ao contexto é levada em consideração.
  • 34.
    POCAP Computação sensívelao contexto Ontologias
  • 35.
    POCAP Computação sensívelao Contexto (1994) “seriam informações de localização, de identidade de pessoas e de objetos próximos entre si e das mudanças nesses objetos” [Schilit & Theimer, 2004] (2001) “é qualquer informação que possa ser utilizada para catacterizar uma entidade. Uma entidade é uma pessoa, lugar ou objeto considerado relevante para uma interação entre um usuário e uma aplicação, incluindo o usuário e a aplicação em questão” [Dey et al., 2001]
  • 36.
    POCAP Computação sensívelao contexto Características Apresentação de informações e serviços para o usuário Execução automática de um serviço União de informações de contexto
  • 37.
    POCAP Computação sensívelao contexto Informações de Contexto Who ➔ identificação Where ➔ localização When ➔ tempo What ➔ atividade Why ➔ motivação How ➔ modo de captura e acesso
  • 38.
    POCAP Ontologias “Ontologia é uma especificação explícita e formal de uma conceitualização compartilhada ”
  • 39.
    POCAP SeCoM (SemanticContext Model) Ontologia Time Ontologia Temporal Event Ontologia Spatial Ontologia Spatial Event Ontologia Actor Ontologia Device Ontologia Activity
  • 40.
    POCAP Processo deDesenvolvimento POCAp Análise e especificação Projeto Desenvolvimento Verificação e validação Implantação Operação Manutenção Aposentadoria
  • 41.
    POCAP Processo deDesenvolvimento POCAp Análise e especificação Projeto Desenvolvimento Verificação e validação Implantação Operação Manutenção Aposentadoria
  • 42.
  • 43.
    POCAP Papéis AnalistaProjetista Desenvolvedor Validador Engenheiro de Ontologias
  • 44.
    POCAP Análise eespecificação É a atividade de estabelecer o que a aplicação sensível ao contexto deve fazer (requisitos funcionais), as restrições na operação e desenvolvimento da aplicação (requisitos não funcionais), e o conjunto de informações de contexto necessário.
  • 45.
  • 46.
    POCAP Projeto éa atividade de produzir uma estrutura de software – por exemplo, um projeto arquitetural – que satisfaz a especificação da aplicação sensível a contexto.
  • 47.
  • 48.
    POCAP Desenvolvimento éa atividade de traduzir a estrutura de software produzida na atividade de projeto para um programa executável.
  • 49.
    POCAP Verificação evalidação corresponde às atividades de checar, revisar e testar se a aplicação está em conformidade com sua especificação e se atende aos requisitos estabelecidos.
  • 50.
    MODEL-DRIVEN DEVELOPMENT FORPERVASIVE INFORMATION SYSTEMS (MDD para Sistemas de Informação Ubíquos)
  • 51.
    MDD PARA SISTEMASDE INFORMAÇÃO UBÍQUOS Objetivos Prover eficiência e eficácia no desenvolvimento de SW Ubíquo Formular uma metodologia para a construção de Sistemas de Informação Ubíquos
  • 52.
    Características relevantes aose desenvolver um SW Ubíquo Elevado número de dispositivos Inovações tecnológicas  A heterogeneidade dos dispositivos A potencial complexidade das interações entre os dispositivos MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
  • 53.
    Considerações sobre funcionalidadeNovos dispositivos integrados ao sistema Nova função é adicionada a um dispositivo Troca de um dispositivo por um mais moderno   Considerações sobre desenvolvimento Interação objeto-objeto Manutenção/Evolução do sistema acomodando novas funcionalidades ou tecnologias   O quão baixo deve ser o nível de abstração MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
  • 54.
    O MDD (Model-DrivenDevelopment) Abordagem de desenvolvimento baseada em modelos Maior independência dos modelos em relação às características particulares e mudanças de plataforma Automatização da tranformação de modelos e geração de código MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
  • 55.
    O uso dosconceitos do MDD são importantes, mas não suficientes   É necessária uma abordagem que: Aborde conceitos, técnicas e ferramentas modernos e adequados Estabeleça uma estratégia adequada de desenvolvimento considerando as características dos sistemas ubíquos MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
  • 56.
    A metodologia desenvolvidaapresenta três divisões de agrupamento dos disposítivos para o desenvolvimento     MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS
  • 57.
    MDD PARA SISTEMASDE INFORMAÇÃO UBÍQUOS Dimensão de Classe
  • 58.
    MDD PARA SISTEMASDE INFORMAÇÃO UBÍQUOS Dimensão de Função
  • 59.
    MDD PARA SISTEMASDE INFORMAÇÃO UBÍQUOS Dimensão de Abstração
  • 60.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 61.
    MPS.BR Melhoria deProcesso do Software Brasileiro Avaliação Formação de um setor de software competitivo Utiliza padrões de qualidade existentes (internacionais) Foco nas micro, pequenas e médias empresas
  • 62.
    MPS.BR Dividido em3 componentes:
  • 63.
    MR-MPS Define níveisde maturidade que caracterizam estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos.
  • 64.
    MR-MPS São seteos níveis:
  • 65.
    MR-MPS Cada nívelpossui um perfil de processos associados, e esses são: Análise de Causas de Problemas e Resolução – ACP Gerência de Projetos – GPR Gerência de Riscos – GRI Desenvolvimento para Reutilização – DRU Análise de Decisão e Resolução – ADR Gerência de Reutilização – GRU (evolução) Verificação – VER Validação – VAL Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE
  • 66.
    Gerência de Projetos– GPR (evolução) Gerência de Reutilização – GRU Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP Medição – MED Garantia da Qualidade – GQA Gerência de Configuração – GCO Aquisição – AQU Gerência de Requisitos – GRE Gerência de Projetos – GPR MR-MPS
  • 67.
    MR-MPS Cada níveltambém possui medidas associadas que são os atributos de processos (AP): AP 1.1 - O processo é executado : medida do quanto o processo atinge seu propósito; AP 2.1 - O processo é gerenciado : medida do quanto a execução do processo é gerenciada; AP 2.2 - Os produtos de trabalho do processo são gerenciados ; AP 3.1 - O processo é definido ; AP 3.2 - O processo está implementado ; AP 4.1 - O processo é medido ; AP 4.2 - O processo é controlado ; AP 5.1 - O processo é objeto de inovações ; AP 5.2 - O processo é otimizado continuamente .
  • 68.
    A – Emotimização B – Gerenciado Quantitativamente C – Definido D – Largamente Definido E – Parcialmente Definido F – Gerenciado G – Parcialmente Gerenciado AP 1.1 - O processo é executado; AP 2.1 - O processo é gerenciado; AP 2.2 - Os produtos de trabalho do processo são gerenciados; AP 3.1 - O processo é definido; AP 3.2 - O processo está implementado; AP 4.1 - O processo é medido; AP 4.2 - O processo é controlado; AP 5.1 - O processo é objeto de inovações; AP 5.2 - O processo é otimizado continuamente.
  • 69.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 70.
  • 71.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 72.
    TRABALHOS FUTUROS Arquiteturade HW/SW Propor novos métodos X Adequar os já existentes Análise das metodologias existentes
  • 73.
    AGENDA Introdução Oque é computação ubíqua? Modelo de Banavar Modelo de Grimm (one.world) Metodologias de Desenvolvimento MPS.BR Aplicação do MPS.BR no POCAp Trabalhos Futuros Referências
  • 74.
    WEISER, Mark. TheComputer for the 21st Century. Disponível em: <http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html>. Acesso em: 16 nov. 2008. FALCÃO, Taciana Pontual da Rocha; GOMES, Alex Sandro. Modelagem de soluções ubíquas para uso em salas de aula do Ensino Fundamental. Disponível em: <http://www.ime.uerj.br/~raquel/wied/ihc2004/TFalcaoEtAl.pdf>. Acesso em: 17 nov. 2008. SACCOL, Amarolinda Zanela; REINHARD, Nicolau. Tecnologias de informação móveis, sem fio e ubíquas: definições, estado-da-arte e oportunidades de pesquisa. Disponível em: <http://www.scielo.br/scielo.php?pid=S1415-65552007000400009&script=sci_arttext>. Acesso em: 17 nov. 2008. REFERÊNCIAS
  • 75.
    Fernandes, J.E.M.; MACHADO,R.J.; CARVALHO,J.A.; Model-Driven Methodologies for Pervasive Information Systems Development. Universidade do Minho, 2004. Disponível em: <http://piano.dsi.uminho.pt/~rmac/privatefiles/papers/2004_MOMPES_FernandesMachadoCarvalho.pdf>. Acesso em: 18 nov. 2008. G. D. Abowd. Software engineering issues for ubiquitous computing. In ICSE '99: Proceedings of the 21st international conference on Software engineering, pages 75-84, Los Alamitos, CA, USA, 1999. IEEE Computer Society Press. BANAVAR, Guruduth et al. Challenges: An Application Model for Pervasive Computing. Disponível em: <http://www.research.ibm.com/PIMA/Documents/Mobicom2000.pdf>. Acesso em: 17 nov. 2008. REFERÊNCIAS
  • 76.
    REFERÊNCIAS R. Grimm.One.world: Experiences with a pervasive computing architecture. Pervasive computing, 2004. RUBIO, José Miguel. Knowledge Management in the Ubiquitous Software Development. Disponível em: <http://delivery.acm.org/10.1145/1370000/1363280/a51rubio.pdf?key1=1363280&key2=2964407221&coll=GUIDE&dl=GUIDE&CFID=8066182&CFTOKEN=21773650>. Acesso em: 17 nov. 2008. LEAL, Kelly; SERRANO, Milene. Framework Intencional para Testes na Computação Ubíqua centrado em Sistemas Multi-Agentes e Requisitos Ubíquos Não-Funcionais. Disponível em: <http://web.teccomm.les.inf.puc-rio.br/uploads/9/9f/KellyPositionPaper2008.2.pdf>. Acesso em: 16 nov. 2008. SCALET, Danilo et al. MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral (Versão 1.2). Disponível em: <http://www.softex.br/mpsBr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>. Acesso em: 30 nov. 2008