Apoio na Concepção de Workflow Científico Abstrato para
Estudos in virtuo e in silico em Engenharia de Software
Wallace M. Pereira1, Marco Antônio P. Araújo2, Guilherme H. Travassos1 1
Programa de Engenharia de Sistemas e Computação (PESC), COPPE/UFRJ Universidade Federal do Rio de Janeiro, Brasil, Caixa Postal 68511 – CEP 21945-970
2
Centro de Ensino Superior de Juiz de Fora / Faculdade Metodista Granbery
{wpereira,ght}@cos.ufrj.br, [email protected]
Abstract. Science evolution has been supported by complex computerized infra-structures 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 simulação 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 simulação 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 simulação 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:
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 simulação, 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 simulação, 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 experi-mentaçã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 pro-dutos 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 recu-pera 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 pesquisa-dor 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 simulação 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
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 simulação. 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
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 Nova rodada de inspeção Avançar na concepção Inspecionar a especificação do workflow científico 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 (http://gexp.nacad.ufrj.br), 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 simulação 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 pro-cesso de decaimento do software ao longo do tempo, através da simulação do compor-tamento 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 repre-sentam 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-dade, complexiperiodici-dade, confiabiliperiodici-dade, manutenibiliperiodici-dade,). 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].
Coleta de Métricas Construção Planilha Geração das Equações Engenheiro de Software 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, espera-se que, posteriormente, espera-seja possível definir e repetir este estudo em um SGWfC.
3.1. 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 simulação, 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 simulação, na qual são criadas as equações baseadas nas formulações da LSE e que servirão como modelo para simulação das características do software; 3) Simular a evolução do software, na qual ocorre a simulação da evolução das características do software para um determinado tempo definido; 4) Análise do resultado da simulação, na qual o objetivo é gerar uma análise do resultado da simulação executada. Nesta etapa, também se identificou o papel do
Engenheiro de Software, cuja responsabilidade é garantir a qualidade dos dados escolhidos, das equações geradas e análise do resultado da simulação. 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 simulação Gerar as equações para simulação Simular a evolução do software Fim Experimento Análise do resultado da simulação
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.
«structured» Preparar dados para
simulação Tabela com versões do software Dados reais do processo de desenvolvimento «structured» Gerar as equações para
simulação Tabela com versões do software Equações para simulação Final_Simulacao_Decaimento «decisão» {Equações representam o modelo dinâmico?} «decisão»
{Base de medidas das versões é válida e suficiente para gerar as equações?} Inicio_Simulacao_Decaimento «datastore» Base de medidas da organização «structured» Simular a evolução do software Equações para simulação Dados da simulação da evolução «decisão» {Qual é origem do problema? Ação a ser tomada?} «Semi-automatizada» Análise do resultado da
simulação Dados dasimulação da evolução Análise do resultado da simulação [SIM] [NÃO] [SIM] [MODIFICAR MEDIDAS DO SOFTWARE] [MODIFICAR EQUAÇÕES PARA SIMULAÇÃO] [NÃO]
Figura 4. Workflow abstrato para Simulação da Evolução de Software.
O modelo que representa os fluxos (controle e dados) da atividade Gerar as
equações para simulação pode ser visto na Figura 5. Essa representação por
sub-workflows permitiu uma melhor organização, pois deixa os modelos mais legíveis para o pesquisador.
«structured»
Gerar as equações para simulação
Tabela com versões do software Equações para simulação Inicio_Gerar_Equações Final_Gerar_Equações «Semi-automatizada» Criar equações da simulação Versão base Tabela com versões do software
Equações para simulação
«Manual» Definir versão base
da simulação Versão base
Tabela com versões do software
Figura 5. Sub-workflow para Gerar equações para simulação.
A especificação é composta pelos diagramas de atividades, mas também por um conjunto de formulários. Estes documentam cada atividade, artefato e ferramenta utili-zada 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 simulação. A Tabela 2
apresenta o formulário associado ao artefato Equações para simulação, que contém as equações geradas em Criar equações da simulação. 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 simulação.
Atividade Criar equações da simulação
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 simulação, estas serão efetivamente utilizadas na simulação 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 simulação Pré-atividades Definir versão base da
simulação
Insumos Tabela com versões do software; Versão base
Tabela 2. Formulário artefato Dados da simulação da evolução.
Artefato Dados da simulação 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 simulação.
Utilização Atividade Entrada/
Saída
Obrigatoriedade Formato Digital.
Origem Interna
Criar equações da simulação 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 simulação 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
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 defei-tos 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 repre-sentaçã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 so-mente usar modelos, como em Verdi et. al. (2007), pode acabar por não capturar algu-mas 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.
(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 conce-bidos, 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 simulação vem sendo cada vez mais utilizada em Engenharia de Software [Travassos & Barros, 2003]. Outras áreas da ciência também fazem uso da simulação 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 simulação. 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 captu-rar 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 simulação 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 pro-dutos, 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.
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. 191.
Deelman, E. et al. (2009) “Workflows and e-Science: An overview of workflow system features and capabilities”, In: FGCS, v. 25, n. 5, pp. 528-540.
Gil, Y. et al. (2007) “Wings for Pegasus: Creating Large-Scale Scientific Applications Using Semantic Representations of Computational Workflows”, IAAI’07, Vancouver, Canadá, p. 1767-1774.
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. 689-704.
Kavanagh, J.; Hall, W. (2008) “Grand Challenges in Computing Research 2008”,
http://www.ukcrc.org.uk/grand_challenges/news/gccr08final.pdf.
Juristo, N.; Moreno, A.M. (2001) “Basics of software engineering experimentation”, 1st 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 208 – 217.
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.121-135.
Medeiros et. al., C.B. (2005) “WOODSS and the Web: annotating and reusing scientific workflows”, SIGMOD Record, v. 34, n. 3, p. 18-23.
Oinn, T. et. al. (2007) "Taverna/myGrid: Aligning a Workflow System with the Life Sciences Community", In: Workflows for e-Science, Springer, p. 300-319.
Object Management Group (2009) “OMG Unified Modeling Language Specification”, versão 2.2, formal/09-02-02, http://www.omg.org/spec/UML/2.2/.
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”, 2nd ed., Prentice Hall, 560p. Sociedade Brasileira de Computação (2006). Grandes Desafios da Computação no Brasil:
2006-2016, http://www.sbc.org.br/index.php?language=1&content=downloads&id=272. 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 2003 - WESSE, Roma, Italy, pp. 117–130.
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 2008 15th APSEC. IEEE Computer Society, Washington, DC, pp. 59-66.
