TEES - Apresentacao Final

OVERVIEW DE OVERVIEW DE METODOLOGIAS PARA METODOLOGIAS PARA COMPUTAÇÃO UBÍQUA COMPUTAÇÃO UBÍQUA RELACIONANDO COM MPS.BRRELACIONANDO COM MPS.BR

Adolfo GuimarãesDaniel BarretoKharylim MachadoLetí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" 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


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


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


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.


As principais necessidades seriam:


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.


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


CENTERED DESIGN IN USER


o José Miguel Rubio L.

o Pontificia Universidad Católica de Valparaíso, Chile

o Design centrado no usuário

o Importância da intervenção do usuário nas atividades de avaliação (pessoas, trabalho e ambiente delas)


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.


• Trabalho Relacionado :• UFPEo Framework que proporciona o

desenvolvimento de artefatos ubíquos educacionais

o Técnicas: Etnografia Rápida e CenáriosEtnografia rápida: observação mais direcionada e estreita para reduzir o tempo gasto no processo

Cenários: criação de quatro cenários


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íquao Interfaces naturaiso Captura e acesso automatizado de

atividades humanaso Computação sensível a contextoo Computação no cotidiano

POCAP

• Computação Ubíquao 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.

o 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íquao 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.

o 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 Contextoo (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]

o (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 contextoo 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 contextoo 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

o “Ontologia é uma especificação explícita e formal de uma conceitualização compartilhada”

POCAP

• SeCoM (Semantic Context Model)o Ontologia Timeo Ontologia Temporal Evento Ontologia Spatialo Ontologia Spatial Evento Ontologia Actoro Ontologia Deviceo Ontologia Activity

POCAP

• Processo de Desenvolvimento POCApo Análise e especificação o Projetoo Desenvolvimentoo Verificação e validaçãoo Implantaçãoo Operaçãoo Manutençãoo Aposentadoria

POCAP

• Processo de Desenvolvimento POCApo Análise e especificação o Projetoo Desenvolvimentoo Verificação e validaçãoo Implantaçãoo Operaçãoo Manutençãoo Aposentadoria

POCAP

POCAP

• Papéiso Analistao Projetistao Desenvolvedoro Validador

o Engenheiro de Ontologias

POCAP

• Análise e especificaçãoo É 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

• Projetoo é 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

• Desenvolvimentoo é a atividade de traduzir a estrutura

de software produzida na atividade de projeto para um programa executável.

POCAP

• Verificação e validaçãoo 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 DEVELOPMENTFOR PERVASIVE INFORMATION SYSTEMS

(MDD para Sistemas de Informação Ubíquos)

MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOS

• Objetivos

o Prover eficiência e eficácia no desenvolvimento de SW Ubíquo

o 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


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


• O MDD (Model-Driven Development)o Abordagem de desenvolvimento baseada

em modeloso Maior independência dos modelos em

relação às características particulares e mudanças de plataforma

o Automatização da tranformação de modelos e geração de código


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


A metodologia desenvolvida apresenta três divisões de agrupamento dos disposítivos para o desenvolvimento


MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOSDimensão de Classe

MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOSDimensão de Função

MDD PARA SISTEMAS DE INFORMAÇÃO UBÍQUOSDimensão de Abstração

AGENDA


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:o Análise de Causas de Problemas e Resolução – ACPo Gerência de Projetos – GPR o Gerência de Riscos – GRIo Desenvolvimento para Reutilização – DRUo Análise de Decisão e Resolução – ADRo Gerência de Reutilização – GRU (evolução)o Verificação – VERo Validação – VALo Projeto e Construção do Produto – PCPo Integração do Produto – ITPo 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):o AP 1.1 - O processo é executado: medida do quanto o

processo atinge seu propósito;o AP 2.1 - O processo é gerenciado: medida do quanto a

execução do processo é gerenciada;o AP 2.2 - Os produtos de trabalho do processo são

gerenciados;o AP 3.1 - O processo é definido;o AP 3.2 - O processo está implementado;o AP 4.1 - O processo é medido;o AP 4.2 - O processo é controlado;o AP 5.1 - O processo é objeto de inovações;o AP 5.2 - O processo é otimizado continuamente.

A – Em otimizaçãoB – Gerenciado QuantitativamenteC – DefinidoD – Largamente DefinidoE – Parcialmente DefinidoF – GerenciadoG – 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


APLICAÇÃO DO MPS.BR NO POCAP

AGENDA


TRABALHOS FUTUROS

• Arquitetura de HW/SW

• Propor novos métodos X Adequar os já existentes

• Análise das metodologias existentes

AGENDA


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

Technology