Aula destinada a apresentações de trabalhos como meio de avaliação da disciplina. O primeiro apresentar foi o aluno Ernani Gaspar, que falou sobre "Mapping Relational Data Base Structure to RDF Records". A ideia apresentada pelo aluno foi de arquiteturas para desenvolvimento de sistemas de informação e interoperabilidade. Apresentação teve como objetivo apresentar trabalhos relacionados a mapeamento de base dados para estrutura RDF. No fim concluiu que além da comunidade ter feita bastante pesquisas, poucas coisas foram concluídas e porém ainda tem muitas coisas a serem feitas.
O segundo grupo a apresentar foi o grupo da Maria das Graças, Cristine e Raquel. O grupo abordou uma reengenharia de uma ontologia que foi desenvolvida antes da existência de UFO. Além de refazê-la, o grupo fez uma análise ontológica e diversas simulações.
sexta-feira, 30 de agosto de 2013
terça-feira, 27 de agosto de 2013
UFO-A, UFO-B e UFO-C
Nesta aula tivemos a presença do ilustre professor Geancarlo, falando sobre Unified Foundational Ontology(UFO). A UFO é uma ontologia de fundamentação baseadas em várias teorias de Ontologia Formal, Lógica filosófica, Filosofia da Linguagem, Linguística e Psicologia Cognitiva[1]. Desenvolvida com o objetivo de fornecer uma fundamentação ontológicas para modelos conceituais. Ou seja, unifica as ontologias(DOLCE/OntoClean e GFO/GOL) existentes, afim de sanar as limitações detectadas e aproveitando as suas principais característica.
Como podemos observar na figura 1. a UFO é dividida em três partes ou camadas, seja elas, UFO-A, UFO-B e UFO-C. A UFO-A trata da parte de uma ontologia de endurantes, entende-se por endurantes, todo objeto que persiste no tempo durante a sua vida. Exemplo mais comum é a de pessoa, uma vez pessoa, ela é pessoa até a sua morte. Ou seja, nunca poderá deixar de ser pessoa quando a sua existência. Já a UFO-B trata a parte de uma ontologia de perdurantes(eventos), entende-se por perdurantes, todos os elementos que são compostos por partes temporais ou que ocorre no tempo. Um exemplo mais comum é quando acontece um processo contra uma determinada empresa, esse processo só vai existir enquanto tiver ocorrendo uma ação judicial contra essa empresa . E por fim a UFO-C trata de uma ontologia de entidades sociais. Ou seja, é baseado em conceitos de objetos físicos e momentos individuais de UFO-A e conceitos específicos de eventos de UFO-B[2].
Figura 1. Representação UFO.
UFO-A
Existe duas distinção de individuo em UFO-A, são elas os endurants e perdunrants, ou seja, podemos dar como exemplo a distinção entre objeto e processo respectivamente. Um endurants não tem partes temporais, e persiste no tempo mantendo a sua identidade. Já o perdurant é constituído por partes temporais, como exemplo, um processo de negócio[2];
Figura 2. Partes de UFO-A
A figura 2, mostra um trecho da UFO-A, onde um individual é uma especialização de pendurant e endurant. E um endurant é uma especialização de substance individual e moment individual. Onde um substance individual possui propriedades de espaços temporais diretos, ou seja, ele existe por si só sem depender de alguém. Ao contrário de moment individual, que não pode existir por si só, ou seja, ele é dependente de outro individuo para existir. Exemplo é a idade de uma pessoa ou matricula em um curso de mestrado, só vai existir a idade de uma pessoa se a mesma existir e só vai existir uma matricula no curso de mestrado e o curso existir.
Um moment individual pode ser tanto um relator ou Intrinsic moment, sendo que um relator é um individuo utilizado para ligar ou mediar duas ou mais entidades. Já a entidade substance individual especializa de amount of matter e physical object, sendo que physical object satisfaz a condição de unidade, onde permite que tenha uma mudança sem que afete a sua identidade. Ao contrário onde a amount of matter não satisfaz a condição de unidade[2].
UFO-B
Em UFO-B o conceito de pendurant é especializado de estado e eventos. Sendo que um estado é um perdurant cuja as suas partes temporais pertence ao mesmo tipo de estado como um todo. Diferente de eventos que esta relacionado com dois estado, sendo eles o estado de post-state e pre-state, conforme mostrado na figura 3. E por fim os eventos são especializados em eventos atômicos e eventos complexos.
Figura 3. Partes de UFO-B
UFO-C
UFO-C é baseado em conceitos de objetos físicos e momentos individuais em UFO-A e eventos em UFO-B[2]. A figura 4 representa a versão UFO-C.
Figura 4. Representação de UFO-C
Na figura 4 mostra que um objeto físico é especializado em um agente físico e um objeto não-agente. Sendo que um agente físico é um objeto que cria eventos de ação a qual podemos atribuir um estado mental. Já um objeto não-agente é considerado um recurso, ou seja, é algo que pode ser utilizado por um agente físico com finalidades específicas.
Para mais informações sobre UFO-A, UFO-B e UFO-C pode ser encontrada em [2] e [3].
Referencia
[1] - Veruska Zamborlini. Estudo de Alternativas de Mapeamento de Ontologias da Linguagem OntoUML para OWL: Abordagens para Representação de Informação Temporal. 2011. http://nemo.inf.ufes.br/pt-br/gguizzardi/supervisao/mestrado
[2] - GUIZZARDI, Renata Silva Souza. Agent-oriented Constructivist Knowledge Management. 1 ed. 2006. v. 1. 320p , - http://nemo.inf.ufes.br/en/rguizzardi/publications
segunda-feira, 26 de agosto de 2013
ARKnowD: Agent-Oriented Recipe for Knowledge Management Systems Development.
A professora Renata começou falando sobre a sua tese de doutorado que tem como objetivo criar uma metodologia ARKnowD. Essa metodologia é a integração de tropos + AORML através de UFO(Ontologia de Fundamentação Unificada), conforme mostrado na figura 1.
ARKnowD é uma metodologia orientada a agente para desenvolvimento de sistemas de gestão de conhecimento. O ARKnowD tem uma forte ênfase nas fases iniciais de desenvolvimento de software, apoiando o analista na compreensão do ambiente organizacional antes de realmente iniciar o desenvolvimento de um sistema.
Para isso foi utilizou conceito de dependência e delegação. Na tabela abaixo mostra o mapeamento dos conceitos utilizando tanto em tropos como AORML. Através de UFO foi possível identificar conceitos comuns entres as duas metodologias.
Para validar a nova proposta, foi mostrado um cenário organizacional além de falar sobre os passos utilizados para fazer o mapeamento. Tudo começou pelo diagrama de dependência estratégica, através de criação de tabela, sendo possível criar o diagrama de agentes. Depois foi feita uma analise do diagrama de razão estratégica para cada ator.
ARKnowD é uma metodologia orientada a agente para desenvolvimento de sistemas de gestão de conhecimento. O ARKnowD tem uma forte ênfase nas fases iniciais de desenvolvimento de software, apoiando o analista na compreensão do ambiente organizacional antes de realmente iniciar o desenvolvimento de um sistema.
Figura 1. Utilizando UFO para mapear conceito de tropos e AORML
Para isso foi utilizou conceito de dependência e delegação. Na tabela abaixo mostra o mapeamento dos conceitos utilizando tanto em tropos como AORML. Através de UFO foi possível identificar conceitos comuns entres as duas metodologias.
Tabela 1. Mapeamento entre tropos e AORML.
Para validar a nova proposta, foi mostrado um cenário organizacional além de falar sobre os passos utilizados para fazer o mapeamento. Tudo começou pelo diagrama de dependência estratégica, através de criação de tabela, sendo possível criar o diagrama de agentes. Depois foi feita uma analise do diagrama de razão estratégica para cada ator.
Ontologia Foundation for The i* Framework - Continuação.
Análise de link de dependência Vs Link de delegação.
Existe dois tipos de links, a de dependência e delegação. Sendo que o primeiro link de dependência, caracteriza por ter uma figura de depender, dependum e dependee. Ou seja, existe uma figura daquele que depende de alguém(depender) e aquilo que se depende(dependum) daquele de quem se depende(dependee). Já o link de delegação, existe a figura do delegator que delega alguma coisa para uma pessoa e delegatum aquilo que se delega, ou seja, pedir alguém para revisar um artigo ou capítulo. E delegatte aquele que se delega, como o coordenador pedir para um professor aplicar uma prova para outro professor.
1. Na parte superior da figura, temos uma dependência real entre coordenador e pesquisador
2. Já na parte inferior da figura, temos uma delegação, porque o member assume uma responsabilidade de cumprir a dependência.
Fixação de incompletude em Tropos
Existe dois tipos de links, a de dependência e delegação. Sendo que o primeiro link de dependência, caracteriza por ter uma figura de depender, dependum e dependee. Ou seja, existe uma figura daquele que depende de alguém(depender) e aquilo que se depende(dependum) daquele de quem se depende(dependee). Já o link de delegação, existe a figura do delegator que delega alguma coisa para uma pessoa e delegatum aquilo que se delega, ou seja, pedir alguém para revisar um artigo ou capítulo. E delegatte aquele que se delega, como o coordenador pedir para um professor aplicar uma prova para outro professor.
Figura 1. Análise de Links dependência
2. Já na parte inferior da figura, temos uma delegação, porque o member assume uma responsabilidade de cumprir a dependência.
Fixação de incompletude em Tropos
Ontologia Foundation for The i* Framework
A ontologia de fundamentação tem como propósito buscar uma estrutura conceitual compartilhada, com o objetivo de melhorar a comunicação entre os especialista, diminuir a curva de aprendizado para os novatos e promover a adoção por profissionais.
Abordagens existentes:
Essas três abordagens são consideradas sintaxe orientada enquanto as abordagens Ontoistar e Our work, são baseadas em ontologias. São abordagens que suportam integração de modelos i* baseados em ontologia.
Exemplos
Posição
Não se proíbe nenhuma combinação entre a raiz e o objetivo na medida que têm um significado ontológico.
O que esta procurando desenvolver:
Or-Decomposicao Vs Means-End
OBS:. O link Means-End é aplicado somente entre task-goal, resource-goal e resource-task.
Referencia
[1] i* Wiki istarwiki.org- http://istar.rwth-aachen.de/tiki-index.php?page=i%2A+Guides&structure=i%2A+Wiki+Home
[2] Metamodeling - http://en.wikipedia.org/wiki/Metamodeling
[3] iStarMl The i* Mark-up Language - http://www.upc.edu/gessi/istarml/
[4] iStarML - http://istar.rwth-aachen.de/tiki-index.php?page=IStarML
Abordagens existentes:
- i* wiki - Seção de diretrizes: Hoje em dia existem dois tipos de guias disponíveis, o guia rápido, onde o usuário encontrará um glossário das principais construções i*. E o segundo o guia i* que estende o guia rápido que inclui diretrizes i* com discussões e ilustrações elaboradas[1].
- Works em metamodeling: É a análise, construção e desenvolvimento das estruturas, regras, modelos e teorias aplicadas para a modelagem de uma classe pré-definida de problemas[2]. Ou seja, é a construçãso de um conjunto de conceitos dentro de um determinado domínio.
- iStarML: É um formato compatível com XML para representar diagramas i*. Tendo como objetivo um formato comum, onde o framework conceitual comum das principais variações da linguagem i* é explicitada[3]. Ou seja, fornecer um formato de intercâmbio para interoperabilidade de modelos entre as variantes i*[4].
Essas três abordagens são consideradas sintaxe orientada enquanto as abordagens Ontoistar e Our work, são baseadas em ontologias. São abordagens que suportam integração de modelos i* baseados em ontologia.
Exemplos
Exemplo de Guideline i* wiki
Figura 1. Modelo em i*
Exemplo Metamodelagem
Figura 2. Modeling
Com o uso da ontologia podemos explicitar os compromissos ontológicos da linguagem de modelagem, podemos definir semânticas do mundo real para os conceitos subjacentes da linguagens e fornecer diretrizes para o suso consistente destes conceitos.
Posição
Não se proíbe nenhuma combinação entre a raiz e o objetivo na medida que têm um significado ontológico.
O que esta procurando desenvolver:
- Definição lógica entre as relações;
- Quais propriedades ontológicas que passa satisfazer;
- Recordar o significado de decomposição.
Or-Decomposicao Vs Means-End
Figura 3. Tabela de quando utilizar Means-End
OBS:. O link Means-End é aplicado somente entre task-goal, resource-goal e resource-task.
Referencia
[1] i* Wiki istarwiki.org- http://istar.rwth-aachen.de/tiki-index.php?page=i%2A+Guides&structure=i%2A+Wiki+Home
[2] Metamodeling - http://en.wikipedia.org/wiki/Metamodeling
[3] iStarMl The i* Mark-up Language - http://www.upc.edu/gessi/istarml/
[4] iStarML - http://istar.rwth-aachen.de/tiki-index.php?page=IStarML
sexta-feira, 23 de agosto de 2013
Palestra sobre Design Science Research in Information Systems and Software Engineering
Neste dia a turma foi liberada para assistir a palestra ministrada pelo professor Dr. Roel Wieringa da University of Twente the Netherlands. A palestra teve como tema "Design Science Research in Information System and Software Engineering".
Nos últimos dez anos tem visto uma onda de interesse em pesquisa científica de design em sistemas de informação e de pesquisa empírica em engenharia de software. Nesta palestra foi apresentado um framework para a ciência de design da informação e engenharia de sistemas de software que mostra como a pesquisa científica design, que iterar sobre concepção de novos artefatos, e empiricamente investigar estes artefatos.
A lógica de ambas as atividades, design e pesquisa empírica, é o da tomada de decisão racional. Onde foi mostrada como essa lógica pode ser usada para estruturar nossas questões de pesquisa, bem como a forma de estruturar os relatórios sobre a nossa pesquisa.
Também foi mostrado uma lista de verificação para a concepção de pesquisa empírica e foi dado alguns exemplos de uso da lista de verificação.
E por fim, foi discutido em detalhe, qual é o papel das teorias na investigação científica de design, e como podemos usar a teoria para questões de pesquisa estaduais e interpretar os resultados da investigação.
Nos últimos dez anos tem visto uma onda de interesse em pesquisa científica de design em sistemas de informação e de pesquisa empírica em engenharia de software. Nesta palestra foi apresentado um framework para a ciência de design da informação e engenharia de sistemas de software que mostra como a pesquisa científica design, que iterar sobre concepção de novos artefatos, e empiricamente investigar estes artefatos.
A lógica de ambas as atividades, design e pesquisa empírica, é o da tomada de decisão racional. Onde foi mostrada como essa lógica pode ser usada para estruturar nossas questões de pesquisa, bem como a forma de estruturar os relatórios sobre a nossa pesquisa.
Também foi mostrado uma lista de verificação para a concepção de pesquisa empírica e foi dado alguns exemplos de uso da lista de verificação.
E por fim, foi discutido em detalhe, qual é o papel das teorias na investigação científica de design, e como podemos usar a teoria para questões de pesquisa estaduais e interpretar os resultados da investigação.
Aplicação de Ontologias em Engenharia de Software - Integração de Ferramentas no Contexto de Gerência de Projetos
Nesta aula contamos com a presença da aluna Gleice Kelly ministrando uma palestra sobre o seu trabalho de Tcc que teve como foco a "Integração de Ferramentas no Contexto de Gerência de projetos".
A gerencia de projetos é um processo complexo que envolve várias atividades envolvendo um número grande de informações. Por tanto existem várias ferramentas que tem como soluções parciais para esse processo. Por isso que tem a necessidade que essas ferramentas trabalhem em conjunto de forma eficiente, integrado, compartilhando dados no apoio ao processo de gerência de projetos.
O seu trabalho apresenta uma iniciativa de integração da ferramenta dotProject ao ambiente ODE, considerando o domínio da gerência de projetos, no que se refere as atividades de definição de atividades do projeto, alocação de pessoas e essas atividades e elaboração de cronogramas.
O seu trabalho foi realizado seguindo a OBA-SI (Ontology-Based Approach for Semantic Integration), uma abordagem baseada em ontologias para integração semântica de aplicações. Tal abordagem promove acordo semântico entre os sistemas no nível conceitual.
A gerencia de projetos é um processo complexo que envolve várias atividades envolvendo um número grande de informações. Por tanto existem várias ferramentas que tem como soluções parciais para esse processo. Por isso que tem a necessidade que essas ferramentas trabalhem em conjunto de forma eficiente, integrado, compartilhando dados no apoio ao processo de gerência de projetos.
O seu trabalho apresenta uma iniciativa de integração da ferramenta dotProject ao ambiente ODE, considerando o domínio da gerência de projetos, no que se refere as atividades de definição de atividades do projeto, alocação de pessoas e essas atividades e elaboração de cronogramas.
O seu trabalho foi realizado seguindo a OBA-SI (Ontology-Based Approach for Semantic Integration), uma abordagem baseada em ontologias para integração semântica de aplicações. Tal abordagem promove acordo semântico entre os sistemas no nível conceitual.
Conceitos de I*
O framework i* é uma linguagem de modelagem de sistema, que tem como objetivo compreender o problema de um determinado domínio. É uma abordagem desenvolvida para modelar raciocínio sobre ambientes organizacionais e seus sistemas de informação.
Entidades:
O framework i* possui quatro entidades, são elas:
Relações:
O framework i* tem as seguintes relações:
O modelo de dependência estratégica tem como finalidade modelar as dependência entre atores de uma organização. Ou seja, um ator depende de outro para chegar ao seu objetivo. O modelo é utilizado para representar as relações intencionais, estratégicas entre os atores.
Modelo de razão estratégica
O modelo de razão estratégica tem como finalidade modelar uma perspectiva de um ator em especial. Ou seja, fornece uma estrutura de representação para expressar as razões por trás das dependências. diferentemente do modelo de dependência estratégica que captura as motivações, desejos, preocupação, planos e recursos.
Representação gráficas de outros elementos.
ou 
Figura 5. Softgoal Figura 6. Crença
Figura 7. Dependência Figura 8. Meio-Fim Figura 9. Decomposição
Figura 10. Contribuição
Fonte:.http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide
OBS: Os sentidos da seta indica a leitura da dependência
Construct Overload
Acontece quando uma construção de linguagem única representa dois ou mais construções ontológicas prejudicando a clareza e o entendimento do modelo. Ou seja tem dois significados diferentes. a figura 11 esse conceito. Conforme[2] a construct overload é uma propriedade indesejavél da linguagem de modelagem, uma vez que apresenta ambiguidade e prejudica a clareza.
Referências:
[1] http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide
[2] GUIZZARDI, Renata; FRANCH, Xavier; GUIZZARDI, Giancarlo. Applying a Foundational Ontology to Analyze Means-End Links in the i* Framework. In Anais da 6th International Conference on Research Challenges in Information Science, Valencia, Spain. 2012
Entidades:
O framework i* possui quatro entidades, são elas:
- Ator - Entidades ativas que realiza ações para atingir os objetivos, exercendo o seu conhecimento. Utiliza-se o termo ator para se referir genericamente a qualquer unidade para a qual dependências intencionais pode ser atribuída. O ator é representado conforme figura abaixo:
Figura 1. Ator
2. Objetivo - Representa o desejo intencional de um ator. Sendo que os detalhes de como o objetivo será alcançado, não é descrito pelo objetivo, e sim por meio de decomposição de tarefas. O objetivo é representado conforme figura abaixo:
Figura 2. Objetivo
3. Tarefa - É a maneira de como o ator vai atingir o seu objetivo. A descrição das especificidade da tarefa pode ser descrito pela decomposição de tarefas em mais sub-tarefas, ou seja, um conjunto de tarefas a serem realizadas para alcançar um objetivo, ou uma tarefa específica a ser realizada. A tarefas é representada conforme a figura abaixo:
Figura 3. Tarefa
4. Recurso - É um objetivo físico, ou recurso de informação para alcançar o objetivo. O recurso é representado conforme a figura abaixo:
Figura 4. Recurso
Relações:
O framework i* tem as seguintes relações:
- Dependência - É utilizado para modelar dependência sobre os atores.
- Decomposição - É utilizado para redefinir os objetivos, ou seja, sempre que tenha uma decomposição, uma tarefa é ligada a seus nós por ligações de decomposição. Uma tarefa pode ser decomposta em quatro tipos, são elas:
- subgoal;
- subtask;
- resource;
- softgoal;
- Meio-Fim - É utilizado para relacionar tarefa com objetivo, ou seja, é uma relação entre um fim, e um meio para alcançar um objetivo. Os meios é expresso na forma de uma tarefa e o fim é expresso como um objetivo e na representação gráfica a seta aponta a partir do meio para o fim.
- Contribuição - É utilizado como uma relação para contribuir com a finalidade de chegar ou atingir o seu objetivo. A relação de contribuição é dividida em, Make, Some+, Help, Unknown, Break, Some-, Hurt, Or e And.
O modelo de dependência estratégica tem como finalidade modelar as dependência entre atores de uma organização. Ou seja, um ator depende de outro para chegar ao seu objetivo. O modelo é utilizado para representar as relações intencionais, estratégicas entre os atores.
Modelo de razão estratégica
O modelo de razão estratégica tem como finalidade modelar uma perspectiva de um ator em especial. Ou seja, fornece uma estrutura de representação para expressar as razões por trás das dependências. diferentemente do modelo de dependência estratégica que captura as motivações, desejos, preocupação, planos e recursos.
Representação gráficas de outros elementos.
ou Figura 5. Softgoal Figura 6. Crença
Figura 7. Dependência Figura 8. Meio-Fim Figura 9. Decomposição
Figura 10. Contribuição
Fonte:.http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide
OBS: Os sentidos da seta indica a leitura da dependência
Construct Overload
Acontece quando uma construção de linguagem única representa dois ou mais construções ontológicas prejudicando a clareza e o entendimento do modelo. Ou seja tem dois significados diferentes. a figura 11 esse conceito. Conforme[2] a construct overload é uma propriedade indesejavél da linguagem de modelagem, uma vez que apresenta ambiguidade e prejudica a clareza.
Figura 11. Construct Overload
Construct Redundancy
Acontece quando uma construção da linguagem tem dois significados para um conceito. Ou seja, uma linguagem deve ter apenas uma construção para representar fenômeno no domínio. Para [2] a mesma entidade conceitual sendo representado por dois ou mais construtores, adicionaria confusão ao significado do modelo. A figura 12 representa esse conceito.
Figura 12. Construct Redundancy
Referências:
[1] http://istar.rwth-aachen.de/tiki-index.php?page=iStarQuickGuide
[2] GUIZZARDI, Renata; FRANCH, Xavier; GUIZZARDI, Giancarlo. Applying a Foundational Ontology to Analyze Means-End Links in the i* Framework. In Anais da 6th International Conference on Research Challenges in Information Science, Valencia, Spain. 2012
Assinar:
Postagens (Atom)