HyperDE Framework e Ambiente de Desenvolvimento dirigido por Ontologias para Aplicações Hipermídia Bom dia... Vou apresentar o HyperDE, que é o fruto desse.

Apresentação em tema: "HyperDE Framework e Ambiente de Desenvolvimento dirigido por Ontologias para Aplicações Hipermídia Bom dia... Vou apresentar o HyperDE, que é o fruto desse."— Transcrição da apresentação:

1 HyperDE Framework e Ambiente de Desenvolvimento dirigido por Ontologias para Aplicações Hipermídia
Bom dia... Vou apresentar o HyperDE, que é o fruto desse meu trabalho de mestrado que eu desenvolvi nestes ultimos meses... E vou tentar passar pra vocês o que faz dele o que está escrito aqui nesse subtítulo, que é uma combinação de um framework MVC e ambiente de desenvolvimento para a construção de aplicações baseadas nos métodos OOHDM e SHDM. Demetrius Arraes Nunes Dissertação de Mestrado Orientador: Daniel Schwabe Departamento de Informática – PUC-Rio Rio de Janeiro, 30 de março de 2005

2 Tópicos Motivação Objetivos O que é o HyperDE?
Criando uma aplicação com o HyperDE Trabalhos relacionados Trabalhos futuros Contribuições Primeiro, o que me levou a construir o HyperDE e os objetivos do ambiente. Depois eu vou mostrar do que é feito o HyperDE, passeando um pouco em uma aplicação e explicando alguns pontos da arquitetura de implementação. Para entender tudo com mais detalhe, farei uma demonstração desenvolvendo uma pequena aplicação do zero usando o HyperDE e tentando explorar quase todos os recursos do ambiente. Daí, veremos alguns trabalhos relacionados, coisas que ainda podem ser feitas relacionadas ao HyperDE (e são muitas!) e por fim as principais contribuições desta dissertação.

3 A Web atual Páginas em código HTML com objetivo de orientar o navegador a gerar uma apresentação das informações Texto, Imagens, etc, compreensível apenas por pessoas Conteúdo + Apresentação misturados “No separation of concerns” Mecanismos de busca se utilizam de algoritmos basicamente estatísticos Pra começar, vou falar um pouco da Web como a gente conhece hoje, e que não é muito diferente do que foi concebido pelo seu principal criador, Tim Berners-Lee. Lee vendeu a WWW para seus gerentes no CERN, lá nos anos 90, como uma plataforma simples para troca de documentos entre cientistas na Internet, ainda acadêmica na época. Assim surgiu o protocolo HTTP e a linguagem HTML e o 1º browser criado por ele mesmo chamado Mosaic. Passados mais de 15 anos, a Internet e principalmente a WWW acabou se tornando uma das principais plataformas para o desenvolvimento de aplicações, tais como lojas de e-commerce, internet banking, enciclopedias, gestao de conhecimento, ensino a distancia, e muitas outras. Todas unidas pelas caracteristicas hipertextuais da WWW, onde temos páginas ligadas através de hyperlinks de uma forma bastante “livre”. Mas a Web nunca foi projetada como plataforma para aplicações e por isso estamos realmente chegando perto dos limites da plataforma, quando temos que confrontar estes problemas aqui: (... Apontar a apresentacao ... Mencionar excesso de informação )

4 A Web Semântica Extensão da Web atual
Objetivo principal é adicionar significado às informações disponíveis na Web de forma a ser processável por máquinas Interoperabilidade: possibilitará a integração entre aplicações Automação: agentes de software serão capazes de executar muitas tarefas que necessitam de cognição e que hoje só podem ser executadas por pessoas Ok, então o Tim Berners-Lee está agora pensando na próxima geração da Web, ao que ele batizou de Web Semântica. A Web Semântica está sendo construída em cima da Web atual, em que os principais objetivos são: (... Apontar apresentação ...)

5 Web Semântica HTML, CSS, XUL, XAML e outras linguagens serão usadas para guiar diversos tipos de navegadores a gerarem apresentações diferenciadas RDF/RDF(s)/OWL (todos com representação em XML) serão usados para descrever o conteúdo de forma semântica, i.e., com significado para humanos E máquinas Possibilitará mecanismos de busca semântica com inferências e uso de inteligência artificial Em termos tecnológicos, a Web Semântica quer adereçar alguns problemas importantes, como promover uma separação entre código que descreve o conteúdo e o que descreve a apresentação, fornecer linguagens como RDF e OWL para fazer isso, onde você pode através de meta-dados, descrever uma informação que poderá ser “entendida” e processada por outros softwares.

6 A Onda da Web Semântica (na visão de Tim Berners-Lee)
Então, aqui a gente pode ver nesta imagem da “Onda Semântica” que demonstra os vários níveis de significado que poderemos chegar e algumas tecnologias e linguagens que nos ajudarão a chegar lá. Atualmente, em termos acadêmicos, estamos ainda tentando passar desse nivel (apontar), enquanto que em termos de mercado geral, ainda estão por aqui (apontar). Portanto, este trabalho é mais um de muitos, tentando avançar um pouco nesta evolução.

7 MDA – Model Driven Architecture
Produção de software através apenas de modelagem Toda fase de implementação é feita de forma automatizada, processando o modelo Por isso, os sistemas são construídos independente de plataforma A idéia é antiga: OOHDM (1995) é um exemplo de MDA para aplicação hipermídia Agora a OMG está “padronizando” e muitas empresas (IBM, Microsoft, Sun, ...) estão apoiando Agora, mudando um pouco de assunto, vou falar de MDA. MDA, que significa em bom português “Arquitetura Orientada a Modelos”, é uma combinação de processo e arquitetura que permite construir uma aplicação executável, apenas pela especificação através de modelos. Ou seja, toda a etapa de implementação é feita de forma automática, pela máquina, apenas processando os modelos fornecidos. Isso possibilitaria por exemplo, a construção de aplicações independentes da plataforma de hardware E software, pois a aplicação estaria totalmente definida em modelos e não em uma linguagem de programação específica. É claro que muita gente, assim como eu, considera o código escrito em linguagem de programação uma parte do modelo, já que é ali onde somos “forçados” a descrever todos os detalhes da aplicação. Mas MDA não vai necessariamente contra o uso de linguagens de programação, desde que não seja você que tenha que usá-la pra escrever um programa e sim a própria máquina. MDA não é uma idéia nova, o conceito existe há muitos e muitos anos, por exemplo, temos OOHDM que é um método que baseia a construção de uma aplicação hipermídia em modelos. Mas por que MDA está ganhando momento agora? Bom, a OMG, responsável pela UML entre outras coisas, se “apossou” do MDA e está institucionalizando-o como um padrão com a ajuda de fornecedoras de ferramentas nesse mercado como IBM, Microsoft e outras. Certamente uma disseminação maior de MDA vai ajudá-las a vender mais ambientes de desenvolvimento e ferramentas, porque agora a Microsoft vai ter a oportunidade de te vender um produto para compilação de modelos MDA para a plataforma .NET, assim como a Sun vai vender para Java, etc. Mas enfim, MDA realmente tem seus benefícios, mas também tem seus limites.

8 Domain Specific Languages (DSL)
“Little languages”: linguagens de programação criadas para utilização dentro de um domínio de problema específico É, de certa forma, um conceito antagônico a MDA, porque é “code-oriented”: Cria-se uma linguagem de programação e Implementa-se o sistema usando essa linguagem Passando pro outro lado do espectro, tem o pessoal que gosta de DSLs. DSLs são linguagens de programação criadas para um domínio de problema especifico. A filosofia disso vai assim: já que o código é o único modelo realmente completo da aplicação, antes de codificar, vamos criar uma linguagem de programação pra nossa aplicação que seja especialmente expressiva e concisa neste contexto. E aí, tem 2 formas de fazer isso, uma é realmente criar uma linguagem do zero e um interpretador ou compilador usando um YACC ou algo assim, a 2ª forma é utilizar uma linguagem de propósito geral já existente e estendê-la, seja através de bibliotecas, metaprogramação ou outros recursos.

9 Ruby/DSL Ruby: linguagem dinamicamente tipada, interpretada, orientada a objetos Pouca ou nenhuma distinção entre tempo de “compilação” e de execução Sintaxe tolerante e concisa Indicada para gerar DSLs baseadas em modelos OO É aí que entra o Ruby. Ruby é uma linguagem de programação dinâmica orientada a objetos, criada no Japão em 1993, que se parece com uma mistura de Smalltalk e Python. No Japão ela é até mais usada que Python na verdade e só não conseguiu se difundir muito no ocidente pela falta de documentação que não em japonês, mas isso tem mudado com muitos livros sendo lançados recentemente em inglês sobre a linguagem e com o surgimento do Rails, o framework MVC para aplicações web em que o HyperDE foi baseado e que está com um momento incrível atualmente, ganhando cada vez mais popularidade a cada dia. Note que eu falei em linguagem dinâmica e não de script, apesar de ela ser sim uma linguagem de script. É que o termo linguagem de “script” ultimamente ganhou uma conotação pejorativa, de linguagens que só servem para aplicações pequenas. E por que Ruby é indicada para se fazer uma DSL? Bom, no meu caso por 2 motivos, 1º, por ela ser totalmente orientada a objetos, sem nenhuma exceçao. Tudo é objeto pra valer, até true e false, números, até nulo é objeto. E como estou trabalhando sob uma perspectiva OO isso faz muito sentido pra mim. E 2º porque os recursos de metaprogramação e reflexão de Ruby são realmente fantásticos e fáceis de usar, além das classes de Ruby serem todas abertas, ou seja, você pode extender ou mudar qualquer coisa da linguagem, até operação de soma, concatenação de strings, realmente qualquer coisa. Eu coloquei este exemplo bobinho aqui (apontar) pra mostrar a sintaxe simples e dá pra ver que até o número 10 é um objeto e possui métodos como o “times” que simplesmente repete esse bloco aqui 10 vezes. Se a gente ler em voz alta fica até fácil de entender. 10.times do print “Hello HyperDE!” end

10 SHDM Versão semântica do OOHDM original Define processo e arquitetura
Orientada a modelos: Conceitual Navegacional Interface Abstrata Metamodelos e Modelos são definidos através de ontologias Implementação pode ser feita artesanalmente ou automatizada por ferramentas/ambientes Ok, mudando de assunto mais uma vez (eu prometo que isso tudo vai fazer sentido daqui a pouco), temos o SHDM, que é uma extensão do método OOHDM, em sua versão semântica e assim como o OOHDM define processos e arquitetura e uma forma de criar aplicações hipermídia fortemente apoiadas em modelos, dos quais posso destacar o modelo navegacional onde você define todo o comportamento navegacional da aplicação. A diferença básica entre o OOHDM e o SHDM é que no OOHDM você construía esses modelos usando basicamente uma UML estendida e no SHDM você define os modelos com ontologias. Como eu falei antes, o SHDM e OOHDM são exemplos de uma arquitetura orientada a modelos, uma MDA, pois a aplicação pode ser toda ou quase toda extraída dos modelos. E aí temos a etapa de implementação, que pode ser feita artesanalmente ou facilitada através de ferramentas, ambientes e frameworks.

11 HyperDE D S L S H D M MDA Web Semântica
Ok, finalmente chegou a hora de juntar todas as peças. Então, eu falei de Web Semântica e de MDA. Esses dois conceitos são amarrados pelo método SHDM, que é uma MDA baseada em ontologias. E eu falei em DSL também, por que? Como eu falei, o pessoal que defende MDA puro não quer programar nada, mas eu acredito que normalmente, a gente chega a um ponto em que os modelos, sejam eles representados graficamente ou de alguma outra forma, ficam tão complexos, que simplesmente é mais fácil representa-los em código em linguagem de programação do que inventar notações e outras formas de representação. Então partindo do pressuposto que eu irei usar MDA até onde der e depois programar o que faltar, seria bom ter a minha disposição uma DSL que me facilitasse a vida nessa horas. E é exatamente isso que o HyperDE tenta prover. Ele adota o SHDM e arquitetura MDA como a maneira de fazer grande parte de uma aplicação hipermídia, mas deixa espaços programáveis para que você possa preencher os buracos de lógica da aplicação usando uma DSL baseada em Ruby que é gerada a partir do modelo navegacional da própria aplicação. MDA Web Semântica

12 O que é o HyperDE? (I) Uma arquitetura de software, um ambiente de desenvolvimento e ferramentas de apoio Permite Desenvolvimento através de uma Interface Web Desenvolvimento interativo Prototipação rápida de uma aplicação SHDM, sem necessidade de programação (ou quase) Então, o que é o HyperDE? Uma arquitetura de software baseada em um framework MVC para web e um ambiente de desenvolvimento rápido para aplicações baseadas nos métodos OOHDM e SHDM. Como um ambiente de desenvolvimento, é possível através da interface Web do ambiente, construir uma aplicação interativamente, de forma bastante ágil, quase sem precisar programar nada.

13 O que é o HyperDE? (II) Um framework MVC
Camada de (M)odelo fornece primitivas baseadas no SHDM (classes navegacionais, contextos, índices, nós, elos, ...) Metamodelo e Modelo é persistido em RDF(S) Geração dinâmica de DSL para manipulação do modelo e codificação de lógica de negócios Camada de (C)ontrole implementa a lógica definida pelo modelo navegacional Camada de (V)isão fornece funções de auxílio para uma implementação “quasi-abstrata” Como framework MVC, o HyperDE fornece uma biblioteca de classes que cobre as camadas de modelo, controle e visão de uma aplicação Web. A camada de modelo é especialmente importante, porque é ela a responsável por gerar dinamicamente a DSL da aplicação, a medida que vamos construindo e também é responsável pela persistência tanto do modelo da aplicação como o metamodelo das primitivas do SHDM na forma de RDF(s). A camada de controle implementa a lógica navegacional da aplicação especificada no modelo navegacional. E a camada de visão fornece uma série de funções de biblioteca para ajudar na construção de visões sobre os objetos da aplicação.

14 HyperDE Demonstração Bom, agora começa a parte mais tensa da apresentação onde eu vou efetivamente demonstrar o ambiente. Se Murphy resolver aparecer e der alguma coisa errada, por favor não vaiem, isto aqui ainda é um ambiente experimental.

15 Antes de começar a mostrar a aplicação de exemplo, vamos dar uma rápida olhada no modelo navegacional. A gente pode ver aqui que temos 5 classes, Pessoa, Professor e Aluno, que são subclasses de Pessoa, temos Publicacao e Area de Pesquisa. Essas classes estão relacionadas através de elos: Professor orienta Aluno, Pessoa escreve Publicacao e trabalha em Area de Pesquisa. Temos tambem alguns atributos navegacionais definidos, por exemplo, Area de Pesquisa possui um indice de alunos e professores, Aluno possui uma ancora para seu orientador entre outras coisas. A gente vai ver isso em mais detalhe se der tempo mais adiante.

16 Pessoa por Publicação Professor Alfa por Área Aluno por Professor Publicação por Pessoa Área de Pesquisa Alunos Alunos por Professor Professores Áreas de Pesquisa Aqui a gente tem o esquema de contextos navegacionais e índices da aplicação. Então a gente pode ver que temos índices de Alunos, Professores, Areas de Pesquisa, Alunos Por Professor, temos também alguns Landmarks, que são pontos de acesso globais na aplicação e temos os contextos em que podemos navegar sobre os objetos (os nós). Então a gente pode navegar pelos alunos por Area, alfabeticamente, por professor, podemos navegar nas publicacoes por pessoa, nas areas de pesquisa alfabeticamente ou por pessoa tambem... Entao, vamos ver isso funcionando.

17 HyperDE Arquitetura de Implementação
Ok, então o que vocês viram funcionando agora está resumido aqui neste esquema de pacotes da arquitetura de implementação, onde a gente tem o pacote da camada de modelo que comporta o metamodelo SHDM e o modelo navegacional, que são persistidos no banco de dados RDF chamado Sesame. Temos a camada de controle que contém os controladores do back-end do ambiente de desenvolvimento, onde a gente pode editar o modelo da aplicação e o controlador de navegação que é o que efetivamente quem executa a navegação da aplicação modelada. O pacote da camada de visão contém a lógica de apresentação da aplicação e a biblioteca de auxílio para construção de visões customizadas, que a gente vai ver mais adiante. Tudo isso pode ser usado via a interface Web, que é a principal forma, ou também através de uma interface de console que eu vou mostrar daqui a pouco e de ferramentas para importação/exportação de modelos que eu também vou mostrar mais adiante.

18 SeRQL Linguagem de Consulta para RDF
Professor Nome Titulação Nome: Maria Titulação: Mestre Nome: Maria Titulação: Mestre Nome: José Titulação: Doutor Ok, vou abrir um rápido parenteses aqui pra explicar um pouco da linguagem SeRQL, que é a linguagem de consulta utilizada pra selecionar os nós que fazem parte de um contexto ou índice na aplicação. Em um modelo RDF, diferentemente de um relacional, toda a informação é armazenada na forma de grafos orientados. Quando fazemos uma consulta, na verdade estamos estabelecendo um padrão ou uma máscara que deve ser aplicada ao grafo como um todo para a extração dos padrões compatíveis, como a gente pode ver graficamente aqui nesse diagrama. Nome: João Titulação: Mestre

19 SeRQL - exemplo variáveis que irão aparecer no resultado 1º caminho: Nó do tipo “Professor” SELECT node FROM {node} rdf:type {<sr:Professor>}, {link} sr:source_node {node}; rdf:type {<sr:Trabalha>}; sr:target_node {?} rdf:type {AreaDePesquisa} 2º caminho (I): Elo com origem no nó e do tipo “Trabalha” 2º caminho (II): Elo com destino em um nó X cujo tipo é “AreaDePesquisa” Quando eu escrevo uma consulta em SeRQL, eu estou na verdade descrevendo este padrão, com uma sintaxe que pode até parecer de início com SQL tradicional, mas que é semanticamente bem diferente. O principal da consulta está aqui na cláusula FROM onde eu estabeleço o padrão de subgrafo que eu estou procurando, sempre no formato de triplas do tipo sujeito, predicado objeto. Então, aqui no 1º caminho eu estou descrevendo o padrão node, que é uma incógnita dentro da consulta, type <Professor>, depois no 2º caminho eu descrevo link, uma 2ª incognita, source_node, node, ou seja, um link com origem no nó que eu pedi aqui, e aqui com ponto-e-virgula eu faco um atalho e posso suprimir o {link}, mas estou na verdade procurando {link} type <Trabalha> e finalmente, completando o segundo caminho, eu peço {link} target_node, node, que é um nó parametrizado que eu vou definir na hora de executar a consulta e que este nó seja do tipo “AreaDePesquisa”.

20 Então graficamente, fica assim.
O 1º caminho: nó do tipo professor. A 1ª parte do 2º caminho: Elo com origem no nó e do tipo Trabalha A 2ª parte do 2º caminho: Elo com destino em um nó X, passado como parâmetro, que é do tipo Area de Pesquisa. Essa é na verdade a definição do contexto Professor por Area que a gente viu rodando agora há pouco, onde a área é passada como parâmetro e os valores resultantes são os nós dos professores que trabalham nesta área.

21 SQL? SELECT n.* FROM nodes n, node_links l, nodes n2
WHERE n.all_types LIKE “%Professor%" AND n.id = l.node_id AND l.type = “Trabalha" AND l.target_node_id = n2.id AND n2.all_types LIKE “%AreaDePesquisa%" AND n2.id = ? Inicialmente, eu desenvolvi uma versão do HyperDE usando um banco de dados relacional, porque uma das coisas mais difíceis em termos de implementacao foi implementar o SemanticRecord que faz a persitencia dos objetos no banco RDF. Então, pra garantir e testar todos os outros conceitos do ambiente, eu fiz primeiro usando MySQL mesmo. E por tratar-se de um banco relacional eu tive que me valer de alguns artificios nada intuitivos para obter a inteligencia de orientação a objeto que eu precisava pra fazer o sistema funcionar. E se a gente comparar com a versao em SeRQL, dá pra perceber que SeRQL encaixa perfeitamente com todos os conceitos do SHDM e de orientação a objeto, além de termos os dados persistidos em forma de RDF(s) o que confere a caracteristica de interoperabilidade à informação armazenada. Provavelmente um banco OO também seria uma boa pedida, apesar de que não teria essa vantagem de interoperabilidade.

22 SeRQL – exemplo 2 SELECT subclass FROM {subclass} rdfs:subClassOf
{<sr:Pessoa>} Além disso, um banco relacional tem seus limites. Por exemplo, como SeRQL entende RDF(s) eu posso fazer consultas não só ao modelo, mas também ao metamodelo, como eu mostro aqui. Esta consulta me retorna as sub-classes da classe Pessoa. Eu simplesmente não teria como fazer essa consulta de forma trivial em um banco relacional, porque ele não entende o que é classe, subclasse, etc. Além disso, o Sesame e outros bancos de dados RDF permite que se adicione regras de inferência diretamente no banco de dados, e que permitira ao mecanismo de consulta enriquecer os resultados de uma consulta. Por exemplo, eu poderia colocar a seguinte regra: se um professor trabalha em uma certa area, entao todos os alunos orientados por esse professor tambem trabalham nesta area, e quando eu fizesse a consulta “Alunos Por Area” o mecanismo de consulta iria se utilizar desta regra para formular o resultado, mesmo que alguns alunos não tivessem explicitamente ligados a uma determinada area.

23 Ruby / HyperDE-DSL schwabe = Professor.find_by_nome “Daniel Schwabe”
hipermidia = AreaDePesquisa.find_by_nome “Hipermidia” schwabe.orienta.each do |aluno| unless aluno.trabalha.include?(hipermidia) aluno.trabalha << hipermidia end Ok. Agora vou mostrar aqui um exemplo de utilização da DSL gerada pelo HyperDE pra manipulação da ontologia da aplicação. Este trecho de código faz mais ou menos isso que eu expliquei agora no exemplo da regra de inferência, só que aqui ele está criando os elos explícitos entre o professor e seus alunos. O importante aqui é notar e legibilidade e expressividade da linguagem. Vamos ver... (explicar o código) Lembra da interface de console interativo que eu falei? Vamos tentar rodar o código acima lá.

24 Java/Jena? DAMLModel model = … // code that loads the VCARD ontology
// and some data based on that ontology DAMLClass vcardClass = (DAMLClass) model.getDAMLValue(vcardBaseURI+"#VCARD"); DAMLProperty fnProp = (DAMLProperty) model.getDAMLValue(vcardBaseURI+"#FN"); DAMLProperty Prop = (DAMLProperty) model.getDAMLValue(vcardBaseURI+"# "); Iterator i = vcardClass.getInstances(); while (i.hasNext()) { DAMLInstance vcard = (DAMLInstance) i.next(); Iterator i2 = vcard.accessProperty( Prop).getAll(true); while (i2.hasNext()) { DAMLInstance = (DAMLInstance) i2.next(); if ( .getProperty(RDF.value).getString().equals( ) ) { DAMLDataInstance fullname = (DAMLDataInstance) vcard.accessProperty(fnProp).getDAMLValue(); if ( fullname != null ) System.out.println("Name: "+ fullname.getValue().getString()); } Vou mostrar agora porque uma DSL faz diferença. Este trecho de código escrito em Java utilizando o Jena, que é um framework Java para manipulação de ontologias, está tentando fazer uma coisa bem simples: buscar os cartões de visita modelados na aplicação e procurar em cada cartão um determinado e imprimir o nome completo da pessoa com esse . Como isto é feito na linguagem Java, sem nenhuma facilidade pra manipular a ontologia específica que estamos usando, temos muito trabalho, porque temos que 1º pegar a definição da classe e das propriedades dos nós que estamos buscando e depois com muito custo verificar os valores retornados e imprimir o resultado esperado. Olha como é difícil simplesmente extrair um valor de um nó.

25 Ruby / HyperDE-DSL VCard.find_all.each do |vc|
vc. s.each do | | if .value == and vc.fn? then print vc.fn end Esse mesmo exemplo, usando a DSL gerada pelo HyperDE para esta ontologia ficaria assim: (explicar o código)

26 Ruby / HyperDE-DSL schwabe = Professor.find_by_nome “Daniel Schwabe”
Métodos de persistência: find, find_all, find_by_* create, save, destroy Classes nativas schwabe = Professor.find_by_nome “Daniel Schwabe” hipermidia = AreaDePesquisa.find_by_nome “Hipermidia” schwabe.orienta.each do |aluno| unless aluno.trabalha.include?(hipermidia) aluno.trabalha << hipermidia end Métodos de acesso aos elos Métodos de acesso aos elos Então, o que a DSL está nos fornecendo. 1º, as classes da ontologia se tornam classes nativas da linguagem de programação. Depois, em cima dessas classes, temos a disposição uma séria de métodos para realizar a persistência dos objetos. Especificamente falando de SHDM, a DSL fornece métodos que retornam o resultado de um elo na forma de um Array de objetos. Esse array de objetos tem seu operador de concatenação “<<“ redefinido pra gerar uma tripla RDF no banco de dados persistindo o novo elo. Métodos de atribuição de valor de elos

27 Métodos de verificação de existência de valor em propriedade
Ruby / HyperDE-DSL VCard.find_all.each do |vc| vc. s.each do | | print vc.fn if == and vc.fn? end Além disso, as propriedades dos objetos são acessadas naturalmente através de métodos get/set de leitura e escrita de valores, além de ter essa forma com ponto de interrogação no final, seguindo um idioma do Ruby, e que verifica a existência de valor na propriedade. Ruby também facilita um pouco o nosso trabalho através dos iteradores que ele fornece, sintaxe e métodos, como por exemplo o include? que usamos antes é um método do Array nativo do Ruby. Métodos de acesso de leitura e escrita para os valores das propriedades dos nós Métodos de verificação de existência de valor em propriedade

28 Exemplo: Mini-Orkut Bom pessoal, o que eu quero fazer agora junto com vocês é desenvolver do zero, usando apenas a interface web do ambiente, uma aplicação bem simples, que eu chamei pretensiosamente de Mini-Orkut, cujo o modelo navegacional está aqui e é pequeno o suficiente para que possamos entender todos os detalhes e fazer isso passo-a-passo. Então a gente tem 1 classe chamada Pessoa, que se relaciona com ela mesma através do elo “AmigoDe” e possui alguns atributos como nome, , foto e humor, e um atributos de índice que enumera os amigos dessa pessoa através do elo “AmigoDe”. No esquema de contexto aqui do lado a gente tem 1 landmark apontando para o índice Pessoas. Esse índice permite que a gente navegue nos nós da classe Pessoa de forma alfabética e de lá a gente pode navegar pelas pessoas que são amigas de alguém. Ok, então vamos lá.

29 Desenvolvendo uma aplicação SHDM com HyperDE (I)
Definição de classes navegacionais e elos Então a 1ª coisa a fazer é definir a classe Pessoa e eu faço isso definindo instâncias das metaclasses NavClass, Link e NavAttribute. NavOperation eu vou deixar pra depois. São estas instâncias destas metaclasses que serão usadas para gerar a DSL da classe Pessoa. Vamos fazer.

30 Desenvolvendo uma aplicação SHDM com HyperDE (II)
Definição de contextos navegacionais Ok, agora a gente precisa criar os 2 contextos onde a gente vai navegar pelos nós da classe Pessoa, que são Pessoa por ordem alfabética e Pessoa amiga de Pessoa. Contexto é uma entidade bastante simples no ambiente, feito dos atributos nome e consulta e os parâmetros, se a consulta tiver alguma parâmetro. Vamos lá.

31 Desenvolvendo uma aplicação SHDM com HyperDE (III)
Definição de estruturas de acesso Ok, precisamos agora definir os índices, que serão os pontos de entrada para a navegação na aplicação. Temos 2 índices baseados em contexto, que é o índice Pessoas, baseada no contexto PessoaAlfa, e Amigos, baseada no contexto Amigos. Um índice pode ser enxergado com uma tabela, onde as células são âncoras para contextos ou outros índices, ou apenas texto informativo. Então a gente tem a definição de colunas, que são objetos da classe IndexAttribute. Quando o índice é computado, ele produz as linhas representadas por objetos da classe IndexEntry e cada linha tem células correspondentes a cada coluna do índice que são representadas por objetos da classe IndexEntryAttribute. Vamos criar os nossos índices.

32 Desenvolvendo uma aplicação SHDM com HyperDE (IV)
Definição de Landmarks Ok, precisamos definir agora o ponto inicial da aplicação através da criação de um landmark. Um landmark é como se fosse uma âncora global da aplicação que pode apontar pra um índice ou um nó em um contexto. Vamos criar apenas 1 landmark que vai apontar para o índice Pessoas.

33 Desenvolvendo uma aplicação SHDM com HyperDE (V)
Definiçao de Nós Ok, agora já temos o modelo navegacional da aplicação criado, vamos criar alguns nós para podermos experimentar. Os nós serão instâncias das classes geradas pelo HyperDE baseadas nas metaclasses de classe, atributo e elo que a gente definiu anteriormente. Essas classes e elos são subclasses da metaclasse Node e NodeLink. Vamos colocar alguns nós no sistema então.

34 Desenvolvendo uma aplicação SHDM com HyperDE (VI)
Definição de templates customizados Ok, conseguimos criar rapidamente uma aplicação usando o ambiente, mas navegamos nos nós usando apenas os templates das visões nativas do ambiente. Isso não precisa ser assim. Podemos customizar a aparência com que os nós são apresentados pela aplicação através da definição de visões associadas a contextos e índices. Como a elaboração de um template customizado dá um pouco mais de trabalho, eu vou trazer de volta a aplicação do DI que vimos anteriormente porque ela já tem algumas visões definidas. (Voltar a aplicação do DI e explicar os tipos de visões lá)

35

36 Pessoa por Publicação Professor Alfa por Área Aluno por Professor Publicação por Pessoa Área de Pesquisa Alunos Alunos por Professor Professores Áreas de Pesquisa

37 Template – exemplo <B>Titulacao:</B><br>
<%= attr(“titulacao”) %><BR> <%= attr(“ano_titulacao”) %> - <%= attr(“origem_titulacao”) %><BR><BR> <B>Areas de Atuacao Tecnologica:</B><BR> <TABLE> <% do |template| %> <% template.entry do |entry| %> <TR VALIGN=TOP><TD><IMG SRC='…'></TD> <TD><%= entry.nome.ahref %></TD></TR> <% end %> </TABLE> Explicar o template.

38 Desenvolvendo uma aplicação SHDM com HyperDE (VII)
Definição e execução de Operações <%= op "mudar_nome", { :label => "Alterar Nome", :view => "attributes", :update => "node_attributes", :label_loading => "Aguarde..." }, [ '<input type=button value="%s" onclick="%s">', :label, :onclick ] %> Pra finalizar, vou mostrar algumas operações que eu defini.

39 Trabalhos Relacionados
Toda a série de linguagens, ambientes e frameworks destinados ao suporte dos métodos OOHDM e SHDM OOHDM-Web (1 e 2) e OOHDM-Java (1 e 2) OOHDM-ML, OOHDM-Xweb Lima, 2003; Szundy, 2004; Moura, 2004 Outros Hera, VisualWADE (OOH-Method), ArgoUWE e WebML OOHDM-Web, Java, ML, Xweb,

40 Trabalhos Futuros Melhorias de implementação do HyperDE
Aplicação compilada => Performance Mecanismos de Segurança Suporte a Regras de inferência Extensões ao modelo do ambiente Inclusão de facetas e outras primitivas e recursos do método SHDM que foram deixadas de fora Mapeamento de modelo conceitual/navegacional como em Szundy, 2004. Mapeamento de interfaces abstratas e interfaces concretas como em Moura, 2004. Capacidades de navegação adaptativa Possibilitar o uso de ontologias pré-definidas

41 Contribuições Ambiente de desenvolvimento e framework MVC integrados (de ponta-a-ponta) para prototipação de aplicações OOHDM e SHDM Enriquecimento do SHDM através de modelo para implementação e execução de operações e atributos computados Harmonização de MDA e DSL Geração dinâmica de DSL para manipulação de ontologias Possibilita processo ágil e incremental