Aula 10 - 12/08/2013

Nesta aula, foi feita a explanação sobre "Agent-oriented Recipe for Knowledge", tese de Doutorado da Professora Renata Guizzardi.

Alguns tópicos citados:
1. CKM (Construtivist Knowledge Management);
2. TROPOS - para análise de ambiente organizacional;
3. Combinação de TROPOS e AORML = ArKnowD;
4. MDD (Model Driven Development) - para criação integrada de modelos - rastreabilidade.


O CKM - uso do Construtivismo na Gestão do Conhecimento.

O TROPOS é um método de desenvolvimento de software e um framework de desenvolvimento usado para análise de ambiente organizacional. Porém, este método é limitado para dar suporte a um design detalhado, necessitando de uma outra linguagem.

A Proposta: combinação de TROPOS e AORML para fornecer um design mais detalhado. A metodologia ArKnowD surge dessa combinação.

Foram apresentados três pontos de vista para a criação integrada de modelos: CIM (Computation Independent Model); PIM (Plataform Independent Model); e PSM (Plataform Specific Model).

Para fazer a transformação dos modelos em TROPOS  para o modelo em AORML,o uso de ontologia tornou-se necessário.

Para uma leitura mais aprofundada, leia a tese no link: http://doc.utwente.nl/56967/1/r_guizzardi.pdf

Aula 09 - 29/07/2013

Nesta aula, foi destacado o tópico Dependency link, que é um relacionamento de dependências que ocorrem entre agentes. Há dois tipos: link de dependência e link de delegação.

No link de dependência há as figuras do depender (aquele que depende de algo/alguém), dependum  (aquele/aquilo de que se depende) e dependee (aquele de quem se depende). Não há obrigação do dependee de realizar o dependum para o depender.

Por outro lado, no link de delegação, há as figuras do delegator (aquele que delega algo para alguém), delegatum (aquilo que se delega) e delegatee (aquele a quem se delega). Há obrigação do delegatee de realizar o delegatum para o delegator.

 O exemplo a seguir contém os dois links mencionados.

  

Aula 8 - 22/07/2013

Nesta aula, prosseguimos a discussão sobre a fundamentação ontológica do framework de i*, cuja discussão iniciou no dia 01/07/2013.

Entre as várias questões discutidas, destacamos o relacionamento de contribuição entre um task e um goal. Há quatro tipos de contribuição: 

• Make - ocorre quando uma task satisfaz completamente um goal. É uma consequência não intencional da tarefa, mas mesmo assim ocorre em decorrência da realização daquela tarefa.

• Break - ocorre quando uma task impede a satisfação de um goal. Seja uma tarefa 1 que leva a satisfação de uma situação que atende a um goal. Se existir uma tarefa 2 que impeça que esta situação seja satisfeita, então a tarefa 1 não poderá ser executada e o goal não poderá ser atingido. Diz-se que a tarefa 2 tem um relacionamento de break contribution com o goal.

• Help  - ocorre quando uma task satisfaz parcialmente um goal. Assim como o make contribution, o help ocorre de modo não intencional. Enquanto que no caso do make a tarefa leva a satisfação da situação que é ligada ao goal, no caso do help a tarefa leva a satisfação parcial da situation que é ligada ao goal.

• Hurt  - ocorre quando uma task dificulta a satisfação de um goal. Seja um goal G decomposto em G1  e G2 e seja uma tarefa T. Se T tem um relacionamento de break contribution com G1, então T tem um relacionamento de hurt contribution com G.

Aula 7 - 15/07/2013

Em tal aula foi ministrada uma palestra por Glaice Kelly Quirino, que apresentou o seu trabalho de conclusão de curso, denominado Integração Semântica entre dotProject e ODE.

Algumas ferramentas / tecnologias utilizadas em tal trabalho foram:

• ODE - Ambiente Integrado de Desenvolvimento de Software, baseado em Ontologia;
• DotProject - Ferramenta de apoio ao gerenciamento de projeto, em especial de cronograma;
• OBA-SI - Ontology-based Aprroach for Semantic Integration;
• SP-OPL - Software Process Ontology Pattern Language.

Dentro do gerenciamento de projeto, o trabalho focou em cronograma, tendo sido proposta a integração do AlocaDE (um módulo do ODE) ao dotProject, com o apoio de OBA-SI e SP-OPL. O objetivo do trabalho consistiu em, a partir das informações para elaboração de cronograma geradas no AlocaODE, importar tais informações para o dotProject, responsável por gerar o cronograma, que é então retornado (no formato de imagem) para o próprio AlocaODE.

Foi um processo interessante de conhecer, pois mostrou de forma prática a utilização de ontologias em um projeto de engenharia de software.

Foi brevemente comentado sobre os passos seguidos no projeto, sendo eles:

• Obtenção dos Modelos Conceituais do ODE e dotProject, sendo que este último não estava disponível e foi necessário realizar engenharia reversa para obter o modelo;
• Uma vez de posse de ambos os modelos foram realizados dois mapeamentos (um horizontal e um vertical). Esses mapeamentos deram origem a um modelo de integração, que consistiu basicamente da ontologia-base acrescetada dos novos conceitos presentes nos modelos conceituais;
• Em seguida foi obtido o modelo de projeto, que foi criado a partir do modelo de integração considerando as limitações das 2 ferramentas, o que acabou resultando em um modelo mais simples;
• Por fim, foi realizada a implementação da integração com base no modelo de projeto obtido.

Aula 6 - 08/07/2013

Em tal aula a turma foi liberada para assistir a palestra do prof. Dr. Roel Wieringa, da University of Twente (Holanda). A palestra foi sobre TAR - Technical Action Research.

Algumas questões que nos chamaram a atenção sobre tal assunto foram:

• Researcher Roles: Designer, Helper, Researcher. TAR says: Keep theses roles separeted;
• Observation Study (eg, Case Study) x Consulting x "Classic" Action Research;
• Action Goal x Knowledge Goal;
• TAR envolve  Client e Researcher.  A partir daí temos:
• Para se testar novos produtos há um Engineering Cycle, que pode ser executado como Researcher Cycle e Client Cycle;
• O palestrante fez uma interessante comparação desse ciclo de validação/avaliação com o processo de testar novos medicamentos, nos quais os testes são primeiro realizados em animais de laboratório, em seguida passa-se para pessoas saudáveis e por fim os testes são aplicados em pessoas doentes. Essa mesma filosofia poderia ser repassada para pesquisa em ciência da computação, onde ao testar uma ferramenta / método / linguagem poderíamos começar com estudantes da área, avançando para clientes-chave e por fim chegando aos clientes-alvo daquela ferramenta / método / linguagem;
• A sugestão do TAR é que o Empirical Research Cycle seja composto por: Researcher´s Engineering Cycle, Researcher´s Empirial Research Cycle e Client´s Engineering Cycle. Dessa forma atingiríamos testes mais completos, e ao mesmo tempo ao serem testados pelos seus clientes-alvos eles já teriam passado por uma bateria de testes, estando provavelmente mais estáveis;
•  Sobre Design Science, brevemente comentado e foco de uma segunda palestra, foi feita uma interessante comparação:
• Design Science - For Some (existential generalization);
• Basic Sciente - For All (universal generalization);
• Case Research - For one.

Aula 5 - 01/07/2013

Nesta aula, foram ministrados conceitos (construtos) da linguagem de modelagem de objetivos i*. Dentre eles, citamos: actor, hard goal, soft goal, task, resource, dependence, decomposition, means-end, contribution.

Após tal introdução, foi apresentado uma análise ontológica sobre tal linguagem, nos moldes comentados no post anterior.  A ontologia de referência foi a UFO.

Como resultado foram identificados problemas de construct overload, construct redundancy, construct excess e construct deficity. A fim de exemplificar, tomemos o problema de construct redundancy, que foi identificado entre as relações Decomposition (AND e OR) e Means-End, ambas sem um critério claro de utilização estabelecido, em princípio, podendo ser utilizadas nas mesmas situações. Como resultado dessa análise, foi proposta uma diferenciação de uso desses conceitos: Decomposition - para decomposições envolvendo as mesmas entidades;  Means-End - para decomposições envolvendo entidades diferentes.

Aula 4 - 24/06/2013

Sobre a Aplicação de Ontologias para Avaliar Linguagem de Modelagem
A ideia é usar uma ontologia de referência (seja uma ontologia de fundamentação, como UFO, seja uma ontologia de domínio)  para avaliar o metamodelo de uma linguagem de modelagem. É feito um mapeamento do metamodelo da linguagem para a ontologia de referência e idealmente essa relação é isomórfica. Dessa forma, é possível avaliar a qualidade da linguagem na sua intenção de representar um certo aspecto da realidade.
A crença é de que toda linguagem de modelagem tem por trás dela uma ontologia e que "o oposto de não ter uma ontologia explícita não é não ter ontologia nenhuma, e sim ter uma ontologia ruim, isto é, inadequada).  O que destaca a importância de se ter uma ontologia de referência adequada ao contexto no qual a linguagem em avaliação é aplicada.
Uma vez que esse mapeamento é realizado, os construtos da linguagem são melhor compreendidos, soluções para os possíveis problemas encontrados podem ser propostas, diferentes linguagens podem ser integradas (se for a intenção da avaliação), e assim a qualidade da linguagem de modelagem é incrementada.
Alguns problemas que podem ser encontrados durante tal avaliação:

• Construct Overload;
• Construct Redundancy;
• Construct Excess;
• Construct Deficit (incompleteness);
• Inconsistency.

Aula 3 - 17/06/2013

Esta 3a. aula foi uma introdução sobre UFO, tendo sido brevemente discutidas noções sobre UFO-A, UFO-B e UFO-C. Vários tópicos foram levantados, em especial alguns que nos chamaram a atenção e gostaríamos de explorar melhor são:

• Nível de Generalidade de Classificação de Ontologias - As fronteiras entre as diferentes classificações para ontologias podem não ser tão simples quanto se pensou (como quando Guarino formulou sua hierarquia de Ontologias - Generic Ontology, Domain Ontology, Task Ontology, Application Ontology). Foi sugerido o seguinte espectro:

• Qua Individual- Olhar para as qualidades em um determinado contexto, dessa forma resolvendo uma série de problemas de modelagem conceitual. Este é um conceito que permite associar propriedades contraditórias para o mesmo objeto, em contextos diferentes. Por exemplo, Romário (individual) foi um bom jogador (qua individual) e um deputado ruim (qua individual).

Aula 2 - 10/06/2013

Representação versus interpretação de modelos conceituais

Com o aumento das relações interpessoais em diferentes escalas, advindo das diversas revoluções tecnológicas, principalmente, com o aumento do uso da Internet, o problema da interoperabilidade semântica acentuou-se. Mas, o que é interoperabilidade semântica? É a necessidade de se trabalhar em conjunto, compartilhando significados presentes na conceituação requerida.

É importante ressaltar que cada stakeholder envolvido nesse trabalho possui um modelo mental. Assim, qual é a distância semântica entre tais modelos? Esta distância deve ser suficientemente pequena para permitir a comunicação entre os stakeholders, resultando em uma melhora na interoperabilidade semântica.

Uma solução é o uso de ontologias, iniciando com a ontologia de fundamentação (top-level ontology) para entender os tipos de conceitos e suas relações e, posteriormente, estender os conceitos existentes da ontologia de domínio baseados na ontologia top-level.

 

Aula 1 - 03/06/2013

O objetivo dessa aula foi apresentar as Cenas dos Próximos Capítulos ...

• Foi realizado um brainstorming sobre o tema ontologias, sua relação com a Engenharia de Software e as Organizações;
• Foram apresentados os objetivos e ementa da disciplina, com contribuições da turma;
• Foram idenficadas as formas de avaliação;
• Foi sugerido material de leitura básica, bem como identificados os pré-requisitos básicos.

E assim nós começamos ...