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.