Apoio na Concepção de Workflow Científico Abstrato para Estudos in virtuo e in silico em Engenharia de Software

Transcrição

1 Apoio na Concepção de Workflow Científico Abstrato para Estudos in virtuo e in silico em Engenharia de Software Wallace M. Pereira 1, Marco Antônio P. Araújo 2, Guilherme H. Travassos 1 1 Programa de Engenharia de Sistemas e Computação (PESC), COPPE/UFRJ Universidade Federal do Rio de Janeiro, Brasil, Caixa Postal CEP Centro de Ensino Superior de Juiz de Fora / Faculdade Metodista Granbery {wpereira,ght}@cos.ufrj.br, maraujo@acessa.com Abstract. Science evolution has been supported by complex computerized infrastructures with growing interests in simulation based studies based on scientific workflows. However, the conception of such workflows is not easy and the current ad-hoc approaches make it a risky process. Therefore, this paper describes the application of an approach for the conception of scientific workflows for Software Engineering simulation based large scale studies in software decay. Resumo. A evolução da ciência tem sido apoiada por infra-estrutura computacional complexa para realizar as pesquisas, com crescente interesse em estudos baseados em utilizando tecnologias de workflow científico. Entretanto, a concepção de workflows não é trivial e as práticas correntes ad-hoc podem trazer riscos ao estudo. Por isto, este trabalho apresenta a aplicação de uma abordagem de apoio à concepção de workflow científicos para estudos larga escala baseados em em Engenharia de Software no domínio da Evolução de Software. 1. Introdução A Engenharia de Software (ES) vem utilizando a Experimentação como meio para a criação de um corpo de conhecimento. Para que apresente validade científica, cada um de seus itens de conhecimento deve ser verificado perante a realidade [Juristo & Moreno, 2001]. Essa verificação pode ser realizada através de estudos experimentais, que permitam ao pesquisador um maior controle da situação e a manipulação do comportamento do ambiente de forma direta, precisa e sistemática [Wohlin et al., 2000]. Diferentes tipos de estudos experimentais podem ser utilizados, contando com a participação de profissionais. Esses estudos visam observar a validade desses itens de conhecimento quando relacionada a seus possíveis comportamentos em processos de software e como podem afetar o produto gerado. Contudo, em situações onde o tempo necessário para observação do comportamento é longo, a utilização de profissionais pode não ser inicialmente viável, tornando a observação mais difícil, trazendo riscos de continuidade da pesquisa. Essas condições têm motivado o uso cada vez mais freqüente de estudos baseados em na Engenharia de Software Experimental [Zhang et. al., 2008]. Dentre as vantagens que podem ser obtidas, destacam-se: maior controle do ambiente, menor custo de pessoal e antecipação a possíveis riscos. Também, existe a possibilidade de observar, de forma restrita, a viabilidade das tecnologias de software sob investigação. Os estudos que fazem uso de ambientes simulados são denominados: in virtuo e in silico. Esses estudos permitem observar o mundo real através de 22

2 em ambientes virtuais, compostos por modelos computacionais. Nos estudos in silico tanto os participantes quanto o ambiente são simulados, ao contrário do s estudos in virtuo, onde o ambiente sofre interação dos participantes [Travassos & Barros, 2003]. A utilização de, embora com ênfase recente em Engenharia de Software, representa prática corrente em outras áreas da ciência como meio de realização de suas pesquisas (e.g., Biologia, Engenharia, Física, dentre outras) [Mattos et al., 2008]. Estas áreas fazem uso de tecnologias como workflow científico e Sistemas Gerenciadores de Workflow Científico (SGWfC) para apoiar este tipo de estudo. Basicamente, o workflow científico é um modelo ou template que representa uma seqüência de atividades, implementadas por ferramentas (programas ou serviços), a fim de realizar um determinado objetivo [Deelman et. al., 2009]. Esses workflows são interpretados e executados pelos SGWfCs. Em geral, os SGWfCs permitem a especificação, modelagem e execução do workflow científico, representado em uma linguagem própria, referente a cada um destes sistemas. Os workflows científicos e SGWfCs trazem benefícios para experimentação como: a possibilidade de registro da proveniência dos dados utilizados; automação da execução do fluxo de atividades; controle e invocação das ferramentas que implementam as atividades; manipulação dos dados passados entre as atividades [Mattos et al., 2008]. Um workflow científico, que representa um estudo baseado em, segue um conjunto de fases (Composição, Execução, Análise e Proveniência [Oinn et. al., 2007]) semelhante ao processo de experimentação (Definição, Planejamento, Execução, Análise e Interpretação, Empacotamento [Wohlin et al., 2000]) para sua instanciação. A Composição é similar às etapas de Definição e Planejamento no processo de experimentação, sendo uma importante fase, onde o pesquisador estrutura e define o estudo, em termos da seqüência de atividades necessárias, os tipos de dados de entrada e os produtos esperados. Essa fase, na verdade, é decomposta em duas subfases, a Concepção, no qual o pesquisador define um novo workflow, e o Reuso, no qual o pesquisador recupera um workflow e o adapta para atender a um novo estudo ou objetivo. Contudo, muitos autores sugerem que a Composição deve seguir um conceito de criação através de níveis de abstração [Medeiros et. al., 2005; Gil et. al., 2007], pois, assim, o pesquisador poderia, em momentos diferentes, definir o comportamento (objetivo, atividades e escopo) do workflow e depois, gradualmente, ir identificando questões de tecnologia (e.g., local de execução, tipo de chamada de uma ferramenta, dentre outras). Pode-se, de forma simplificada, definir em dois níveis a abstração do worklfow: concreto e abstrato. Neste caso, o nível mais abstrato é ligado à definição do comportamento do workflow, sendo denominado workflow abstrato. Já o nível concreto é ligado aos recursos computacionais necessários à execução do workflow científico, já pronto para execução em um SGWfC, sendo denominado workflow concreto [Mattos et al., 2008]. Com o crescente uso de estudos experimentais baseados em na Engenharia de Software [Zhang et. al., 2008], faz se necessário buscar formas de auxiliar os pesquisadores em sua realização. Uma possível maneira, como em outras áreas científicas, é através do uso de tecnologias de workflow científico e SGWfCs, visto que trazem as vantagens já enumeradas anteriormente, como controle, proveniência e automação. Porém, apesar desses benefícios, o uso dessas tecnologias gera novas questões associadas à especificação, modelagem e reutilização deste tipo de estudo experimental [Mattoso et al., 2008]. Soma-se a isso o fato de estudos do tipo in 23

3 virtuo e in silico, naturalmente, já adicionarem complexidade a realização do estudo, pois requerem maior apoio computacional e infra-estrutura complexa, bem como maior conhecimento do domínio onde a pesquisa será realizada [Travassos & Barros, 2003]. Isso tudo torna a Concepção não trivial para o pesquisador. Assim, a concepção pode se tornar uma barreira para a modelagem computacional de estudos baseados em. De fato, Modelagem Computacional já foi identificado como um dos desafios para computação [Kavanagh & Hall, 2008; SBC, 2009]. No momento da concepção do workflow científico, o pesquisador enfrenta uma série de dificuldades para sua realização. De forma geral, essa tarefa é realizada diretamente no nível concreto e de maneira ad hoc, o que pode acarretar em riscos para a pesquisa [Gil et. al., 2007; Verdi et al., 2007]. Soma-se a isso a falta de apoio dos SGWfC s para documentação mais detalhada do estudo. Estes sistemas, por exemplo, não permitem a especificação de atividades manuais ou semi-automatizadas, e também não apóiam a representação de diferentes fluxos de execução ligados ao estudo definido no mesmo workflow, característica existente nos estudos em Engenharia de Software. Isso pode acarretar perda do conhecimento, que fica somente disponível com o pesquisador responsável pelo workflow, tornando-o tácito. Ainda, como não existe um processo bem definido, a concepção pode não ser realizada organizadamente e, assim, o conhecimento não ser explorado e documentado de forma sistemática, acarretando dificuldades para seu posterior reuso por outro pesquisador [Mattoso et. al., 2008]. Em uma revisão tradicional da literatura técnica, não foi possível identificar uma abordagem de concepção de workflow abstrato para estudos do tipo in virtuo e in silico, que utilizasse tarefas bem definidas e definisse meios de garantir a qualidade dos produtos gerados (especificação do workflow abstrato). Por isso, Pereira & Travassos (2009) propuseram uma abordagem para concepção de workflows científicos abstratos e conseqüente especificação destes estudos experimentais. Esta abordagem visa oferecer meios para garantir o aumento da qualidade do produto final e da padronização das tarefas e produtos gerados. Este trabalho descreve a aplicação da abordagem de concepção de workflows abstratos para estudos in virtuo e in silico [Pereira & Travassos, 2009] em Engenharia de Software através de sua aplicação no domínio da Evolução de Software [Araujo, 2009]. O artigo é organizado da seguinte forma: a Seção 2 apresenta, resumidamente, a Abordagem de Concepção; a Seção 3 apresenta um exemplo de aplicação no domínio de Simulação da Evolução; a Seção 4 apresenta as lições aprendidas com a aplicação da abordagem; a Seção 5 apresenta alguns trabalhos relacionados; a Seção 6 apresenta o andamento da pesquisa, os trabalhos futuros e a conclusão. 2. Abordagem para Concepção de Workflows Abstratos A Abordagem para Concepção de Workflows Abstratos, proposta por Pereira & Travassos (2009), inspira-se nos processos de desenvolvimento de software e explora as técnicas usualmente utilizadas na Engenharia de Software [Pfleeger, 2004]. Essa abordagem intenciona auxiliar o pesquisador na concepção de estudos experimentais in virtuo e in silico, que utilizem a tecnologia de workflow científico, oferecendo facilidades para garantir a qualidade da especificação. São utilizados modelos e formulários para representar a especificação do workflow abstrato. Os modelos são 24

4 baseados no diagrama de atividades da UML 2.2 [OMG, 2009], enquanto os formulários (Atividades, Artefatos e Ferramentas) são compostos por campos que representam os requisitos do estudo experimental. O responsável pela especificação e modelagem é denominado modelador, sendo ele um pesquisador ou engenheiro de software. A Figura 1 apresenta a Abordagem de Concepção, maiores detalhes em [Pereira & Travassos, 2009]. De maneira resumida, a seguir é apresentada a Abordagem de Concepção. Definir modelo inicial do workflow científico Identificar e modelar requisitos do workflow científico Inspecionar a especificação do workflow científico Nova rodada de inspeção Avançar na concepção Validar a especificação do workflow científico Não validado Validado Figura 1. Tarefas da Abordagem para Concepção de Workflows Abstratos [Pereira & Travassos, 2009]. Inicialmente, realiza-se a tarefa Definir o modelo inicial do workflow científico, onde o modelador concebe o modelo inicial, construindo uma visão global do estudo através da discussão com outros pesquisadores. Após esta tarefa, Identificar e modelar requisitos do workflow científico é executado. Nela, o modelador cria a especificação do workflow abstrato através de reuniões semi-estruturadas com os pesquisadores. Os formulários são utilizados como guias nas perguntas da entrevista e o modelo inicial como base para o modelo de workflow abstrato. Conforme citado anteriormente, a abordagem também foca na garantia da qualidade da especificação gerada. Para alcançar esse objetivo, primeiramente é realizada uma verificação da especificação (Inspecionar a especificação do workflow científico), através de uma inspeção ad hoc, no qual os inspetores, pesquisadores do domínio não envolvidos na especificação, verificam todo o documento em busca de discrepâncias. Os defeitos são categorizados e corrigidos. Já a tarefa de validação, Validar a especificação do workflow científico, é realizada através de reuniões com todos os participantes, no qual todo o conteúdo do documento é avaliado, assim confirmando se os requisitos do estudo experimental foram capturados de maneira a atender o seu propósito. Essa abordagem vem sendo utilizada no contexto de um projeto real, Gexp ( para a especificação de workflows abstratos no domínio de exploração de petróleo em sistemas alto mar (offshore). 3. Domínio da Simulação de Evolução de Software A pesquisa sobre Evolução de Software tem como objetivo entender como sistemas evoluem e modificam-se ao longo do seu ciclo de vida e como isto pode influenciar no decaimento de sua qualidade. Para isto, podem-se construir modelos de para ajudar a observar a evolução do software ao longo de sucessivos ciclos de manutenção. Araújo (2009) apresenta um modelo, baseado nas Leis de Evolução de Software (LSE Laws of Software Evolution) [LEHMAN et al. 1998], que permite a observação do processo de decaimento do software ao longo do tempo, através da do comportamento de determinadas características do software. O modelo de Araújo baseia-se em premissas descritas através de formulações lógicas das LSE. Essas formulações representam as tendências do comportamento de determinadas características de software ao longo do tempo (e.g., características da fase de codificação: esforço, tamanho, periodici- 25

5 dade, complexidade, confiabilidade, manutenibilidade,). Entretanto, as premissas não permitem a observação direta do processo de decaimento da qualidade do software, pois não representam as influências que uma Lei exerce em outra. Assim, utiliza-se ferramentas para simular as características do software, através das equações definidas, que representam as influências entre as LSE e como essas afetam as características. A Figura 2 apresenta o processo para observação de Evolução de Software [Araújo, 2009]. Engenheiro de Software Coleta de Métricas Construção Planilha Geração das Equações Simulação Evolução de Software Ferramenta para Dinâmica de Sistemas Figura 2. Processo para Observação de Evolução de Software [Araújo, 2009]. Essa Figura 2 e uma descrição textual do processo são a especificação do estudo experimental apresentado em Araújo (2009). Contudo, a especificação apresentada não é padronizada, o que pode apresentar problemas. Por exemplo, na representação do modelo (Figura 2), estão misturados informações como: o perfil do pesquisador (Engenheiro de Software), a ferramenta utilizada (Ferramenta para Dinâmica de Sistemas) e as atividades do estudo. Estas informações distintas, sem um padrão de representação, que explicite qual é o significado de cada um desses no modelo, pode gerar confusão para um pesquisador que pretende repetir o estudo. Além disso, informações (e.g., descrição das atividades, insumos e produtos, dentre outras) estão descritas em formato textual sem um template, provocando o risco do pesquisador ao documentar esquecer alguma informação, pois, não há um conjunto característico de informações pré-definidas para cada elemento (Atividade, Ferramenta e Artefato) que deva sempre ser identificado. Estes exemplos de problemas, possíveis, no uso de uma especificação não padronizada, ilustram a necessidade do uso de uma abordagem que permita a identificação e documentação do conhecimento e dos requisitos (funcionalidades, restrições e objetivos) do estudo experimental a ser realizado. Com isso, foi aplicada a abordagem descrita na Seção 2, a fim de conceber uma especificação do estudo, incluindo atividades opcionais e/ou manuais e alternativas de ferramentas que suportam a execução do processo. Com essa especificação do workflow abstrato, esperase que, posteriormente, seja possível definir e repetir este estudo em um SGWfC Aplicação do processo de concepção Para representar o estudo in virtuo apresentado, foi criado, primeiramente, o modelo inicial do estudo (Figura 3), sendo ele um diagrama de atividades em alto nível de abstração. Foram identificadas, inicialmente, três atividades, retiradas do modelo (Figura 2) e, durante a modelagem inicial, foi identificada uma nova atividade: 1) Preparar dados para, na qual as métricas extraídas do processo real de desenvolvimento são padronizadas, avaliadas e excluídas caso apresentem comportamento incomum; 2) Gerar as equações para, na qual são criadas as equações baseadas nas formulações da LSE e que servirão como modelo para das características do software; 3) Simular a evolução do software, na qual ocorre a da evolução das características do software para um determinado tempo definido; 4) Análise do resultado da, na qual o objetivo é gerar uma análise do resultado da executada. Nesta etapa, também se identificou o papel do 26

6 Engenheiro de Software, cuja responsabilidade é garantir a qualidade dos dados escolhidos, das equações geradas e análise do resultado da. O modelo inicial (Figura 3) serviu como insumo para a tarefa de Identificar e modelar do processo de concepção. Início Experimento Preparar dados para Gerar as equações para Simular a evolução do software Análise do resultado da Fim Experimento Figura 3. Modelo Inicial para Simulação da Evolução de Software. Este modelo inicial foi refinado e, assim, foram identificados alguns pontos de decisão no estudo (vide Figura 4). No modelo foram representados os fluxos de controle e dados do modelo, o que possibilita ao pesquisador visualizar as dependências entre as atividades do estudo, trazendo a ele uma visão dessas duas perspectivas. Também foi percebido que três atividades eram compostas de sub-atividades. Na Figura 4, as atividades compostas estão estereotipadas com <<structured>>, que representam o conceito de sub-workflows. Inicio_Simulacao_Decaimento Dados reais do processo de desenvolvimento «datastore» Base de medidas da organização «structured» Preparar dados para Tabela com versões do software «decisão» {Base de medidas das versões é válida e suficiente para gerar as equações?} [SIM] Tabela com versões do software «structured» Gerar as equações para [MODIFICAR MEDIDAS DO SOFTWARE] Final_Simulacao_Decaimento Análise do resultado da [NÃO] «Semi-automatizada» Análise do resultado da «decisão» {Qual é origem do problema? Ação a ser tomada?} Dados da da evolução [MODIFICAR EQUAÇÕES PARA SIMULAÇÃO] Dados da da evolução [NÃO] [SIM] «structured» Simular a evolução do software Equações para Figura 4. Workflow abstrato para Simulação da Evolução de Software. «decisão» {Equações representam o modelo dinâmico?} Equações para O modelo que representa os fluxos (controle e dados) da atividade Gerar as equações para pode ser visto na Figura 5. Essa representação por subworkflows permitiu uma melhor organização, pois deixa os modelos mais legíveis para o pesquisador. Tabela com versões do software Inicio_Gerar_Equações Tabela com versões do software «Manual» Definir versão base da «structured» Gerar as equações para Tabela com versões do software Versão base Versão base «Semi-automatizada» Criar equações da Equações para Final_Gerar_Equações Figura 5. Sub-workflow para Gerar equações para. Equações para A especificação é composta pelos diagramas de atividades, mas também por um conjunto de formulários. Estes documentam cada atividade, artefato e ferramenta utilizada no estudo. Os formulários foram preenchidos conforme ocorreram as reuniões, em conjunto com a concepção dos modelos do workflow abstrato. A Tabela 1 apresenta alguns campos do formulário da atividade Criar equações da. A Tabela 2 27

7 apresenta o formulário associado ao artefato Equações para, que contém as equações geradas em Criar equações da. A Tabela 3 apresenta o formulário da ferramenta Tabela_Excel. O documento de especificação é composto por uma seção de introdução, descrição dos papéis envolvidos, apresentação dos modelos (diagramas de atividades) e formulários preenchidos. Tabela 1. Formulário atividade Criar equações da. Atividade Criar equações da Descrição As equações combinadas (referentes à formulação lógica pra cada Lei de Evolução de Software) e os valores base das características são definidos nas equações para, estas serão efetivamente utilizadas na da evolução do software. Para tal utilizam-se duas técnicas: regressão linear; e, método de mínimos quadrados. A aplicação da técnica de regressão linear, apesar da possibilidade de aumento do erro, é condizente com a análise semi-quantitativo dos dados, pois neste estudo é a tendência do comportamento de uma variável que deve ser considerado, mais do que seus valores individuais. A aplicação do método de mínimos quadrados, que é uma técnica de otimização matemática, procura encontrar o melhor ajustamento para um conjunto de dados, tentando minimizar a soma dos quadrados das diferenças entre a curva ajustada e os dados, onde essas diferenças são chamadas de resíduos. Tipo de Atividade Semi-Automatizada Papéis Engenheiro de Software Obrigatoriedade Obrigatória Pré-condições Nenhuma Ferramentas Tabela_Excel Pós-condições Nenhuma Produtos Equações para Pré-atividades Definir versão base da Insumos Tabela com versões do software; Versão base Tabela 2. Formulário artefato Dados da da evolução. Artefato Dados da da evolução Descrição Este artefato é construído a partir das influências identificadas entre as características de software, considerando que a periodicidade é uma variável em função do tempo decorrido, e as demais características são calculadas a partir das funções das outras características que nela influenciam que, por sua vez, são calculadas a partir da regressão linear dos dados coletados do sistema em observação. Também estão considerados aqui os valores da versão base e o incremento de tempo (em dias) a ser utilizado no processo de. Utilização Atividade Entrada/ Obrigatoriedade Formato Digital. Saída Origem Interna Criar equações da Saída Obrigatória Ferramenta Tabela_Excel Simular evolução Entrada Obrigatória Sinônimos Nenhum Tabela 3 Formulário ferramenta Tabela_Excel. Ferramenta Tabela_Excel Descrição Tabela no formato.xls onde já estão pré-definidos campos para o cálculo da regressão linear e do método dos mínimos quadrados. São geradas as equações para a partir dos dados das versões do software e permite a definição dos valores das características do software versão base. Tipo de aplicação Interface Formatos Suportados Formato.xls. Versão Não há. Local de Execução Local Sistema Operacional Windows XP SP3 com Office Excel Forma de disparo Chamada por interface gráfica. Figura 6. Planilha para relato de discrepâncias encontradas na inspeção. Após a tarefa de Identificar e modelar, foi solicitado a um pesquisador, que não participou da especificação, que inspecionasse e relatasse as discrepâncias em uma 28

8 planilha, como apresentado na Figura 6. Foram encontradas 20 discrepâncias no documento. Após isso, as discrepâncias foram analisadas para descartar as que não fossem defeitos reais (falso positivos 2 no total). Após a correção dos defeitos, o documento foi validado em conjunto, modelador e dois pesquisadores do domínio (incluindo o inspetor), sendo realizada a distância por um dos participantes. 4. Lições aprendidas A abordagem foi desenvolvida para ser aplicada por pesquisadores, porém foi observado ser ainda necessário conhecimento sobre modelagem UML, em especial sobre o diagrama de atividades. A aprendizagem sobre este modelo demanda tempo pelos participantes, em especial os pesquisadores. Por isso, a tarefa de Definir o modelo inicial do workflow científico é importante, pois abre a possibilidade do pesquisador ir assimilando os conceitos sobre modelagem e da própria técnica. Um ponto importante é a participação do pesquisador responsável e a necessidade de comprometimento por parte dos participantes, pois como em processos de software, o cliente é fundamental na captura e identificação dos requisitos. Relacionado à especificação e aos formulários, foi percebido que o crescimento do número de atividades, artefatos e ferramentas que fazem parte do estudo, pode dificultar o seu preenchimento, a sua manipulação e a consistência. Como os formulários foram criados para serem inter-relacionados, algumas informações ao sofrerem alteração demandam esforço para modificações em outros formulários. Ainda, destaca-se a possibilidade, apontada por um dos pesquisadores, de utilizar a especificação como forma de disseminação de conhecimento entre outros pesquisadores (novos no domínio). O modelo em diagrama de atividades permite uma visualização do encadeamento das atividades e os dados passados entre elas, enquanto os formulários sintetizam as informações e permitem um rápido acesso a um conteúdo organizado. 5. Trabalhos relacionados Em uma revisão da literatura técnica, apenas Verdi et al. (2007) apresentou um processo definido para concepção de workflows científicos abstratos. Este é composto por 3 fases de modelagem, com etapas de projeto e de validação. Contudo, não definem nenhuma atividade de verificação dos artefatos gerados, realizando somente a validação pelos próprios autores. Este tipo de abordagem pode acarretar risco da não percepção de defeitos no documento. Ainda, a captura das informações é realizada através de três modelos, um para capturar o fluxo de dados, outro para controle e um para hierarquia entre as atividades. Quanto ao modelo de hierarquia, o diagrama de atividades permite a representação de atividades compostas e, em geral, as ferramentas já mantém a consistência entre a atividade e seu modelo interno. Já sobre os fluxos de controle e dados, quando separados, pode haver inconsistência entre as informações nos diversos modelos. Além disso, muitos modelos diferentes podem gerar inconsistência na documentação e somente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algumas informações consideradas importantes (e.g. pré e pós-condições, papéis ou riscos). Alguns sistemas utilizam o conceito de template para representar o estudo experimental abstratamente. Contudo, os templates são dependentes do SGWfC e à sua infra-estrutura de execução, onde foram concebidos. Gil et al. (2007) e Kaster et al. 29

9 (2005) apresentam abordagens desse tipo. Esses sistemas permitem que um pesquisador com bom conhecimento do estudo defina o template que, posteriormente, é instanciado para uma infra-estrutura computacional provida pelos sistemas. Porém, isto acarreta uma forte dependência entre o estudo, o template e a plataforma na qual foram concebidos, afinal ele só é utilizado no próprio SGWfC. O estudo acaba ficando restrito, pois a especificação que deveria ser independente de linguagem, ou máquina de workflow, já é concebida pensando em questões relacionadas ao SGWfC. Afinal, os requisitos são os mesmos para o estudo, não importando o SGWfC a ser utilizado. 6. Conclusão A experimentação baseada em vem sendo cada vez mais utilizada em Engenharia de Software [Travassos & Barros, 2003]. Outras áreas da ciência também fazem uso da e, para concretizá-la, utilizam tecnologias como workflows científicos. A Engenharia de Software, em especial a experimental, pode também utilizar tais tecnologias para obter vantagens, como controle, automação da execução e proveniência dos dados gerados em estudos experimentais baseados em. Por isso, foi proposta uma abordagem para apoiar o pesquisador a especificar e gerar workflows científicos abstratos para estudos in virtuo e in silico [Pereira & Travassos, 2009]. Entendemos que a concepção de workflow científicos, em nível abstrato, deve ser independente de SGWfC, pois o estudo em si é independente de tecnologias e a sua execução deveria ser possível, a princípio, em qualquer infra-estrutura. Este artigo apresentou a aplicação da Abordagem de Concepção no domínio da observação da Evolução de Software. Através do uso da abordagem, foi possível capturar o processo para Simular a Evolução de Software de maneira incremental. O modelador e pesquisador responsável identificaram, inicialmente, as atividades e o seus objetivos, artefatos gerados e consumidos e ferramentas, gerando ao final uma especificação do workflow abstrato. Os formulários, quando utilizados, induzem a identificação das informações necessárias para o estudo e sua representação em workflow abstrato, levando à percepção de detalhes ou conhecimento não explicitado se feito de forma ad hoc. A formalização do estudo permite a posterior exploração dessa especificação como insumo para uma implementação em algum SGWfC ou ambiente computacional. A abordagem utilizada neste trabalho ainda está em desenvolvimento para apoiar experimentação baseada em em Engenharia de Software. Melhorias já estão previstas, tal como uso de técnica de inspeção mais formal, por exemplo, checklists calibrados para guiar o inspetor na verificação de questões importantes para o domínio ou na completude das informações. No momento, está sendo revisada de forma mais sistemática a literatura técnica em busca de possíveis abordagens que atendam e possam ser adaptadas a este contexto de estudo in virtuo e in silico. O volume de informações e a repetição de tarefas indicam a necessidade de apoio computacional para melhorar o gerenciamento do conteúdo e inserção automática de informações (e.g., insumos e produtos, pré-atividades, dentre outras), visando diminuir problemas com a consistência entre as informações e o esforço na manipulação e preenchimento dos formulários. 30

10 Agradecimentos Este trabalho é parte do projeto Engenharia de Software Experimental e Ciência em Larga Escala - CNPq (475459/2007-5) e FAPERJ. Os autores agradecem também a ao CAPES e FINEP por apoiar esta pesquisa. Referências Araújo, M. A. P. (2009) "Um Modelo para Observação de Evolução de Software", Tese de Doutorado, PESC/COPPE, Rio de Janeiro, UFRJ, p Deelman, E. et al. (2009) Workflows and e-science: An overview of workflow system features and capabilities, In: FGCS, v. 25, n. 5, pp Gil, Y. et al. (2007) Wings for Pegasus: Creating Large-Scale Scientific Applications Using Semantic Representations of Computational Workflows, IAAI 07, Vancouver, Canadá, p Kaster, D.; Medeiros, C.; Rocha, H., (2005) Supporting modeling and problem solving from precedent experiences: The role of workflows and case-based reasoning, Environmental Modelling and Software, v. 20, pp Kavanagh, J.; Hall, W. (2008) Grand Challenges in Computing Research 2008, Juristo, N.; Moreno, A.M. (2001) Basics of software engineering experimentation, 1 st ed., Kluwer Academic Publishers, 395p. Lehman, M.M.; Perry, D.E.; Ramil, J.F. (1998), Implications of Evolution Metrics on Software Maintenance, In:ICSM, v. 16, ed. 20, pp Mattos, A. et al. (2008) Gerência de Workflows Científicos: uma análise crítica no contexto da bioinformática, COPPE/UFRJ, PESC, Technical Report ES-716/08. Mattoso, M. et al. (2008) Gerenciando Experimentos Científicos em Larga Escala In: SBC- SEMISH 08, Belém, Brasil. p Medeiros et. al., C.B. (2005) WOODSS and the Web: annotating and reusing scientific workflows, SIGMOD Record, v. 34, n. 3, p Oinn, T. et. al. (2007) "Taverna/myGrid: Aligning a Workflow System with the Life Sciences Community", In: Workflows for e-science, Springer, p Object Management Group (2009) OMG Unified Modeling Language Specification, versão 2.2, formal/ , Pereira, W. M., Travassos, G.H. (2009) Abordagem para concepção de experimentos científicos em larga escala suportados por workflows científicos In: 3 E-Science Workshop colocado ao SBBD/SBES, Fortaleza, Brasil, in press. Pfleeger, S. L. (2004) Engenharia de Software: Teoria e Prática, 2 nd ed., Prentice Hall, 560p. Sociedade Brasileira de Computação (2006). Grandes Desafios da Computação no Brasil: , Travassos, G. H.; Barros, M. O. (2003) Contributions of In Virtuo and In Silico Experiments for the Future of Empirical Studies in Software Engineering, In: ESEIW WESSE, Roma, Italy, pp Verdi, K.; Ellis, H.; Gryk, M. (2007) Conceptual-level workflow modeling of scientific experiments using NMR as a case study, BMC Bioinformatics, v. 8, n. 31, 12p. Wohlin, C. et al. (2000) Experimentation in Software Engineering, Kluwer Academic Publishers, 204p. Zhang, H., Kitchenham, B., and Pfahl, D. (2008) Software Process Simulation Modeling: Facts, Trends and Directions, In Proceedings of the th APSEC. IEEE Computer Society, Washington, DC, pp