Avaliando a utilização da Ferramenta JGOOSE no Processo de Ensino e Aprendizagem na Engenharia de Requisitos Um Relato de Experiência

Transcrição

1 Avaliando a utilização da Ferramenta JGOOSE no Processo de Ensino e Aprendizagem na Engenharia de Requisitos Um Relato de Experiência Victor Francisco Araya Santander, Ivonei Freitas da Silva Universidade Estadual do Oeste do Paraná (UNIOESTE) Rua Universitária 2069, Cascavel - PR Brazil victor.santander@unioeste.br, ivonei.silva@unioeste.br ABSTRACT This paper presents an experience report using the JGOOSE (Java Goal Into Object Oriented Standard Extension) tool on the teaching and learning of organizational modeling and requirements engineering in software engineering course for undergraduate students in computer science. Considering the questionnaire answers applied to the students and the lessons learned from the software engineering course lecturer, the JGOOSE provided useful artifacts to the following steps of the software engineering process. As a consequence, the students were motivated with the tool. Keywords i* Framework, Use Cases, Requirements Engineering. 1. Introdução Os esforços na formação de estudantes de graduação na área da computação devem ser direcionados para o uso de técnicas e ferramentas que permitam aumentar a eficiência no trabalho realizado. Neste sentido, um dos esforços iniciais na formação é a utilização de técnicas para modelagem organizacional com o intuito de compreender o contexto organizacional no qual um sistema computacional deverá atuar. Em [6] apresenta-se um relato de experiência de uso da técnica de modelagem organizacional i* no contexto do processo de ensino e aprendizagem na engenharia de requisitos. Nesse relato, são apresentadas algumas lições aprendidas a partir do uso dessa técnica durante oito anos em disciplinas de engenharia de software em um curso de graduação em Ciência da Computação. O relato mostra que uma das dificuldades percebidas está associada à necessidade de integrar modelos organizacionais com modelos funcionais orientados a objetos. Acadêmicos e profissionais da área da computação almejam integrar modelos organizacionais e modelos funcionais no processo de engenharia de software buscando reduzir ambiguidades e centrar esforços em objetivos estratégicos que devem ser suportados por sistemas computacionais pretendidos. Este processo de integração, para ser realizado em menos tempo e com mais eficiência, deve possuir algum suporte computacional. Assim, considerando inicialmente o relato prévio apresentado em [6], apresenta-se neste trabalho as lições aprendidas com o uso da ferramenta JGOOSE (Java Goal Into Object Oriented Standard Extension) [9] que deriva casos de uso em UML [3] a partir de modelos em i* [8]. Estas lições consideram como base a utilização da ferramenta por 45 alunos divididos em 15 equipes em uma disciplina de engenharia de software. O restante deste artigo está estruturado conforme segue. Na seção 2 apresenta-se um breve relato do framework i* e da técnica de casos de uso, cuja integração é suportada pela ferramenta JGOOSE. Na seção 3 é apresentada a ferramenta JGOOSE e na seção 4 é realizado o relato de experiência bem como as lições aprendidas. Na seção 5 são realizadas as considerações finais do trabalho. 2. Framework i* e Casos de Uso UML O framework i* proposto por Eric Yu [8] permite descrever aspectos de intencionalidade e motivações envolvendo atores em um ambiente organizacional. Para descrever estes aspectos são propostos dois modelos: O Modelo de Dependências Estratégicas (SD) e o Modelo de Razões Estratégicas (SR). O Modelo SD é composto por nós e ligações. Os nós representam os atores no ambiente e as ligações são as dependências entre os atores. Por ator entende-se 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 alguma forma de outro ator é chamado de Depender e o ator que atende e satisfaz o Depender é 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 [8 ]. O modelo de SR é complementar ao modelo de SD. O SR permite compreender e modelar de forma mais detalhada as razões associadas com cada ator e suas dependências. Enquanto o modelo de SD provê um nível de abstração, no qual modela-se somente os relacionamentos externos entre atores, o modelo de SR permite uma maior compreensão a respeito das razões estratégicas de atores em relação aos processos da organização e como os mesmos são expressos. O modelo de SR auxilia no processo de Engenharia de Requisitos permitindo que elementos de processos e as razões por detrás dos mesmos sejam expressos. Para um melhor entendimento da técnica, na figura 1 apresenta-se um exemplo de modelo SR para uma organização que deseja obter um sistema computacional que apoie seu processo de compra e venda. Nesta figura podemos observar que a satisfação do objetivo Consultar Produtos pelo ator Sistema é obtida através dos objetivos Buscar Produtos e Mostrar Produtos, os quais estão representados via mecanismo de decomposição de tarefas. A busca ainda pode ser feita de duas formas, Via Mecanismo de Pesquisa e Via Browser demonstrados pelas 531

2 ligações meio-fim, nas quais, Via Browser, e Via Mecanismo de Pesquisa representam meios para obter o fim de Buscar Produtos. Da mesma forma, o objetivo Mostrar Produtos possui dois meios para ser alcançado, os quais são Via Impressão e Via Tela. Já a satisfação do objetivo Efetuar Venda, representado internamente no ator Sistema pela tarefa de mesmo nome, é levada a cabo pela realização das tarefas Consultar Produtos, Selecionar Produto, Dar Baixa do Produto e Emitir Nota Fiscal. Cabe destacar que esta última tarefa pode ser realizada de forma independente para satisfazer o objetivo Emitir Nota Fiscal para o ator Funcionário. 3. A Ferramenta JGOOSE A ferramenta JGOOSE permite, a partir de modelos organizacionais gerados via framework i* [8], gerar diagramas de casos de uso e descrições dos cenários primário e secundário dos mesmos. Inicialmente devem ser criados os modelos organizacionais utilizando a ferramenta OME3 formato Telos (.tel) [11], sendo que estes arquivos servirão de entrada para a ferramenta JGOOSE. A figura 2 mostra a tela inicial da ferramenta na qual o engenheiro de requisitos deve selecionar o arquivo Telos a ser utilizado como entrada e, posteriormente, selecionar qual ator do modelo organizacional representa o sistema computacional pretendido pela organização. Figura 2. Tela Inicial da Ferramenta JGOOSE Figura 1. Exemplo de Modelo de Razões Estratégicas (SR) O bom entendimento dos aspectos organizacionais através dos modelos produzidos pelo framework i* pode auxiliar na construção de um software que atenda as reais necessidades para as quais ele foi proposto. No entanto, é importante transformar essa representação de modelos organizacionais em implementação do sistema. Para apoiar essa transformação pode-se adotar a UML (Unified Modeling Language). Existem diversos diagramas e descrições em UML que auxiliam no desenvolvimento de um software, entre os quais podemos destacar os casos de uso. Os casos de uso podem ser expressos em forma de texto, permitindo representar as ações que devem ser realizadas entre o usuário e o sistema para levar a cabo o objetivo associado ao caso de uso. Isto permite uma melhor compreensão do caso de uso por todos os envolvidos. Um template de descrição textual dos casos de uso bastante utilizado é proposto por Cockburn [2]. Juntamente com esta descrição textual, representase casos de uso através de diagramas. Uma referência completa para diagramas de casos de uso pode ser encontrada em [3]. Visando integrar o framework i* com casos de uso UML, é apresentando em [5] um conjunto de diretrizes que apoiam esta integração. A última versão destas diretrizes bem como outros trabalhos relacionados ao uso de i* na Engenharia de Requisitos podem ser consultados em [8]. Na figura 3 é apresentada a tela de seleção das diretrizes a serem utilizadas no mapeamento dos casos de uso tendo como base os modelos em i*. Esta tela é mostrada logo após selecionar o ator sistema e acionar o botão Selecionar Diretrizes na figura 2. A figura 4 apresenta a tela com os casos de uso gerados bem como a descrição textual associada a cada caso de uso. Esta tela é gerada após o usuário acionar o botão Mapear Objetos i* -> Diagrama de Casos de Uso UML. Figura 3. Seleção das Diretrizes de Mapeamento 532

3 Os alunos possuíam prévio conhecimento da técnica de casos de uso tanto em nível de descrição textual quanto diagramática bem como sobre o framework i*, incluindo os modelos SD e SR. 4.2 Objetivo O objetivo principal deste estudo foi avaliar o uso da ferramenta JGOOSE no que se refere a sua viabilidade em gerar o diagrama de casos de uso e as descrições textuais associadas a partir dos modelos organizacionais SD e SR, bem como, importar os diagramas gerados no formato xmi usando a ferramenta de modelagem orientada a objetos StarUml [12]. Essa avaliação foi baseada no ponto de vista dos estudantes de graduação através de um questionário adotado e na interpretação do docente da disciplina. A síntese das respostas dos estudantes e a interpretação do docente da disciplina são apresentadas na Seção 4.4, Resultados e lições aprendidas, respectivamente. Figura 4. Tela de Casos de Uso Gerados Figura 5. Diagrama de Casos de Uso Gerado A figura 5 apresenta a tela da ferramenta na qual é apresentado o diagrama de casos de uso correspondente ao arquivo Telos sendo mapeado. Cabe ressaltar que o diagrama gerado foi derivado do modelo i* apresentado na figura 1. Este diagrama pode ser exportado para o formato xmi possibilitando o uso do diagrama em outras ferramentas que apoiam a engenharia de software. Uma descrição completa da ferramenta pode ser consultada em [10]. As diretrizes utilizadas para o mapeamento podem ser consultadas em [5]. Em [8] apresenta-se em detalhes o framework de modelagem organizacional i*. 4. Relato de Experiência 4.1 Contexto Este estudo foi avaliado durante uma disciplina de graduação em Ciência da Computação denominada de Processo de Engenharia de Software II. A disciplina é integralizada em 136 horas-aula anuais, sendo 102 h/a teóricas e 34 h/a práticas no 4º ano (correspondente ao oitavo período em cursos semestrais). 4.3 Condução da avaliação Durante a disciplina, os alunos desenvolveram um projeto prático. Este projeto consistiu no desenvolvimento de uma solução computacional para um cliente real. Assim, os mesmos deveriam interagir com um cliente já no início da disciplina e desenvolver uma solução computacional passando por todas as etapas do processo de engenharia de software. O projeto consistiu de três etapas principais: estudo de viabilidade, especificação de requisitos e análise orientada a objetos bem como projeto, implementação e testes do produto final. Cada uma destas etapas macro foram realizadas em várias iterações e o resultado final entregue na forma de um documento seguindo um template fornecido pelo professor. As entregas, agendadas para o final do 1º, 2º e 4º bimestres respectivamente, resultaram na aplicação dos conceitos vistos em sala de aula e interação com o cliente real para mostrar o progresso do trabalho. Este relato concentra-se nas atividades realizadas na segunda etapa, ou seja, as atividades típicas do processo de engenharia de requisitos. Mais especificamente, o estudo cobre a construção de modelos organizacionais via framework i* e a derivação de casos de uso a partir destes modelos usando a ferramenta JGOOSE. Esse estudo gastou 08 horas no total para a execução dessas duas atividades. Em um primeiro momento, os alunos desenvolveram os modelos organizacionais SD e SR [8] do framework i* visando obter um entendimento do contexto organizacional no qual a solução computacional operaria bem como explorar as principais metas dos atores organizacionais em relação ao sistema computacional pretendido. A construção destes modelos foi realizada em 4h/a práticas antes do uso da ferramenta JGOOSE. Na aula subsequente da disciplina, em 4h/a práticas, a ferramenta JGOOSE foi utilizada e o questionário respondido pelas equipes dos projetos. Inicialmente o docente fez uma breve explanação das funcionalidades da ferramenta computacional a ser utilizada e em seguida os alunos passaram a utilizá-la. Dúvidas específicas em relação à ferramenta, sobre os modelos organizacionais criados bem como sobre a técnica de casos de uso, foram sendo sanadas ao longo da primeira aula prática. Os alunos foram instruídos a salvar as descrições textuais dos casos de uso gerados no formato.doc para posterior integração ao documento de requisitos final do projeto. 533

4 Os alunos geraram o diagrama de casos de uso e as descrições textuais associadas a partir dos modelos organizacionais SD e SR, bem como, importaram os diagramas gerados no formato xmi usando a ferramenta StarUml [12] de modelagem orientada a objetos. Ao final, os alunos responderam o questionário sem interferência do docente sendo que do total de 15 equipes, 13 (86,7%) responderam o questionário e 2 (13,3%) equipes não o fizeram por estarem ausentes no dia da aula prática. 4.4 Resultados e lições aprendidas Seguem abaixo as questões do questionário aplicado, com uma breve síntese das respostas coletadas. Também na sequência de cada questão são descritas as lições aprendidas sob a perspectiva direta e subjetiva do docente da disciplina. Q1a - Você considera que os casos de uso gerados realmente são os principais para o sistema em questão? Justifique sua resposta? Síntese das respostas obtidas: do total de 13 equipes, 10 (77%) responderam que a ferramenta gerou os principais casos de uso do sistema. Três equipes (23%) apontaram que consideravam que nem todos os casos de uso essenciais foram gerados. Lições aprendidas: O objetivo da pergunta era coletar dos alunos suas impressões sobre a utilidade da ferramenta em gerar automaticamente, a partir dos modelos organizacionais, os principais casos de uso a serem implementados. Sob a ótica da maioria dos alunos, a ferramenta permitiu gerar os principais casos de uso do sistema. Aqueles que responderam que nem todos os casos de uso principais foram gerados, justificaram sua resposta apontando a existência de outros casos de uso importantes. Estes casos de uso não estavam explicitamente representados por objetivos ou tarefas nos modelos organizacionais e por isso não foram gerados. Desta forma, sob a ótica do docente parece bastante óbvio que modelos organizacionais mais completos geram uma maior quantidade de casos de uso importantes para o sistema. Entretanto, o fato de não gerar os principais casos de uso apontado por três equipes, trás a tona algo positivo que recai na análise realizada pelos alunos agora sob a perspectiva direta de descoberta de importantes casos de uso que não foram expressos nos modelos organizacionais i*. Nesse sentido, como o princípio de desenvolvimento iterativo e incremental foi adotado, os alunos puderam modificar os modelos SD e SR para incluir novas metas ou tarefas essenciais visando gerar esses novos casos de uso para o sistema pretendido. Cabe salientar que ao final do processo de utilização da ferramenta JGOOSE, os alunos geraram um documento base para a descrição de requisitos e que em um processo de análise, novos casos de uso e requisitos acabaram sendo agregados ao documento final. Isto implica em afirmar que o uso da ferramenta permitiu gerar uma base que deveria ser melhorada ao longo do processo de engenharia de requisitos. Q1b - Os casos de uso gerados são consistentes, fazem sentido? Justifique sua resposta. Síntese das respostas obtidas: do total de 13 equipes, 7 (54%) responderam que os casos de uso gerados eram consistentes tanto na parte diagramática quanto na descrição textual derivada e representavam de fato o que o sistema deveria satisfazer na sua essência. Seis equipes (46%) apontaram alguns problemas. Três equipes responderam que a descrição textual dos cenários dos casos de uso estava inconsistente, devido a que os modelos organizacionais utilizados estavam incorretos e/ou não detalhados suficientemente. As outras três equipes apontaram que nem todos os elementos do template de descrição textual dos casos de uso eram gerados automaticamente e/ou que os casos de uso gerados eram muito genéricos e precisavam ser refinados. Lições aprendidas: O objetivo da pergunta era verificar junto aos alunos se os diagramas e descrições textuais de casos de uso faziam sentido no contexto do sistema que deveria ser implementado. Observando as respostas dos alunos, verificou-se que a maioria considerou que os modelos organizacionais construídos permitiram gerar casos de uso consistentes com o que se espera do sistema e que os casos de incoerência estavam associados à falta ou incorretude das informações modeladas no SD ou SR. Contudo, alguns alunos perceberam que algumas metas que originaram casos de uso estavam em um nível muito alto de abstração e precisavam ser refinadas para dar uma ideia mais clara e que fosse mais consistente com a definição de um caso de uso. Neste aspecto, como a proposta do uso da ferramenta JGOOSE é dar uma base para posterior refinamento dos casos de uso, permitiu-se que estes alunos pudessem refinar os casos de uso muito genéricos nas etapas subsequentes do processo de engenharia de requisitos. Q1c - Como você procederia a busca de outros casos de uso importantes para o sistema? Por que eles não foram gerados pela ferramenta? Síntese das respostas obtidas: do total de 13 equipes, 3 (23%) responderam que todos os casos de uso foram gerados pela ferramenta, 1 (0,7%) equipe não soube responder apesar de considerar que existiam outros casos de uso importantes e as outras 9 (70%) equipes apontaram diversos caminhos para descobrir outros casos de uso tais como realizar mais contatos com o cliente/usuário do sistema pretendido, revisar e explorar com mais profundidade os modelos organizacionais construídos, investigando outras relações entre atores que poderiam gerar novos casos de uso, refinar os casos de uso gerados pela ferramenta, explorar funcionalidades mais simples a serem oferecidas pelo sistema independentemente de estarem descritas nos modelos organizacionais e explorar as descrições textuais visando detectar outros casos de uso. No que tange ao porque alguns casos de uso importantes não foram gerados pela ferramenta, 6 (46%) equipes não responderam e as outras 7 (54%) apontaram que os modelos organizacionais não continham todas as informações para gerar todos os casos de uso e/ou que é natural que seja realizada uma análise adicional para encontrar novos casos de uso. Lições aprendidas: O objetivo da pergunta era instigar nos alunos a necessidade de realizar análises complementares para, com base no mapeamento realizado pela ferramenta JGOOSE, explorar outros casos de uso para o sistema pretendido. Assim, detectou-se que a maioria conseguiu visualizar outros casos de uso utilizando vários meios. A lição mais importante sob a perspectiva do docente da disciplina é que maioria das equipes percebeu que o mapeamento realizado era somente o ponto de partida para a descrição dos casos de uso e o processo de descoberta é inerentemente iterativo e incremental. Nesta direção, é importante ressaltar que todos os alunos utilizaram os diagramas de casos de uso em formato xmi gerados pela ferramenta JGOOSE, sendo que a maioria alterou estes diagramas de forma manual usando a 534

5 ferramenta StarUML, a qual foi utilizada para importar os diagramas gerados. Assim, novos casos de uso foram descobertos a partir da base gerada. Entretanto, após estas mudanças, os modelos organizacionais passaram a não ser mais consistentes com a versão final modificada dos casos de uso do sistema. Uma das alternativas seria que a ferramenta JGOOSE permitisse fazer o caminho inverso, atualizando os modelos organizacionais a partir dos casos de uso gerados. Infelizmente, isto ainda não é suportado pela ferramenta. Q1d - Os cenários principal e secundário dos casos de uso gerados automaticamente pela ferramenta são úteis, fazem sentido? Eles precisam ser modificados/complementados? Justifique sua resposta. Síntese das respostas obtidas: do total de 13 equipes, 4 (31%) responderam que a geração textual não era útil pois a ferramenta só gerou o template ou informações parciais. Neste contexto, verificou-se que a ferramenta de fato apresentava um bug e que não mapeava determinados subelementos para passos nos cenários. Isto ocorria quando ligações do tipo meio-fim eram definidas já em um primeiro nível de detalhamento da tarefa que satisfazia uma dependência externa. Este é um aspecto importante que está sendo corrigido na ferramenta. Já para as demais 9 (69%) equipes, os cenários gerados foram úteis e inconsistências nesses cenários foram atribuídas a problemas na descrição dos modelos SR. Contudo todas as equipes apontaram a necessidade de modificar e complementar as descrições textuais para representar todos os detalhes necessários conforme exigido para casos de uso [2]. Lições aprendidas: O objetivo da pergunta era averiguar se a geração automática de descrições textuais de casos de uso era útil e se, com base no conhecimento prévio sobre a técnica de casos de uso, modificações/complementações eram necessárias. Nesse sentido, a maioria das equipes apontou aspectos positivos associados a descrição obtida bem como mostrou um nível de conhecimento razoável que permitiu-lhes afirmar a necessidade de melhorar as descrições dos casos de uso observando a implementação futura dos mesmos. Cabe ressaltar que após o uso da ferramenta, o docente da disciplina reforçou a necessidade de melhorar as descrições textuais dos casos de uso que deveriam integrar o documento de requisitos final. Q1e - O fato de poder modificar e salvar as descrições textuais dos casos de uso facilita o teu trabalho? Como? Síntese das respostas obtidas: Todas as 13 equipes que responderam o questionário afirmaram que esta funcionalidade da ferramenta facilita o trabalho do engenheiro de requisitos. Entre as vantagens apontadas estão a padronização já permitida pelo template textual gerado pela ferramenta, a possibilidade de utilizar o arquivo gerado em outros editores de texto e a diminuição de tempo para criar e editar os casos de uso. Por outro lado, os alunos também expressaram a necessidade de agrupar manualmente todas as descrições textuais geradas pela ferramenta, já que a mesma permite apenas gerar um arquivo.doc para cada descrição textual de um caso de uso e ressaltaram a inconsistência propagada para as descrições textuais caso os modelos em i* estivessem inconsistentes. Também apontaram a necessidade inevitável de fazer alterações nas descrições textuais de forma a descrever adequadamente os casos de uso seguindo o template proposto. Lições aprendidas: O objetivo da pergunta era obter junto aos alunos a sua percepção quanto a essa funcionalidade apresentada pela ferramenta. Neste sentido, verificou-se que todos visualizaram as vantagens dessa funcionalidade, mas também ficou evidente a necessidade de melhorar a ferramenta, adicionando, por exemplo, um editor de textos mais completo. Também os acadêmicos verificaram que as descrições textuais geradas nem sempre correspondiam a todos os passos no cenário principal, bem como a todas as extensões (erros e alternativas) que deveriam ser considerados nos casos de uso. Isso promoveu a reflexão nos alunos sobre as correções necessárias nas tarefas e metas expressas nos modelos organizacionais bem como na necessidade de aprofundar e melhorar a descrição textual em um nível adequado para casos de uso. Contudo, a proposta do uso da ferramenta JGOOSE é criar uma base essencial de atividades nos cenários principal e secundário e evoluir desta base para uma descrição textual completa dos casos de uso. Este é um trabalho de análise imprescindível. Q1f - O fato de poder exportar o diagrama de casos de uso para o formato.xmi facilita o teu trabalho de analista? Por quê? Síntese das respostas obtidas: 12 (92%) equipes responderam positivamente esta questão argumentando que esta funcionalidade possibilita diminuir o tempo de construção dos diagramas de casos de uso bem como a utilização em outras ferramentas de apoio a modelagem orientada a objetos. Estas equipes utilizaram a ferramenta opensouce StarUml para importar os arquivos gerados pela ferramenta JGOOSE. Uma das equipes não soube responder a pergunta. Lições aprendidas: O objetivo da pergunta era obter junto aos alunos a percepção quanto a possibilidade de importar os diagramas gerados e possibilidade de evoluir no projeto da disciplina usando outras ferramentas de modelagem orientada a objetos. Assim, a maioria dos mesmos apontou como favorável essa importação reforçando a ideia de tornar mais ágil o processo de desenvolvimento e aproveitar o trabalho de fases anteriores ao longo do processo. Na visão dos alunos a maior vantagem está em construir modelos organizacionais e utilizar estes modelos para gerar automaticamente casos de uso passíveis de serem utilizados em outras ferramentas da engenharia de software. Q2 - Em sua opinião, quais são as vantagens/desvantagens em derivar casos de uso neste momento e desta forma no processo de desenvolvimento de software? Síntese das respostas obtidas: Todas as 13 equipes apontaram que a principal vantagem percebida no processo é que o trabalho necessário para gerar os modelos organizacionais é compensado pela redução de tempo na geração automática dos casos de uso, mesmo com a necessidade de complementar/melhorar as descrições geradas. Contudo, três equipes manifestaram a preocupação em dedicar mais tempo para a construção dos modelos organizacionais para gerar casos de uso mais completos. Lições aprendidas: O objetivo da pergunta era coletar as percepções dos alunos quanto ao uso da ferramenta e por consequência do processo adotado pela mesma. Pelas respostas obtidas foi possível perceber uma boa aceitação do uso da ferramenta e processo. Entretanto, é difícil estimar se as respostas seriam as mesmas em um novo projeto aplicando o questionário antes de iniciar a construção dos modelos organizacionais em i*. Q3 - Quais são os problemas, sugestões de melhoria que você apontaria em relação a ferramenta JGOOSE? 535

6 Síntese das respostas obtidas: Todas as 13 equipes apontaram melhorias necessárias na ferramenta. Entre as melhorias sugeridas estão: melhoria da interface deixando-a mais intuitiva, organizar os casos de uso por ator, permitir editar e modificar os diagramas de casos de uso gerados dentro da própria ferramenta, disponibilizar mais conteúdo de ajuda nas ações da ferramenta, corrigir os erros apontados na questão 1d, permitir salvar tantos os diagramas gerados quanto as descrições textuais em um único arquivo, entre outros. Lições aprendidas: Foi possível perceber claramente que a maioria das melhorias sugeridas pelos alunos são pertinentes e devem ser incluídas em uma próxima versão da ferramenta 5. Considerações Finais e Trabalhos Futuros Neste trabalho foram apresentadas algumas lições aprendidas fruto da experiência vivenciada pelos alunos e docente da disciplina de processo em engenharia de software II no contexto do uso da ferramenta JGOOSE [9]. A lição mais importante neste contexto recai na necessidade de estimular nos alunos a busca do conhecimento utilizando meios que facilitem este processo. Técnicas e ferramentas devem ser experimentadas e o docente deve ter claro quais são as contribuições do uso das mesmas na formação dos alunos. Especificamente em relação à ferramenta abordada neste artigo, verifica-se que a mesma permitiu apoiar o processo de geração de casos de uso em UML a partir de modelos em i*. Com base nas respostas obtidas sobre o questionário aplicado, pode-se perceber que os alunos sentiram-se motivados quando perceberam que um artefato resultante do trabalho de uma fase do processo de software, pode ser aproveitado para evoluir para outras etapas do processo. Também nota-se que os resultados gerados pela ferramenta foram considerados úteis pela maioria dos alunos. Por outro lado, também ficou evidente pelas respostas dos alunos, que a qualidade dos casos de uso gerados depende fortemente da completude e consistência dos modelos organizacionais construídos. Contudo, construir modelos i* de qualidade depende diretamente da experiência dos engenheiros de requisitos neste tipo de modelagem. Neste aspecto, cabe destacar que antes de realizar o estudo foram gastas 4h/a para explicar o framework i* e 4h/a para casos de uso UML. Este tempo foi restrito por ser necessário cobrir outros conteúdos na disciplina. Outro aspecto relevante está relacionado ao tempo dedicado à atividade. Não podemos aferir que se aumentássemos as horas do estudo além das 8h/a gastas, a avaliação da ferramenta seria melhor ou pior. Apesar de todas as equipes terem conseguido terminar as atividades no tempo previsto, talvez um tempo maior permitisse obter avaliações e resultados melhores e mais detalhados. Como trabalhos futuros pretende-se estender o estudo a outras turmas do curso de Ciência da Computação como também melhorar o questionário utilizado. Também pretende-se estender os estudos para equipes mais experientes na construção de modelos i* para então comparar com os resultados obtidos por equipes menos experientes. Para esses futuros estudos, gastar-seia mais horas no entendimento e uso do framework i*. É importante salientar que a ferramenta JGOOSE vem sofrendo melhorias e que uma nova versão diferente da utilizada no estudo relatado neste artigo está disponível em [9]. Entretanto, a essência da ferramenta não foi alterada e as melhorias realizadas na nova versão serão consideradas em outras avaliações. 6. Referências Bibliográficas [1] Brischke, M., Santander, V.F.A., Castro, J. F. B., GOOSE: Uma Ferramenta para Integrar Modelagem Organizacional e Modelagem Funcional In: Jornadas Chilenas de Computación - V Workshop Chileno de Ingeniería de Software, Valdivia, Chile. (2005). [2] Cockburn, A. Writing Effective Use Cases. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., [3] Jacobson, I., Object Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley (1992). [4] Kotonya, G., Sommerville, I.: Requirements Engineering: Processes and Techniques. John Wiley & Sons (1998). [5] Santander, V. F., Castro, J. F. B., Deriving Use Cases from Organizational Modeling In: IEEE Joint International Requirements Engineering Conference - RE 02, p , Essen, Germany, (2002). [6] Santander, Victor F. A. Avaliando a utilização da Técnica i* no Processo de Ensino e Aprendizagem na Engenharia de Requisitos - Um Relato de Experiência. In: IV Fórum de Educação em Engenharia de Software, Evento integrante do XXV Simpósio Brasileiro de Engenharia de Software (SBES), São Paulo, [7] Vicente, André A., Santander, Victor Francisco Araya, Castro, Jaelson B., Freitas da Silva, Ivonei., Reyes Matus, Francisco G., JGOOSE: A Requirements Enginnering Tool to Integrate i* Organizational Modeling with Use Cases in UML. Ingeniare. Revista chilena de ingeniería., v.17, p.6-20,(2009). [8] Yu, E., Giorgini, P., Maiden, N., Mylopoulos, J., Social Modeling for Requirements Engineering. The MIT Press (2011). [9] JGOOSE, Disponível em [10] Brischke, M., Santander, V.F.A., Melhorando a Ferramenta JGOOSE. In: 15th Workshop on Requirements Engineering (WER), Buenos Aires, Argentina (2012) [11] Mylopoulos, J. et al. Telos: Representing knowledge about information systems. ACM Transactions on Information Systems (TOIS), ACM, v. 8, n. 4, p , [12] StarUML. StarUML - The Open Source UML/MDA Platform. Consultado na Internet: em Agosto de