Aula em que Glaice apresentou o trabalho realizado em seu TCC

Glaice apresentou o seu trabalho, que foi uma iniciativa de integração entre ferramentas do domínio de Gerência de Projetos - AlocaODE e dotProject - e abrangeu a definição de atividades do projeto, a alocação de pessoas a essas atividades e a elaboração de cronogramas.

Utilizou-se OBA-SI (Ontology-Based Approach for Semantic Integration), uma abordagem baseada em ontologia em que a integração semântica é realizada em um alto nível de abstração, possibilitando acordo semântico entre os sistemas no nível conceitual.

Aula do dia 09/09/2013

A primeira apresentação do dia foi feita por Fabiano que abordou a construção de ontologias utilizando uma linguagem de padrões ontológicos (SE-OPL).  A OPL é replicada (como um template) e não especializada para a construção da nova ontologia. Entre as vantagens da utilização dessa abordagem estão o reuso de estrutura e das de regras.

Victor e Cássio apresentaram uma transformação automatizada de OntoUML para OWL (linguagem para ontologias voltada para Web). O metamodelo OWL é mais sintético que o de UFO. Então uma transformação de UFO para OWL representa perda de informação e no sentido inverso não é possível de ser feita. Por ser mais sintético, quando é construída uma ontologia diretamente em OWL várias informações podem passar despercebidas.

Entre as vantagens estão o tempo para a construção, a possibilidade de abstrair OWL e a diminuição de erros. A desvantagem é a perda de expressividade ocorrida.

John tratou de uma transformação entre Temporal OCL para Alloy. Ele já tem feitos transformações de OCL para Alloy e agora visa abordar também o aspecto temporal. Para isso algumas ações serão necessárias como a restrição entre transições de phases e roles, por exemplo.

Diobert planejou um Sistema de Comparação de Preços Baseado em Ontologia. O serviço seria similar ao Buscapé e BondFaro. O desafio é transformar informações não estruturadas em informações baseadas em ontologias. A arquitetura do sistema apresenta um Gatherer (Nutch e Apacha Tomcat como WebCrawler) e um Triplificador.

[Aula 26/08] Primeira e segunda apresentações de seminários

No dia 26 tivemos duas apresentação de ontologia aplicada a engenharia de software. A primeira apresentação foi a respeito de um survey na área de mapeamentos entre banco de dados em triplas e banco de dados relacionais. A segunda, apresentou uma reengenharia de ontologia no domínio de organizações públicas.
A primeira apresentação traz um histórico de como a internet era um "web of documents" e hoje está evoluindo para "Web of data". Neste cenário o uso de bancos de dados em RDF se faz mais útil. Este trabalho foca na transformação de dados em formato relacional (RDB) para formato de triplas(RDF). O estudo foca em duas principais características. Uma é quanto a automaticidade da transformação onde automático seria transformação 1 para 1, a semi-automática baseia-se em um modelo de transformação intermediário, e neste momento a ontologia toma seu espaço e por fim, a transformação manual, podendo também ser baseada em ontologias. A outra característica é em relação à estática ou dinâmica, onde a primeira enquadra na transformação a nivel de dado, normalmente utilizando o ETL (Extract, tranform, load), enquanto a segunda - dinâmica - faz o uso da transformação da query, de SPARQL para SQL.
A segunda apresentação relatou os esforços aplicados na transformação de uma ontologia no domínio de organizações públicas, escrita em axiomas e relacionamentos, em uma ontologia escrita em OntoUML. Nesta apresentação, as autoras relataram que com o uso da linguagem OntoUML foi possível descobrir vários furos na ontologia prévia e fez-se a necessidade de tomar decisões de modelagem que não estavam incluídas na ontologia anterior.
Em resumo, as duas apresentações tiveram usos diferentes da ontologia na área de engenharia de software. A primeira analisou transformações de formatos de dados, com o uso da ontologia como uma mantedora de semântica durante este processo, enquanto a segunda apresentação fez uma reengenharia com a finalidade de transformar uma representação de domínio de um linguagem para outra, mantendo-se ou até melhorando, sua semântica.

Technical Action Research (TAR) – Roel Wieringa - 08/07

Technical Action Research (TAR) – Roel Wieringa

TAR é a validação de um artefato pela sua aplicação em um caso real.

Em TAR os papéis de um pesquisador (designer, helper e researcher) devem ser mantidos separados.

Em classical action research o pesquisador ajuda o cliente a identificar e resolver um problema. Já em TAR, o pesquisador deseja aprender sobre uma técnica através de sua utilização na solução de problemas. Assim, TAR é orientada a tecnologia e não a problema, pois uma tecnologia pode solucionar uma classe de problemas e não um problema específico.

TAR é importante para o pesquisador levar uma técnica “da sua mesa” para a prática. Para o cliente isso representa maior probabilidade de obter resultados úteis e avanço do conhecimento sobre novas técnicas.

AR clássica é orientada a problema.

1. É observado um problema com o cliente;
2. Conjuntamente uma ação é decidida;
3. A ação é então executada;
4. Os resultados são avaliados; e
5. As lições aprendidas são aplicadas no caso específico e em outros.

Princípios de canonical action research aplicados em TAR:

1. Para cada ciclo do cliente, TAR requere um acordo entre cliente-pesquisador;
2. TAR é iterativo;
3. TAR deve ser baseado em teoria;
4. TAR implementa mudança através de ação; e
5. TAR contém aprendizado pela reflexão sobre uma ação.

Por fim, foi abordada a generalização necessária para identificação de arquiteturas e mecanismos. Para isso, é necessário apoio em lógica e em teorias pré-estabelecidas.

Aula 12/08/2013

Para realizar uma análise organizacional pode-se utilizar Tropos. Porém, Tropos é limitada à análise de requisitos e projeto de arquitetura. 

Por outro lado, a linguagem AORML é utilizada para produção de projeto detalhado. Por isso, as duas linguagens foram combinadas. Ou seja, a partir do projeto arquitetural, em Tropos, é feito um mapeamento para gerar o projeto detalhado, em AORML.

A transformação realizada foi inspirada no Desenvolvimento Orientado a Modelos (Model Driven Development - MDD). MDD apresenta 03 (três) viewpoints, que são Computation Independent Model (CIM), Platform Independent Model (PIM) e Platfomr Specific Model (PSM). 

Esse mapeamento foi feito também utilizando-se ontologia, mas especificamente UFO. Sem o uso da ontologia para fazer a análise dos conceitos da linguagem, o mapeamento não seria possível.

Aula dia 29/07/2013

Na aula do dia 29/07/2013 continuou-se a tratar de Ontological Foundation em i* Framework.

A relação de dependência foi discutida. Essa relação pode ser dividida em dependência e delegação. A delegação especifica uma relação material. De modo diferente a dependência é definida por uma relação formal.

Como conclusão do trabalho apresentado temos que proporcionar um fundamento ontológico para i* é o caminho para esclarecer o significado das construções da linguagem. 

O entendimento do significado das construções e dos diagramas possíveis contribui para maior objetividade da linguagem, pois impedem a ocorrência de falhas como construct overload, redundancy, excess e incompleteness. Como comentado em aula, algumas construções da linguagem permitem modelagem e leituras diferentes (subjetividade) de um mesmo diagrama, de acordo com o contexto em que é feita aquela representação, o que não é aconselhável em uma linguagem de diagramação.

No fim da aula analisamos diagramas procurando identificar eventuais inconsistências e o que estava certo em cada um deles.

Aula 22/07/2013

A linguagem de modelagem de objetivos denominada i* vem abrindo um leque de novas tecnologias e usos com grande utilidade, entre outras áreas, no levantamento de requisitos. Durante a aula de Ontologias aplicadas a Engenharia de software foram apresentados alguns trabalhos relacionados com a linguagem i*, como exemplo o i* wiki, que consiste em um ambiente de colaboração com o tema i*, apresentando novas ferramentas, tutoriais e FAQs. Outros trabalho conhecidos são, workson approach, um metamodelo da linguagem e iStarML, uma estrutura baseada em XML utilizado para prover interoperabilidade entre as ferramentas baseadas em i*.

Existem também dois trabalhos de representação de i* utilizando ontologias. O Ontoistart é uma representação em OWL  da linguagem, o qual seu foco é disponibilizar um metamodelo e manter uma referência, ou entendimento, compartilhado. No entanto o laboratório Nemo tem aplicado esforços para desenvolver uma ontologia que reflita o i*, conhecida como Onto i*. Este trabalho tem reunido esforços para justificar conceitos e relações da linguagem i* através da ontologia (UFO-C), relacionando um conceito na UFO com um conceito no i*. Alguns conceitos são evidentes como intenção, proposição e agentes.              O resultado deste trabalho, facilita a interoperabilidade entre linguagens baseadas no i*  (entre outros beneficios).

Na aula do dia 22/07/2013 foi apresentada o trabalho desenvolvido (Onto i*). Discutiu-se a semântica de conceitos do i* como MAKE, BREAK, HELP e HURT, a diferença ontológica entre means-end e MAKE, entre outros. Também durante a aula foram naturalmente levantados, algumas discussões a respeito. Entre as discussões, foram questionados a individualidade de objetivo que exerce o papel de um subobjetivo, ou seja, foi levantada a importância, ou relevância de se falar de um objetivo individualmente, quando ele foi identificado como subobjetivo de um outro objetivo maior?

NOTAS DE AULA - 01/07/2013

Nesta aula foi abordada a linguagem i*. Ela é útil na Engenharia de Requisitos e em Análise Organizacional, por exemplo. Existem extensões da linguagem que podem ser utilizadas em contextos variados. Seguem características da linguagem.

Entidades:

• ator;
• objetivo (hard goal e soft goal);
• tarefa; e
• recurso.

Relações:

• dependência;
• decomposição;
• meio-fim; e
• contribuição.

Diagramas:

• dependência estratégica; e
• razão estratégica.

Coincidentemente, um dos componentes do grupo leu há alguns dias o artigo de KIYAVITSKAYA e ZANNONE (2008). Nesse artigo, os autores apresentam a aplicação de métodos para a transformação de especificação de requisitos, escritos em linguagem natural, em especificações semi-estruturadas. A metodologia Secure Tropos é utilizada nesse artigo. Ela adota a linguagem SI*, que uma extensão do i* para modelar requisitos de segurança.

Referência:

KIYAVITSKAYA, N.; ZANNONE, N. Requirements model generation to support requirements elicitation: the Secure Tropos experience. Automated Software Engineering 15 (2): 149-173 p. 2008.

AULA 3 - UFO-C - 24/06/2013

Foi abordada a UFO-C, que é uma ontologia de entidades sociais e que sistematiza conceitos sociais, tais como plano, ação, intencionalidade. Os pontos de destacados na aula são comentados a seguir.

Na UFO-C são diferenciados substanciais agentivos (Agents) dos não agentivos (Object). Um Agent pode representar por exemplo um Kind ou um Role.

Já um Mental Moment, que é um Intentional Moment, pode ser dividido em Belief, Desire ou Intention (Internal Commitment). Não há ação associada há um desejo, por exemplo: quero que faça sol no fim de semana. Enquanto em uma Intenção (Compromisso Interno) há sim uma ação associada para que isso aconteça. Ex: Quero entender UFO-C. Além do Internal Commitment, UFO-C também modela Social Commitment, que representa um compromisso com outra entidade.

Ações são eventos intencionais, i. e., apresentam o propósito específico de satisfazer alguma intenção.

Na ontologia é feita a diferenciação entre closed commitment, que apresenta passo a passo para sua realização e é descrito por um plano, e openned commitment, o qual não está relacionado a esse passo a passo.

Também foi dito que Appointment Goal tem o objetivo relacionaodo a um intervalo de tempo e Scheduled Actions são closed appointments.

Além disso, também foram abordados problemas que podem ocorrer no mapeamento entre um metamodelo da linguagem e uma ontologia de referência, como por exemplo: construct overload e construct redundancy.

Aula 2 - UFO

O estudo da Ontologia no laboratório Nemo deu inicio com a idéia de Falbo de descrever processos de Software utilizando uma ontologia para desenvolver um meta ambiente. Seguindo esta idéia, Falbo deu inicio ao desenvolvimento de ODE (Ontology-based Development Environment). Este meta ambiente, baseia-se em ontologias a respeito de domínios relativos processo de software a fim de se tornar um ambiente fácilmente integrável.
Durante o uso constante de ontologias, e o progresso do estudo na área, percebeu-se a importância de utilizar ontologias de fundamentação. Nesta forma de desenvolver ontologias de domínio, é utilizado conceitos (ontologias) mais detalhadas que descrevem elementos básicos do mundo e enriquecem semânticamente a ontologia de domínio.
Mais adiante, desenvolveu-se ontologias que não eram nem genéricas a ponto de serem de fundamentação e nem específicas para serem de domínio. A estas foram atribuídas o nome de Core Ontologies. Este tipo de ontologia possibilitou o desenvolvimento de linguagens de padões a fim de guiar a construção de ontologias de domínio a partir de core ontologies.
Por exemplo, a Ontologia de Apoio à Gerência de Projetos (AGPR) foi criada por meio da composição de alguns dos padrões da Linguagem de Padrões de Ontologia para Processos de Software (Software Process Ontology Pattern Language – SP-OPL). Esta é uma linguagem de padrões de ontologia para o domínio de aplicação de processos de software. As principais áreas abordadas pela SP-OPL são Definição de Processo Padrão de Software, Definição e Programação do Processo de Projeto, Alocação de Recursos e Execução do Processo de Software. A ontologia AGPR aborda o processo de gerência de projetos de software no que se refere à definição de atividades do projeto, alocação de pessoas a essas atividades e elaboração de cronogramas.

Postagem Aula 1 - Desafios da Interoperabilidade Semântica

Durante a aula, observamos a importância de haver um consenso entre os modelos conceituais existentes na mente de cada pessoa, sobre um mesmo domínio, para que houvesse uma boa comunição. Da mesma forma, isso é observado para softwares. Esse assunto pode ser relacionado ao TCC da Glaice, no qual foi necessário mapear os conceitos dos modelos de ODE e de dotProject com o objetivo de integrar essas ferramentas num contexto de gerência de projetos, no que se referia à alocação de recursos humanos, controle de atividades e geração de cronogramas. Nesse TCC, o conceito de Projeto foi mapeado diretamente, porém alguns conceitos necessitaram de certas restrições para serem mapeados. Por exemplo, em dotProject, havia usuários e contatos. Foi necessário analisar o real papel de cada um no software, para que pudesse finalmente poder dizer que um Contato, em dotProject, se referia a um Recurso Humano, em ODE. Um outro exemplo é o caso de Atividade, em ODE, que só é uma Tarefa, em doProject, se ela tiver datas de início e fim previstas definidas no sistema.

A questão da interoperabilidade é complexa e por isso um campo fértil para estudos. No exemplo apresentado, modelos que pertencem a uma mesma organização (mas que no caso concreto da Petrobrás não ao mesmo departamento) apresentam significados diferentes. Não é difícil imaginar que problemas semelhantes ocorram em outras organizações. Talvez essas divergências estejam relacionadas ao número de departamentos, pois quanto maior esse número mais difícil deve ser obter um consenso sobre a definição de um conceito.

É possível observar ainda que problemas de interoperabilidade ocorrem também em modelos de referência (ISO e outros), pois ao comparar dois modelos fatalmente serão encontradas definições diferentes para um mesmo conceito. Durante a aula de Engenharia de Software, alguém disse que estudaria a interoperabilidade de modelos durante seu doutorado/mestrado.

O problema de interoperabilidade de conceitos não necessita de ser entre empresas e nem entre departamentos. Conhecemos um caso em que uma empresa tinha particularmente um departamento de portos, onde entre outros requisitos, desejava-se controlar os equipamentos utilizados no embarque e o embarque em si. Uma das funcionalidades que supria este requisito era o relacionamento entre parada de embarques e suas causas, por exemplo, mau tempo. Uma das causas era relativa as paradas de equipamentos, i.e. se nenhum equipamento operasse, o embarque parava. E assim, existia uma divergência de conceitos entre os operários do mesmo departamento. Alguns desses operários alegavam que a culpa da parada de embarque era do último equipamento que parasse de trabalhar, e outros diziam que dependia da causa da parada do equipamento. Por exemplo, um equipamento pode parar por falha elétrica, falha mecânica, falha operacional ou mudança de rota de equipamento.

Neste exemplo, vemos que ao explicitar a semântica de um relacionamento causamos conflitos até mesmo com conhecedores do domínio de uma mesma região/empresa.