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.