Integrating Activity Theory and i* Technique in the Late Requirements Phase

Transcrição

1 1644 Integrating Activity Theory and i* Technique in the Late Requirements Phase E. P. Teixeira, V. F. A. Santander and F. L. Grando Abstract The main focus of the Requirements Engineering is to generate requirements specifications that meet the needs of users and clients. To assist requirements engineers, in this work we propose a set of guidelines to deriving i* organizational models for the late requirements phase from activities models. We argue that integrating the i* technique and activity theory we can produce more complete and non-ambiguous requirements models by exploring these two different views. The proposed guidelines are applied to a Pet Shop case study. Keywords Activity Theory, i* Technique, Requirement Engineering. I. INTRODUÇÃO O DESENVOLVIMENTO de sistemas computacionais na atualidade enfrenta vários desafios. Um dos principais desafios está associado à necessidade de compreender e expressar de forma não ambígua e completa os requisitos de sistemas de software. Neste contexto, a engenharia de requisitos tem focado seus esforços em propor técnicas e processos que permitam apoiar esta difícil tarefa. Vários trabalhos têm proposto a necessidade de entender e modelar o contexto organizacional como meio efetivo para compreender as motivações que norteiam o desenvolvimento de sistemas computacionais [2], [6], [14]. Neste sentido é importante destacar a utilização da técnica denominada i*, proposta por Eric Yu [14]. Esta técnica permite explorar as intencionalidades associadas aos atores de uma organização sob a forma de objetivos, tarefas, recursos e objetivos-soft. Assim, processos organizacionais podem ser compreendidos e modelados já considerando, por exemplo, o impacto da utilização de um sistema computacional nesse contexto. Outro aspecto positivo da técnica i* é que, a partir da mesma, podem-se derivar artefatos de software orientados a objetos, como proposto em [1], [12]. Esta técnica também é parte integrante do framework TROPOS [13], o qual propõe um processo e ferramentas para o desenvolvimento de software orientado a agentes. Contudo, uma das dificuldades no uso da técnica i* está associada ao processo de construção dos modelos propostos pela mesma. Neste sentido, algumas propostas [5], [8], têm surgido para auxiliar engenheiros de requisitos na descoberta E. P. Teixeira, Universidade Estadual do Oeste do Paraná, Brasil, elianapteixeira@yahoo.com.br V. F. A. Santander, Universidade Estadual do Oeste do Paraná, Brasil, vfasantander@unioeste.br F. L. Grando, Universidade Estadual do Oeste do Paraná, Brasil, fernandogrando@gmail.com. dos elementos intencionais estratégicos em uma organização. Destaca-se neste contexto a proposta apresentada em [5], a qual considera a Teoria da Atividade [11] como base para elicitar e elaborar modelos organizacionais que descrevem um ambiente organizacional. O uso da Teoria da Atividade permite, de uma forma mais organizada, entender os elementos que estão associados à realização de atividades em um contexto de relações interpessoais. A análise destas atividades e seus elementos associados melhora consideravelmente o processo de construção de modelos i*. Entretanto, a proposta apresentada em [5] não considera a construção de modelos organizacionais nos quais já se estabeleça as intencionalidades que devem estar associadas a sistemas computacionais, os quais irão automatizar parcial ou completamente processos de negócio. Isto implica em afirmar que o sistema computacional pretendido deve ser considerado como um ator no contexto organizacional e deve-se explorar as intencionalidades dos demais atores em relação ao mesmo. O objetivo deste trabalho é apoiar a elaboração de modelos em i* a partir de modelos da Teoria da Atividade, já considerando as dependências em relação a um sistema computacional pretendido. Este novo foco facilita a compreensão dos benefícios do uso da Teoria da Atividade e modelos i* no desenvolvimento de sistemas computacionais. Este trabalho está estruturado da seguinte forma. Na seção II descreve-se brevemente a técnica i*. Na seção III apresentam-se os princípios básicos da Teoria da Atividade, exemplificados com o estudo de caso de uma Clínica Veterinária. Na seção IV apresenta-se um conjunto de diretrizes que apoiam o processo de construção de modelos i* para a fase de requisitos detalhados a partir de modelos de atividades. Estas diretrizes são apresentadas e exemplificadas no contexto do problema da Clínica Veterinária. Finalmente, na seção V são apresentadas as considerações finais e trabalhos futuros. II. MODELAGEM I* A técnica i* objetiva possibilitar a representação/modelagem de aspectos organizacionais envolvidos com processos [14]. Basicamente, permite descrever aspectos de intencionalidade e motivações envolvendo atores em um ambiente organizacional. Esta técnica provê uma compreensão das razões ( Porquês ) que estão associadas aos requisitos de software [3]. Para descrever o ambiente organizacional, i* propõe dois modelos: o Modelo de Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). O modelo SD descreve os relacionamentos

2 TEIXEIRA et al.: INTEGRATING ACTIVITY THEORY de dependências entre os vários atores no contexto organizacional. Este modelo é composto por nós e ligações. Os nós representam os atores no ambiente e as ligações representam as dependências entre os atores. O ator é uma entidade que realiza ações para obter objetivos no contexto do ambiente organizacional. Atores dependem uns dos outros para atingir objetivos, realizar tarefas, e obter recursos no ambiente organizacional. O ator que depende de outro ator é chamado de Depender e o ator responsável por cumprir a dependência é denominado de Dependee. O objeto ou elemento de dependência entre Depender e Dependee é denominado de Dependum. Portanto, haverá relacionamentos do tipo Depender Dependum Dependee. Já o modelo SR permite expressar os meios e formas alternativas que os atores que desempenham um papel de Dependee nos relacionamentos consideram na satisfação de suas dependências. Na Fig. 1 apresentam-se as notações gráficas utilizadas na técnica i* para representar atores e dependências entre os mesmos. Figura 1. Notações gráficas utilizadas na técnica i*. III. TEORIA DA ATIVIDADE A Teoria da Atividade [11] possui origens na filosofia sócio-cultural soviética. Foi fundada por Lev Vygostsky e seus colegas Leont ev [10] e Luria [15]. Esta teoria trata de um conjunto de princípios para a compreensão, descrição e análise do contexto sócio-cultural adotando a atividade humana como elemento central de análise. Os atuais métodos que operacionalizam a Teoria da Atividade baseiam-se no diagrama de Engeström [7]. Este diagrama estende os princípios básicos de Leont ev para tratar aspectos de coletividade. Neste modelo, ações individuais são realizadas dentro de um sistema coletivo. Isso define que uma atividade é um conjunto de relações entre um grupo de indivíduos e o seu ambiente. A estrutura do modelo é mostrada na Fig. 2. Figura 2. Modelo Sistêmico da Atividade. Para permitir visualizar as atividades considerando um sistema coletivo, são incorporados os conceitos de comunidade, regras sociais e divisão do trabalho, os quais permitem representar os fatores sociais do trabalho em grupo. Todos os indivíduos que compartilham um mesmo objeto formam o que chamamos de comunidade [9]. Dentro desta 1645 comunidade são estabelecidas normas e convenções sociais. Estas normas e convenções são regras definidas como forma de mediação entre sujeito e comunidade. A divisão do trabalho, enquanto forma de mediação entre a comunidade e o objeto, refere-se à forma de organização de um grupo de pessoas relacionada ao processo de transformação do objeto em um resultado. As ferramentas de mediação são instrumentos que são usados para realização de um trabalho, pelos quais uma pessoa ou um grupo de pessoas pode utilizar com o propósito de transformar um objeto, de forma que este satisfaça aos requisitos e ofereça um melhor resultado. As atividades estão associadas a intencionalidades e motivações pessoais, podendo se subdividir em ações observáveis orientadas a um determinado objeto e por último, a pequenas operações realizadas inconscientemente pelos sujeitos (nível de operação). Para facilitar a compreensão da modelagem das atividades utilizando esta teoria, a mesma foi aplicada ao estudo de caso de uma Clínica Veterinária e suas principais atividades cotidianas. A Fig. 3 mostra o modelo de atividades correspondentes às atividades humanas identificadas nesta Clínica. As atividades podem ser resumidas em: Cadastrar Cliente, Fazer Orçamento, Agendar Horário, Solicitar Serviço Leva e Traz, Recolher Animal, Prestar Serviços Requeridos ao Animal e Obter Pagamento Pelos Serviços. Na primeira atividade, Cadastrar Cliente, o Funcionário e o Cliente fazem parte da atividade. Esta atividade se subdivide em duas ações: Fornecer Informações Pessoais e Gravar Informações Pessoais. O Cliente é responsável por fornecer suas informações pessoais através da ferramenta de mediação Comunicação, e o Funcionário é responsável por gravar as informações pessoais do Cliente utilizando-se da ferramenta de mediação Planilha Eletrônica. Esta planilha pode ser qualquer tipo de programa de computador que utiliza tabelas para apresentação de dados, formada por uma grade composta de linhas e colunas, disponível gratuitamente na internet. Algumas motivações estão associadas às atividades, as quais dizem respeito aos aspectos que motivam a realização das atividades por parte dos indivíduos. Por exemplo, as nuvens ao redor do sujeito Funcionário, na atividade de Cadastrar Cliente, indicam que o funcionário é motivado pela necessidade da Disponibilidade dos Dados do Cliente e Organização. Observando a atividade Fazer Orçamento na Fig. 3, pode-se visualizar que é necessário o envolvimento tanto do Funcionário quanto do Cliente na realização da mesma. Como motivação da atividade, destaca-se a satisfação do Cliente em ter o conhecimento prévio dos preços dos Serviços Requeridos ao Animal. Esta atividade está decomposta basicamente em duas ações: Escolher Serviços Para Orçamento e Calcular o Valor dos Serviços. Nesta última ação pode-se visualizar que o cálculo do valor dos serviços é realizado através da ferramenta de mediação Calculadora. Já observando a atividade Agendar Horário, pode-se verificar que o Cliente é responsável pela ação Escolher Horário e o Funcionário é responsável pela ação Verificar Disponibilidade. Na atividade Solicitar Serviço Leva e Traz, o Cliente tem como motivação a

3 1646 Figura 3. Diagrama de Atividades para o estudo de caso da Clínica Veterinária.

4 TEIXEIRA et al.: INTEGRATING ACTIVITY THEORY Comodidade e o Funcionário é motivado pelo fato de Receber Pelo Serviço prestado. Em relação a esta atividade, foram modeladas algumas características de qualidade que são esperadas pelos clientes, tais como, Agilidade e Eficiência, as quais dizem respeito a restrições de qualidade impostas a realização da referida atividade. Um aspecto importante que deve ser observado na Fig. 3, é que para realizar a atividade Recolher Animal é necessário que o animal tenha sido encaminhado à Clínica Veterinária através do Serviço Leva e Traz. Da mesma forma pode-se observar que para realizar a atividade Prestar Serviços Requeridos ao Animal é necessário que o animal já esteja recolhido (objeto: Animal Recolhido) e para Obter Pagamento Pelos Serviços, que o serviço já tenha sido concluído (objeto: Serviço Concluído). Finalmente, analisando a atividade Obter Pagamento Pelos Serviços, podese destacar que o cliente é motivado a efetuar o pagamento a fim de cumprir suas obrigações financeiras. Assim, utilizando as estratégias propostas pela Teoria da Atividade é possível representar as intencionalidades e dependências existentes entre atividades no contexto do estudo de caso da Clínica Veterinária. O diagrama criado permite inclusive evidenciar conflitos entre atividades modeladas. Desta forma, é proposto neste trabalho que os elementos modelados na Fig. 3 possam servir de base para a elaboração dos modelos organizacionais em i*, com foco nas atividades que serão associadas ao sistema computacional pretendido para a Clínica Veterinária. Na próxima seção são descritas as diretrizes de mapeamento que permitem gerar os modelos i* a partir dos Diagramas de Atividades gerados utilizando os princípios da Teoria da Atividade. IV. CONSTRUINDO MODELOS I* PARA A FASE DE REQUISITOS DETALHADOS É importante ressaltar que a presente proposta está fundamentada no trabalho realizado por Cruz Neto em [5], no qual utiliza-se a Teoria da Atividade para melhorar a construção de modelos i* na fase de requisitos iniciais. Contudo, considera-se que este trabalho deve ser estendido para apoiar o processo de construção de requisitos detalhados, os quais representam as intencionalidades associadas ao sistema computacional sendo desenvolvido. Assim, a partir de modelos i* contendo estas intencionalidades pode-se, por exemplo, derivar outros artefatos do processo de desenvolvimento orientado a objetos, como proposto em [12], [2]. A. Mapeando Diagramas da Teoria da Atividade em modelos i* A seguir, apresenta-se um conjunto de diretrizes para apoiar o processo de análise das categorias e representação de atividades em um diagrama de atividades, visando a construção de modelos i* na fase de requisitos detalhados. A apresentação de cada diretriz vem acompanhada de um exemplo no contexto do estudo de caso sobre as atividades da Clínica Veterinária (Fig. 3). Primeiramente, propõe-se gerar um modelo intermediário utilizando quadros para organizar, bem como documentar e 1647 armazenar as informações e o processo contidos nos modelos de atividades. Em seguida, observando os quadros gerados juntamente com o modelo de atividades apresentado propõe-se realizar uma análise já considerando uma nova solução de software para automatizar algumas das atividades e/ou ações associadas. Basicamente esta análise consiste em considerar a possibilidade de alterar a ferramenta de mediação de algumas ações para considerar um suporte computacional como meio de realização das referidas ações. Assim, analisando os diagramas do modelo de atividades da Fig. 3, as informações de cada atividade serão mapeadas para um quadro, já considerando diferentes ferramentas de mediação, com o objetivo de melhorar o processo existente. Cabe ressaltar que neste momento cada atividade é analisada independentemente e podem ser considerados os seguintes aspectos: De que forma um sistema computacional pode sustentar dada atividade? Por exemplo, observando a Fig. 3, analisando a atividade Cadastrar Cliente, um sistema computacional pode dar suporte a esta atividade agilizando e melhorando o processo de cadastro. Assim, por exemplo, o Funcionário deixará de utilizar uma Planilha Eletrônica e usará um módulo de cadastro do sistema para realização da atividade. A medida que novos atores (indivíduos) são descobertos, as dependências existentes devem ser realocadas? A partir do momento que um sistema computacional é inserido na organização, um novo ator deve ser inserido no modelo organizacional i*. Observando a atividade Cadastrar Cliente na Fig. 3, pode-se visualizar que o Funcionário passará a depender do sistema para a obtenção do objetivo da atividade. Será mantido o mesmo ator para satisfazer as dependências da atividade? Utilizando como exemplo a atividade Cadastrar Cliente, observada na Fig. 3, pode-se concluir que através da inserção do sistema, o Funcionário passará a ter como intenção a obtenção das informações pessoais do Cliente. Contudo, o sistema computacional passará a ser responsável pela conclusão da atividade. Podem ser identificadas funcionalidades de componentes ou módulos de software? Observando a Fig. 3, analisando as atividades da Clínica Veterinária, pode-se identificar três possíveis módulos do sistema computacional pretendido: Cadastro de Cliente, Agendamento e Orçamento. Surgirão novas ações? Quem serão os atores responsáveis? Por exemplo, observando a atividade Cadastrar Cliente, podem surgir novas ações. Identificase para o ator Funcionário a ação Obter Informações Pessoais do Cliente e como ação do sistema Gravar Informações Pessoais. Desta forma, seguindo o processo sugerido, para cada atividade modelada na Fig. 3, deve-se construir quadros considerando: os atores envolvidos, motivações associadas, ações, atores responsáveis por cada ação, ator ou atores dependentes, ferramentas de mediação, recursos produzidos,

5 1648 recursos consumidos e recursos fornecidos. Como resultado deste mapeamento obtém-se os seguintes Quadros I, II e III apresentados a seguir. Sistema. QUADRO III ATIVIDADE: AGENDAR HORÁRIO. QUADRO I ATIVIDADE: CADASTRAR CLIENTE. Observando o Quadro I, pode-se visualizar que a ferramenta de mediação Planilha Eletrônica foi substituída por uma funcionalidade do Sistema, que deve implementar os requisitos de forma a satisfazer da melhor forma o resultado dessa atividade. Isto implica em afirmar que o Sistema aqui proposto passa a ter responsabilidades sobre certas ações no âmbito desta atividade. Desta forma, uma análise deve ser feita, a fim de identificar se é necessário modelar novas ações para o Sistema. Para a atividade Cadastrar Cliente, foi identificado para o Sistema as ações Inserir e Gravar Informações Pessoais, que antes era responsabilidade do Funcionário. O Funcionário por sua vez, passou a ter responsabilidade sobre a ação Obter Informações Pessoais, e dependerá do Sistema para executar as ações Inserir e Gravar Informações Pessoais. QUADRO II ATIVIDADE: FAZER ORÇAMENTO. Observando o Quadro II, pode-se verificar que a ferramenta de mediação Calculadora foi substituída por uma funcionalidade do Sistema. Foi identificado para o Cliente a ação Escolher Serviços, na qual o Cliente comunica verbalmente ao Funcionário as escolhas realizadas. Para o Funcionário foi identificada a ação Obter Lista de Serviços, e as ações Inserir Serviços Escolhidos, Calcular o Valor dos Serviços e Mostrar Valor passaram a ser implementadas no Sistema computacional a ser desenvolvido. Desta forma, o Funcionário dependerá do Sistema para alcançá-las. No Quadro III, correspondente à atividade Agendar Horário, as ferramentas de mediação Caderno, Agenda e Caneta foram substituídas por uma funcionalidade do Sistema. A ação Escolher Horário foi identificada para o Cliente, onde o mesmo comunica verbalmente ao Funcionário o horário desejado. Para o Funcionário foi identificada a ação Obter Opção Horário e as ações Inserir Horário Escolhido, Verificar Disponibilidade e Marcar Horário foram identificadas para o As atividades Solicitar serviço Leva e Traz, Recolher animal, Prestar serviço requerido ao animal e Obter pagamento pelos serviços não serão implementadas no Sistema e, portanto, continuarão sendo responsabilidade dos mesmos atores do Diagrama de Atividades da Fig. 3. A seguir, apresentam-se algumas diretrizes que apóiam o processo de mapeamento dos modelos em i* a partir das informações presentes nos quadros construídos via uso dos princípios da Teoria da Atividade. 1) Gerando o Modelo de Dependências Estratégicas Apresenta-se a seguir as diretrizes que apóiam o processo de mapeamento dos elementos do Modelo de Dependências Estratégicas em i* a partir dos quadros construídos considerando o Modelo de Atividades da Fig. 3. Como resultado da utilização destas diretrizes, tem-se o Diagrama SD da Fig. 4. Cada diretriz é descrita e exemplificada considerando o estudo de caso da Clínica Veterinária conforme modelo da Fig. 3 e quadros descritivos associados. Diretriz 1 Descobrindo atores: todo sujeito de uma atividade deve ser modelado como um ator no modelo organizacional. Também deve ser feita uma análise das ferramentas de mediação dos quadros das atividades (Quadros I, II e III). Se alguma ferramenta de mediação for uma funcionalidade do sistema, o sistema deve ser mapeado para o modelo como um novo ator. Através da observação das atividades modeladas nos Quadros 1, 2 e 3, tem-se como sujeitos das atividades o Funcionário, o Cliente e o Sistema. Estes sujeitos então são mapeados para atores no modelo SD da Fig. 4. Diretriz 2 Descobrindo dependências entre sujeitos de uma mesma atividade: quando uma atividade é realizada por dois sujeitos X e Y, gera-se inicialmente um relacionamento de dependência entre os dois no modelo de dependências estratégicas. No entanto, deve-se observar se o ator usa como ferramenta de mediação uma funcionalidade do sistema. Neste caso, gera-se também uma dependência entre esse ator e o futuro sistema. O nome dado ao relacionamento é o mesmo dado ao objetivo da atividade. Caso o critério de avaliação da conclusão deste objetivo seja subjetivo, gera-se uma dependência do tipo objetivo-soft, caso contrário uma dependência do tipo objetivo deve ser criada. O ator que depende do outro é chamado depender e o ator responsável por satisfazer a dependência é chamado de

6 TEIXEIRA et al.: INTEGRATING ACTIVITY THEORY 1649 Figura 4. Modelo de Dependência Estratégica da Clínica Veterinária. dependee (Depender dependência Dependee). Aplicando esta diretriz no modelo de atividades da Fig. 3 e observando mais atentamente os objetivos associados com as atividades descritas, tem-se como resultado a geração das dependências do tipo objetivo denominadas: Cadastro de Cliente Criado, Orçamento Concluído, Horário Agendado, Serviço Leva e Traz Solicitado, Pagamento Obtido, Serviço Concluído, Animal Recolhido. Estas dependências são relacionadas no modelo SD entre os atores Funcionário e Cliente que participam na realização das atividades. Por outro lado, considerando as ações associadas à atividade Cadastrar Cliente no Quadro 1, verifica-se que como uma funcionalidade do Sistema é utilizada como ferramenta de mediação e o Funcionário é o principal interessado na realização da atividade, cria-se um relacionamento de dependência do Funcionário para o Sistema (Funcionário CadastroDeClienteCriado Sistema) conforme pode ser visualizado na Fig. 4. Diretriz 3 Descobrindo dependências do tipo recurso entre atividades: quando a atividade A do ator X se usufrui de um recurso produzido por um ator Y da atividade B, gera-se no modelo organizacional uma dependência de recurso entre os atores X e Y (X recurso Y). Deve-se observar também se o ator usa como ferramenta de mediação uma funcionalidade do sistema. Neste caso, também estabelece-se uma relação de dependência entre esse ator e o futuro sistema. Se existirem mais de um ator em cada atividade, o relacionamento incide sobre os atores com maiores interesses na realização das atividades, para que não exista uma explosão de relacionamentos no modelo i*. No entanto, caso sejam X e Y o mesmo indivíduo, ao invés do relacionamento de dependência de recurso, criase o recurso como um elemento de decomposição da tarefa que representa a atividade B, e gera-se uma relação de meio-fim entre a tarefa que representa B e a tarefa que representa A. No modelo de atividades da Fig. 3, verifica-se que o Cliente da atividade Obter Pagamento Pelos Serviços depende do recurso Serviço Concluído do Funcionário quando este realiza a atividade Prestar Serviços Requeridos ao Animal. Assim, o relacionamento de dependência do tipo de recurso Serviço Concluído deve ser representado conforme modelado na Fig. 4 (Cliente ServiçoConcluído Funcionário). 2) Gerando o Modelo de Razões Estratégicas O modelo de Razões Estratégicas fornece um nível mais detalhado da organização explorando de que forma as dependências entre atores podem ser satisfeitos pelos atores que atuam no papel de Dependee no relacionamento. A seguir apresentam-se as diretrizes que permitem gerar o modelo de Razões Estratégicas. Para cada diretriz, apresenta-se um exemplo considerando o estudo de caso da Clínica Veterinária. Como resultado da utilização destas diretrizes, obtém-se o modelo SR para o estudo de caso da Clínica Veterinária. Diretriz 4 Mapeando atividades como tarefas internas a atores organizacionais: para cada ator X de uma atividade A, gera-se uma tarefa na área do ator X com o nome da atividade A. No entanto, deve-se observar se um desses atores envolvidos na atividade usa como

7 1650 ferramenta de mediação uma funcionalidade do sistema. Se isto ocorre, deve-se gerar esta mesma tarefa na área do ator Sistema. Observe que no caso de uma atividade ter dois ou mais atores envolvidos, tem-se a criação de uma tarefa na área limite de cada ator. A escolha de qual relacionamento do Modelo Estratégico de Dependência estas tarefas devem satisfazer é definida pelas subdiretrizes abaixo: Sub-diretriz Dependência entre atores em uma mesma atividade: a tarefa representando uma atividade de dois atores X e Y está conectada ao relacionamento de dependência entre X e Y gerada seguindo a Diretriz 2. Sub-diretriz Dependência entre atores de atividades diferentes: na existência de uma atividade A do ator X que depende de algo provido por uma atividade B associada ao ator Y, então as tarefas que representam as atividades A e B são relacionadas à dependência entre X e Y gerada pela Diretriz 3. Observando o Quadro 1, pode-se visualizar que os atores envolvidos na atividade Cadastrar Cliente são Funcionário, Cliente e Sistema. Cada um desses atores recebe nas suas respectivas áreas limite uma Tarefa que corresponde à participação do ator na atividade. Como o Funcionário, o Cliente e o Sistema participam da atividade Cadastrar Cliente, segue-se a sub-diretriz 4.1, na qual as respectivas tarefas de Cadastrar Cliente presentes nas áreas limites desses atores são conectadas ao relacionamento de dependência do tipo objetivo, denominado Cadastro de Cliente Criado. Cada atividade possui objetivos que precisam estar representados no modelo i*. Para as atividades que possuem mais de dois atores, tais objetivos estão presentes nos relacionamentos de dependências estratégicas entre os atores criados a partir da Diretriz 2. No entanto, existem atividades que estão associadas a apenas um ator. Nestes casos, aplica-se a Diretriz 5, descrita a seguir. Diretriz 5 Mapeando os objetivos das atividades individuais no modelo de atividades: para cada atividade individual, gera-se um objetivo na área do ator responsável por ela, cujo nome é o mesmo dado ao objetivo da atividade. Ligações meio-fim são então inseridas para associar as tarefas que representam as atividades individuais aos seus objetivos. Caso o critério de avaliação da conclusão deste objetivo seja subjetivo, gera-se uma dependência de objetivo-soft, caso contrário gera-se uma dependência do tipo objetivo. Diretriz 6 Mapeando ações associadas a cada atividade: as ações de um ator X em uma atividade A, são mapeadas em sub-tarefas (ligações de decomposição) da tarefa que representa a atividade A. Em caso de atividades com dois ou mais atores, deve-se alocar na área limite de cada ator apenas as tarefas que representam ações de sua responsabilidade. O nome dado a cada sub-tarefa é o mesmo dado às ações no modelo de atividades. Analisando a divisão de trabalho e as ações da atividade Cadastrar Cliente no Quadro 1, verifica-se a existência da ação do Cliente de Fornecer Informações Pessoais, a ação do Funcionário de Obter Informações Pessoais, e as ações do sistema Inserir e Gravar Informações Pessoais. Para gerar o modelo organizacional da Fig. 5, as ações de cada ator são mapeadas em sub-tarefas da tarefa Cadastrar Cliente presentes na área limite de cada ator correspondente. Diretriz 7 Mapeando sub-ações e operações: as subações e operações de uma ação A são mapeadas em subtarefas da tarefa que representa a ação A, através de ligações de decomposição. Na descrição das atividades da Clínica Veterinária as ações não estão subdivididas em sub-ações. Portanto, esta diretriz não se aplica. Diretriz 8 Transferência de recursos entre ações: quando uma ação A do ator X gera um recurso necessário para a realização de uma ação B do ator Y de uma mesma atividade, gera-se no modelo organizacional uma dependência de recurso entre as tarefas representando as ações A e B (B recurso A). No entanto, caso X e Y correspondam ao mesmo ator, gerase uma relação de meio-fim entre a tarefa que representa B e a tarefa que representa A. Observando a Fig. 5, por exemplo, o recurso Informações Pessoais surgiu da especificação da transferência deste recurso da ação Fornecer Informações Pessoais do Cliente para a ação do Funcionário de Obter Informações Pessoais. Da mesma forma, a ação Inserir Informações Pessoais do ator Sistema depende da transferência do recurso Registro de Informações Pessoais da ação Obter Informações Pessoais do ator Funcionário. Diretriz 9 Mapeando as motivações para a realização das atividades: cada motivação presente nas descrições das atividades e das ações do modelo de atividades é mapeada para objetivos-soft no contexto da modelagem i*. Os novos objetivos-soft são associados às tarefas representando as atividades ou ações que são afetadas pelas respectivas motivações. O local correto no qual estes objetivos-soft devem ser inseridos no modelo i* são definidos pela sub-diretriz 9.1. Como as motivações associadas às atividades são também conectadas às ações individuais, uma análise adicional também deve ser realizada (sub-diretriz 9.2) para evitar uma explosão de relacionamentos no modelo i*. Sub-diretriz 9.1 Associando motivações no modelo SR: quando para a realização de uma determinada motivação o ator A depende de uma atividade ou ação a ser realizada por um ator B, então a motivação é mapeada em um relacionamento de dependência de A (Depender) Este para B (Dependee) (A Motivação B). relacionamento de dependência permanece associado, na área de delimitação dos atores envolvidos, com as tarefas representando as atividades ou ações. Caso contrário, a motivação é inserida como objetivo-soft dentro da área de delimitação do ator que possui a respectiva motivação. Neste caso, relações de contribuição positiva são colocadas das atividades e ações norteadas pelas motivações para os recém criados objetivos-soft. Sub-diretriz 9.2 Analisando as motivações associadas às

8 TEIXEIRA et al.: INTEGRATING ACTIVITY THEORY 1651 Figura 5. Modelo de Razão Estratégica da Clínica Veterinária. ações: caso uma mesma motivação de um sujeito A esteja associada a várias ações deste sujeito, então apenas um objetivo-soft é gerado. Como exemplo, pode-se citar a motivação associada ao Funcionário que é Organização. Realizando a tarefa Cadastrar Cliente, o Funcionário estará contribuindo para a Organização. Essa motivação foi mapeada como um objetivo-soft dentro da área delimitada pelo ator Funcionário e recebe uma contribuição positiva da tarefa Cadastrar Cliente. Diretriz 10 Representando aspectos não-funcionais qualitativos: caso sejam detectadas nos dados restrições não-funcionais, classificadas pela norma ISO-9126 e/ou proposta em [4], associadas a uma motivação, atividade ou ação, tais restrições são representadas no modelo SR observando uma das diretrizes abaixo. Sub-diretriz 10.1 Mapeando uma restrição associada a uma motivação: caso seja uma restrição a uma motivação, então o objetivo-soft que representa a motivação (gerado na Diretriz 9) passará a possuir um complemento no próprio nome do objetivo-soft indicando a restrição extra. Sendo assim: (nome=nome_motivo+complemento_não_funcional). Sub-diretriz 10.2 Mapeando uma restrição associada a uma atividade ou ação: caso seja uma restrição associada a uma atividade ou ação, cria-se um objetivo-soft representando esta restrição como um sub-elemento (relação de decomposição) da tarefa que representa o atividade ou ação. Por exemplo, a atividade Recolher Animal associada ao Funcionário tem a restrição de Atenção Especial. Desta forma, esta restrição é mapeada para um objetivo-soft que será modelado como uma decomposição da tarefa Recolher Animal no modelo SR. Diretriz 11 Analisando as contribuições e conflitos presentes no modelo SR gerado: caso algum elemento i* modelado contribua (negativamente ou positivamente) para que determinado objetivo-soft seja satisfeito, criamse relacionamentos do tipo meio-fim (tradução do inglês means-end link) entre o elemento que contribui e o objetivo-soft que recebe a contribuição. V. CONSIDERAÇÕES FINAIS Neste trabalho foi apresentada uma proposta de melhoria da construção de modelos organizacionais em i* a partir de modelos de atividades. A diferença desta proposta em relação à proposta apresentada em [10] é que o foco do novo mapeamento está nas dependências geradas em relação ao sistema computacional pretendido. Para esta finalidade é necessário realizar uma análise adicional, a qual é apresentada na forma de diretrizes no presente trabalho. Isto implica em afirmar que os benefícios da modelagem utilizando a Teoria da Atividade são agora percebidos nos modelos organizacionais i* que consideram as intencionalidades associadas ao sistema computacional que será desenvolvido. Assim, engenheiros de requisitos podem construir modelos i* para a fase de Requisitos Detalhados de forma assistida e fazendo uso dos benefícios oriundos de ambas as técnicas, i* e Teoria da Atividade. Cabe ressaltar também que somente utilizando a presente proposta é possível, a partir dos modelos i*, gerar Casos de Uso ou Diagramas de Classe, conforme proposto em [1], [12], respectivamente. Considera-se que técnicas que auxiliam engenheiros de software precisam estar ajustadas a realidade do desenvolvimento de software hoje, na qual os artefatos gerados devem efetivamente considerar as necessidades dos usuários em relação a sistemas computacionais e apoiar este processo de elicitação, análise, negociação e documentação. Entre os trabalhos relacionados pode-se citar o trabalho desenvolvido por Cruz Neto [4], o qual propõe derivar modelos i* a partir de modelos de atividades com foco na fase de requisitos iniciais, e o trabalho de Grau [7], o qual propõe um método em i* para a perspectiva da reengenharia. Este

9 1652 método é composto por seis fases. Dentre essas seis fases cabe ressaltar a primeira, onde o processo atual é analisado e um modelo descritivo é gerado, e a segunda, onde o modelo i* é construído através de um conjunto de diretrizes para essa finalidade. Como trabalhos futuros, pretende-se aplicar a presente proposta a outros estudos de caso utilizando princípios da engenharia de software experimental bem como realizar a passagem do diagrama das atividades atuais do ambiente para o diagrama das atividades propostas como solução. Também pretende-se elaborar algum suporte computacional para apoiar a utilização das diretrizes propostas, bem como integrar a presente proposta ao trabalho proposto em [12]. REFERÊNCIAS [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] F. M. R. Alencar, Mapeamento e modelagem organizacional em especificações precisas, Tese de Doutorado, Universidade Federal de Pernambuco - Centro de Informática, Recife, PE, Brasil, J. A. Bubenko, On Concepts and Strategies for Requirements and Information Analysis, In Information Modelling, pp Chartwell-Bratt, M. Chichinelli, Contribuição da Técnica de Modelagem Organizacional I* ao Processo de Engenharia de Requisitos, com destaque aos Requisitos Não Funcionais, Dissertação de Mestrado, Universidade de São Paulo Escola de Engenharia de São Carlos, São Carlos, SP, Brasil, L. K. Chung, B. A. Nixon, E. Yu, J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 472 p., G. G. Cruz Neto, Estudos qualitativos para elicitação de requisitos: uma abordagem que integra análise sócio-cultural e modelagem organizacional, Tese de Doutorado, Universidade Federal de Pernambuco Departamento de Informática, Recife, PE, Brasil, A. Dardene, A. Van Lamsweerde, S. Fickas, Goal Directed Requirements Acquisition. In: Selected papers of the sixth international workshop on software specification and design, Amsterdam, The Netherlands: Science of Computer Programming, vol. 20, pp. 3-50, Apr., Y. Engestrom, Learning by Expanding, Helsinki: Orienta-Konsultit, G. Grau, An i*-based Reenginering Framework for Requirements Engineering, PhD Thesis, Universitat Politècnica de Catalunya, Departament de Llenguatges I Sistemes Informàtics for the Degree of Doctor of Philosophy, V. Kaptelinink andb. A. Nardi, Acting with Technology: Activity Theory and Interaction Design, MIT Press, A. N. Leont Ev, The Problem of Activity in Psychology, J. Werstch (Ed.): The concept of Activity in Soviet Psychology, Armonk, New York: M. E. Sharpe, inc, B. A. Nardi, Context and Consciousness: Activity Theory and HumanComputer Interaction, London: MIT Press, J. F. B. Castro, F. M. R. Alencar, V.F.A. Santander, C. T. L., Lourenco, Integration of i * and Object-Oriented Models (January, 2011) In: Social Modeling for Requirements Engineering. E. Yu, P. Giorgini, N. Maiden, J. Mylopoulos (eds). Cambridge, MA : MIT Press, v.1, p , I. G. L. Silva, Projeto e Implementação de Sistemas Multi-Agentes: O caso Tropos, Dissertação de Mestrado, Universidade Federal de Pernambuco Centro de Informática, Recife, PE, Brasil, E. Yu, Modelling Strategic Relationships for Process Reengineering, Phd Thesis, University of Toronto, A. R. Luria, The Historical Development of Cognitive Processes, Moscow: Nauka Publishers, Eliana Paula Teixeira graduou-se em Ciência da Computação pela Universidade Estadual do Oeste do Paraná UNIOESTE. Realizou sua monografia na área de Engenharia de Requisitos, com foco nos diagramas i* e usando benefícios da Teoria da Atividade. Publicou um artigo para um evento da área. Atualmente trabalha com Testes de Software. Estuda formas de realizar testes cada vez mais completos e consistentes. Victor Francisco Araya Santander graduou-se em Ciência da Computação pela Universidade Estadual de Maringá (1994), obteve o título de mestre em Ciências da Computação e Matemática Computacional pela Universidade de São Paulo (1997), doutorou-se em Ciências da Computação pela Universidade Federal de Pernambuco (2002), realizou pósdoutorado pela Universidade de Talca, Chile ( ) e pós-doutorado pela Universidad Politécnica de Valencia, Espanha ( ). Atualmente é professor associado da Universidade Estadual do Oeste do Paraná. Suas pesquisas se concentram na área de engenharia de software e engenharia de requisitos. Fernando Luiz Grando graduou-se em Ciência da Computação pela Universidade Estadual do Oeste do Paraná UNIOESTE. Realizou sua monografia de conclusão de curso na área de Engenharia de Requisitos, tendo como foco a Modelagem Organizacional no contexto de desenvolvimento de sistemas computacionais. Atualmente trabalha na área de Testes e Qualidade de Software.