Definindo a Arquitetura de Agentes

Na última aula avançamos em nosso primeiro modelo de objetivos e várias dúvidas já surgiram.
Mas, tendo em vista que esse foi o assunto de um post no blog do Tiago, meu parceiro nesse trabalho, o foco principal desse meu post será outro.
Um único detalhe sobre a experiência de construir esse primeiro modelo que gostaria de acrescentar às observações relatadas pelo Tiago foi o fato de termos sentido a necessidade de diferenciar um refinamento "or" de um refinamento "xor" (ou exclusivo), mas a linguagem utilizada só provê uma sintaxe concreta especificada como refinamento "or" de forma que tivemos de recorrer a anotações para explicitar essa diferenciação.
A grande novidade da aula em termos de conteúdo ficou por conta da apresentação do modelo de Design Arquitetural. Essa perspectiva visa a permitir o refinamento dos agentes que realizarão os objetivos definindo os "componentes" que formam esses agentes, bem como os objetivos/requisitos que serão realizados por cada componente. Me parece muito útil especialmente no projeto de sistemas de software.
Até a próxima aula, se tudo der certo, com o modelo finalizado!

Tipos de delegação

Nossa primeira aula de 2013 teve como principal foco incluir novos elementos em nossos modelos de objetivos, a saber: tarefas e recursos. Esses elementos são relacionados aos objetivos através de relações "means-end" uma vez que representam meios de se realizar os objetivos.
Agora, com esses novos elementos, podem ser definidos três tipos de delegação/dependência (em post anterior foram definidos os conceitos de delegação e de dependência):

• Delegação/Dependência de objetivo: nesse caso o objetivo é delegado ficando a cargo do agente "delegatee" definir como realizar o objetivo. Devido a essa característica, é classificado como "open delegation".
• Delegação/Dependência de tarefa: nesse tipo de delegação o agente "delegator" define uma tarefa a ser executada para realizar o objetivo e a delega a outro agente, nomeado "delegatee". Por definir a forma de realização do objetivo, esse tipo de delegação é classificado como "close delegation".
• Delegação/Dependência de recurso: ocorre quando o agente "delegator" define o recurso a ser utilizado mas não define a tarefa a ser executada.

No fim da aula iniciamos o desenvolvimento de um trabalho cuja meta é gerar um modelo de objetivos para um domínio conhecido. Ao realizar essa tarefa conseguiremos avaliar o quão difícil é definir quando aplicar cada um dos conceitos.

Primeiro Modelo

Em nossa última aula de 2012 desenvolvemos, em grupo, nosso primeiro modelo de objetivos. Essa atividade foi minha primeira experiência prática com modelagem de objetivos. Foi uma boa introdução pois ajudou a solidificar alguns conceitos.
Um fato que me chamou atenção foi que a notação utilizada não tem expressividade para modelar a noção de temporalidade. Por exemplo, quando decompomos um objetivo em vários subobjetivos não temos como definir a ordem temporal em que esses subobjetivos devem ser realizados a fim de que o objetivo maior seja satisfeito. De fato, essa questão temporal deve ser modelada utilizando outro tipo de linguagem pois não está no escopo dos modelos de objetivo em geral.
Apesar de considerar que em alguns casos essa noção de temporalidade pode fazer falta, mesmo não tendo experiência em modelagem de objetivos, já deu para notar que a quantidade de conceitos englobados é muito grande de forma que é totalmente compreensível que alguns conceitos menos centrais fiquem de fora do escopo a fim de se controlar a complexidade das linguagens e, consequentemente, dos modelos produzidos.
Além dos conceitos definidos em aulas anteriores, no desenvolvimento do modelo foram utilizados também conceitos introduzidos nessa aula. Dentre esses conceitos destaco os conceitos de dependência e delegação entre atores. O conceito de dependência permite descrever a relação de dependência que pode haver entre dois agentes relacionados por um objetivo. Nessa relação, um agente (o depender) pode depender da realização de um objetivo enquanto essa realização depende da ação de um outro agente (o dependee). Um caso especial de dependência é a delegação. Na delegação há um compromisso firmado entre o depender (nesse contexto nomeado delegator)  e o dependee (então nomeado delegatee) para a realização do objetivo.

Segunda Aula

Em nossa segunda aula, alguns dos assuntos abordados na primeira aula voltaram ao foco da discussão. Nessa aula começaram a ser definidos mais claramente alguns conceitos centrais em análise de objetivos e, mais especificamente, no contexto de GORE.

O primeiro deles foi o conceito de objetivo. Um objetivo de um sistema pode ser definido como um fim a ser atingido por esse sistema. É importante ressaltar que podem ser definidos objetivos em diferentes níveis de abstração, ou seja, considerando uma abordagem top-down, pode-se definir objetivos mais genéricos e especializá-los/refiná-los.  Além das relações de decomposição, podem ser definidas também relações de contribuição e de alternativas entre objetivos. As relações de contribuição visam a capturar se a busca por um objetivo influencia positivamente ou negativamente em outro objetivo enquanto as relações de alternativas tem por finalidade registrar as diversas opções para se realizar um dado objetivo.

Um outro conceito interessante apresentado foi o de "soft goal". Se classificam como "soft goals" objetivos para os quais não é possível definir um critério objetivo de satisfatibilidade. Finalmente, um terceiro conceito abordado foi o conceito de requisito. Segundo a abordagem exposta, a maior diferença conceitual entre um objetivo e um requisito é que requisitos fornecem um critério de corte preciso. Por exemplo, posso ter como objetivo de um sistema “enviar comandos em tempo hábil” e, a partir desse objetivo, gerar o requisito “enviar comando em menos de um segundo em pelo menos 95% das ocorrências”.

Apesar de terem sido apresentadas algumas definições um pouco mais criteriosas sobre esses conceitos, a diferença entre eles ainda me parece bastante sutil e um tanto subjetiva. Na próxima aula desenvolveremos nossos primeiros modelos, o que deve nos ajudar na percepção das diferenças e das relações entre esses conceitos no contexto de GORE.

GORE - Um mundo de expectativas surge...:)

Quando, na primeira aula, falou-se em Engenharia de Requisitos Orientada a Objetivos duas questões principais instigaram minha curiosidade:

1. Qual a diferença fundamental entre o conceito de requisito e de objetivo nesse contexto?
   Intuitivamente tendemos a crer que um requisito seria uma característica necessária a um sistema para atingir um ou mais objetivos do mesmo. Mas, quando na aula, começamos a decompor objetivos em sub-objetivos, diminuindo a granularidade dos mesmos chegamos em um ponto onde ficou a dúvida sobre estarmos lidando ainda com um objetivo ou com um requisito. Segundo a metodologia i*, os requisitos surgem da decomposição dos objetivos, sendo que os requisitos são atômicos. Mas, confesso que para mim, um iniciante na área, ainda é difícil enxergar o limite entre esses conceitos. Fica então a expectativa de que, através da utilização prática de GORE e da análise ontológica desses conceitos, consigamos compreender esse tênue limite.


2. Por que utilizar GORE? Uma pergunta que sempre surge quando pensamos em estudar estudar uma nova técnica para fazer algo é "o que essa técnica pode me dar de vantagem em relação ao que eu uso hoje para justificar meu esforço em aprendê-la?". Quando ouvi falar de GORE, não foi diferente. Já trabalhei em alguns projetos com levantamento e especificação de requisitos sem nunca ter usado um método orientado a objetivos, logo, qual vantagem GORE me traria?
   Pelo debate ocorrido na aula, as técnicas de GORE são bem formalizadas e as linguagens de modelagem utilizadas são bastante expressivas (ao contrário da Modelagem de Casos de Uso). Além do mais, segundo Kavakli e Loucopoulos (artigo utilizado como referência para a aula) há abordagens de GORE para auxiliar em cada uma das atividades de Engenharia de Requisitos. Fica então a expectativa por conhecer essas abordagens e seus métodos!

Primeira Aula

Há quem diga que uma boa aula é aquela que gera no aluno expectativa sobre "os próximos capítulos" da disciplina causando uma certa inquietude no mesmo. Sob essa ótica, a primeira aula não poderia ter sido melhor. 

A aula foi recheada de discussões interessantes acerca de conceitos como "objetivo", "objetivo individual", "objetivo organizacional", "requisito", dentre outros. Falou-se ainda sobre a utilização de objetivos em engenharia de requisitos, dando origem à Engenharia de Requisitos Orientada a Objetivos (GORE - Goal-Oriented Requirement Engineering) e sobre os motivos para a adoção de uma abordagem de engenharia de requisitos orientada a objetivos.

Com uma primeira aula tão rica em conceitos e debates, fica a expectativa para as próximas...