Barbara Cristina Alves Silveira 1, Thiago Silva-de-Souza 2 INTRODUÇÃO REFERENCIAL TEÓRICO

Transcrição

1 ACASE SPEM: FERRAMENTA PARA INSTANCIAÇÃO DE PROCESSOS SPEM BASEADA NO ECLIPSE MODELING FRAMEWORK ACASE SPEM: AN ECLIPSE MODELING FRAMEWORK BASED TOOL FOR SPEM PROCESSES INSTANTIATION Barbara Cristina Alves Silveira 1, Thiago Silva-de-Souza 2 Abstract In general, software processes are beneficial to software development teams. However, in most companies there is no documented process guiding how to develop projects. Probably the main difficulty to define a process is the lack of conceptual support on process models. The Software Process Engineering Metamodel (SPEM) is a metamodel, defined by the Object Management Group (OMG), used to describe software development processes. This paper presents an Eclipse Modeling Framework (EMF) based tool for definition and instantiation of software processes according to SPEM. In addition, this paper discusses the fundamental concepts of Model Driven Architecture (MDA), as well as a critical view of EMF, presenting its advantages and disadvantages. Index Terms Software Process, Model-Driven Architecture, SPEM, EMF. INTRODUÇÃO Processos de desenvolvimento são largamente utilizados na indústria de software, com base em diversos modelos de ciclo de vida. A utilização de um processo pode trazer diversos benefícios às equipes de desenvolvimento, tais como repetibilidade, facilidade de realocação de recursos, etc. Entretanto, mesmo utilizando processos prescritivos, onde cada tarefa é detalhada, as fábricas de software, em geral, costumam ter problemas quanto à correta execução do processo em seus diversos projetos. Um ponto de partida para garantir a aderência dos projetos aos processos é a definição de um modelo geral de processos (ou metamodelo), que, a partir do qual, processos possam ser definidos e instanciados de acordo com o contexto de cada organização. Em seguida, esse processo deve ser automatizado, de forma a garantir que todos as tarefas sejam devidamente realizadas e todos os artefatos sejam entregues pelos membros dos projetos. Diante disso, o Object Management Group (OMG) definiu um metamodelo de processos denominado Software Process Engineering Metamodel (SPEM) [8]. A partir dos conceitos do SPEM é possível definir os mais variados processos de desenvolvimento de software. Seu modelo é bem definido e pode ser facilmente implementado por ferramentas que tenham como objetivo instanciar o processo e controlar a aderência dos projetos. O Eclipse Modeling Framework (EMF) é a implementação corrente de parte da Model Driven Architecture (MDA) na família de ferramentas do Eclipse [6]. A ideia por trás do MDA é tornar possível que o desenvolvimento e o gerenciamento de todo o ciclo de vida da aplicação sejam baseados no modelo. O modelo por sua vez é descrito por um metamodelo, que através de mapeamentos, é utilizado para gerar artefatos de software, os quais irão programar o sistema real [6]. O projeto EMF é um passo significativo que promete acelerar a utilização de MDA, mostrando o quão pragmático o uso dos conceitos mencionados anteriormente pode levar a benefícios significativos. O EMF provê persistência, uma API reflexiva bastante eficiente para manipulação de objetos genéricos, um framework para notificação de mudanças e classes genéricas reutilizáveis para a construção de editores de modelos do EMF. Este trabalho está organizado em mais três seções, nas quais é apresentada uma aplicação que permite a instanciação de processos SPEM, construída através da ferramenta EMF. REFERENCIAL TEÓRICO SPEM O Software Process Engineering Metamodel (SPEM) é um metamodelo, definido pelo OMG, usado para descrever processos de desenvolvimento de software ou uma família de processos de desenvolvimento de software relacionados [8]. A versão do SPEM considerada neste trabalho é a 1.1, datada de janeiro de O SPEM utiliza uma abordagem orientada a objetos e a UML como notação para representar os processos de desenvolvimento de software. Sua definição se baseia em uma arquitetura de quatro níveis de modelagem, representada na Figura 1, onde se observa que o SPEM é baseado no Meta-Object Facility (MOF), a tecnologia adotada pelo OMG para definir metadados, e serve como metamodelo de processos conhecidos, como o 1 Barbara Cristina Alves Silveira, Universidade do Grande Rio (UNIGRANRIO), ba.cristina@gmail.com 2 Thiago Silva-de-Souza, Universidade Federal do Rio de Janeiro (UFRJ), Universidade do Grande Rio (UNIGRANRIO), and Serviço Federal de Processamento de Dados, Brazil, thiagosouza@cos.ufrj.br DOI /WCSEIT

2 Rational Unified Process (RUP). A especificação do SPEM é estruturada como um profile UML e provê um metamodelo baseado no MOF [8]. Esta abordagem facilita a troca de modelos entre ferramentas baseadas no MOF. Atualmente, diversas empresas focam seus esforços em construir ferramentas para dar apoio ao SPEM. o terceiro passo é a geração de um ou mais Platform Specific Models (PSMs). Cada PSM é gerado levando em conta detalhes específicos de uma determinada tecnologia a ser utilizada na implementação. Para cada PIM, vários PSMs podem ser gerados. o último passo é a geração de código a partir de cada PSM. Esta geração de código não constrói apenas estruturas básicas e templates, como fazem algumas ferramentas CASE tradicionais; o código gerado no MDA deve ser o mais próximo possível da solução de software definitiva, incluindo as regras de negócio. A Figura 2 representa as etapas da arquitetura MDA, com seus artefatos e relacionamentos. FIGURA 1 ARQUITETURA DE QUATRO NÍVEIS [8]. Model-Driven Architecture A arquitetura Model Driven Architecture (MDA) proposta pelo Object Management Group (OMG) reconhece a importância dos modelos no processo, tornando-os o ponto-chave no desenvolvimento. Ela define que o processo de desenvolvimento de software deve ser direcionado pela atividade de modelagem do sistema [7], no nível conceitual, independente de qualquer plataforma ou tecnologia de implementação, e através de transformações realizadas sobre esse modelo conceitual, novos modelos, com níveis de abstração cada vez mais específicos e ligados à implementação sejam gerados, de forma que o sistema final seja gerado automaticamente, a partir da especificação definida no modelo conceitual. Os modelos construídos são mais formais, evitando ambiguidade, modelos que podem ser entendidos por sistemas de software [4]. MDA, na verdade, é uma especificação para apoiar o desenvolvimento dirigido por modelos, chamado de Model-Driven Development (MDD) [1]. MDD não é algo recente, mas ganhou notoriedade após o OMG lançar a especificação MDA, em A MDA compreende três passos principais: o primeiro passo é a geração do modelo Computation Independent Model (CIM), uma visão do sistema de um ponto-de-vista independente de computação [7]. O CIM representa apenas requisitos do sistema e não mostra detalhes de sua estrutura. Apesar de constar na especificação MDA, o CIM ainda é um conceito pouco explorado e omitido na maioria das ferramentas MDA. o segundo passo é a geração, a partir do CIM, do modelo chamado Platform Independent Model (PIM), definido com um alto grau de abstração, independente de qualquer tipo de tecnologia. O PIM descreve o sistema de software de uma perspectiva que melhor represente o negócio sendo modelado; FIGURA 2 ETAPAS DE TRANSFORMAÇÃO NO MDA [5]. Eclipse Modeling Framework O Eclipse Modeling Framework (EMF) foi desenvolvido para facilitar o projeto e a implementação de um modelo e permitir seu intercâmbio [6]. A partir de um modelo EMF, que pode ser representado de diversas formas, o framework é capaz de gerar um conjunto de classes de modelo, um conjunto de classes adaptadoras e um editor. Um dos aspectos mais importantes de EMF é que ele provê os alicerces para interoperabilidade com outras ferramentas baseadas em EMF. Tal aspecto tende a impulsionar a popularização do framework e, consequentemente, trazer novas funcionalidades. O EMF consiste de três partes fundamentais [3]: EMF: o núcleo do framework EMF inclui um metamodelo (Ecore) para descrever e executar modelos incluindo notificação de mudanças, suporte a persistência com serialização XMI e uma API reflexiva para manipular objetos EMF genericamente. EMF.Edit: framework que inclui classes para construir editores para modelos EMF, os quais podem ser exibidos através de visualizadores padrão. EMF.Codegen: framework que provê a capacidade de geração de qualquer coisa necessária à construção de um editor completo para o modelo EMF, incluindo uma interface gráfica e geradores que podem ser invocados. 132

3 ACASE SPEM Esta seção apresenta, em três subseções, a prova de conceito desenvolvida neste trabalho, denominada acase SPEM. A primeira subseção descreve o modelo de processos implementado pela ferramenta; a segunda subseção descreve os materiais e métodos utilizados para o desenvolvimento da ferramenta; finalmente, a terceira subseção apresenta os resultados através da demonstração de algumas funcionalidades da ferramenta. Modelo de Processos A prova de conceito foi desenvolvida utilizando parte da especificação do SPEM. Foi utilizado o pacote Process Structure que define a estrutura dos elementos básicos de um processo de desenvolvimento. O modelo a seguir (Figura 3) representa um recorte do pacote Process Structure, onde são apresentados tais elementos, seus relacionamentos e os respectivos papéis nestes relacionamentos. FIGURA 3 MODELO DE CLASSES DA ESTRUTURA DE UM PROCESSO SPEM [8]. Essa representação contém apenas os elementos essenciais para realizar a prova de conceito. Desses elementos só será necessário instanciar objetos das seguintes classes: WorkProduct: é a descrição de algo que contém informação ou é uma entidade física produzida ou usada por atividades do processo (artefato). ProcessRole: descreve os papéis, responsabilidades e competências que um determinado indivíduo tem dentro do processo. Activity: descreve uma determinada atividade que um papel realiza dentro de um processo. Step: descreve um passo dentro de uma atividade. Atividades podem ser compostas por vários passos. Na prova de conceito foi desenvolvida uma ferramenta a partir do modelo descrito na Figura 3. A partir desse modelo foram implementadas funcionalidades para gerenciar a criação, consulta, alteração e exclusão desses elementos. Materiais e Métodos O desenvolvimento da ferramenta iniciou-se com a criação do modelo independente de plataforma (PIM). Optou-se por criar um modelo de classes UML para representar a porção do Process Structure utilizada neste estudo de caso. A escolha deve-se ao fato dessa abordagem ser mais simples, prover maior grau de abstração e ser a forma de representação sugerida pela especificação MDA. O modelo foi criado através do Rational Rose e importado através do Eclipse, criando um projeto EMF. Em uma primeira tentativa de implementação o modelo foi criado exatamente como mostrado na Figura 3. Entretanto, para facilitar o entendimento da aplicação pelo usuário e em virtude de especificidades do EMF, o modelo precisou sofrer algumas alterações. A primeira delas foi criar atributos name em cada uma das classes a serem instanciadas pela aplicação, com o intuito de atribuir nomes específicos para cada elemento incluído no processo. Com isso, o usuário pode atribuir nomes que identificam os componentes gerados em seu processo. A segunda modificação foi definir os relacionamentos entre WorkProduct e ProcessRole, ProcessRole e Activity, e Activity e Step com navegabilidade bidirecional. Essa modificação permite ao EMF criar métodos get(), com tipo de retorno EList, para consultar coleções de objetos das classes com a navegabilidade definida no relacionamento. Desta forma, é possível recuperar, por exemplo, todas as atividades relacionadas com determinado papel, bem como, todos os passos relacionados com determinada atividade. A terceira alteração foi a criação de uma classe Process para atuar como raiz de persistência para objetos das classes de modelo e para identificar um processo em si. Um objeto da classe Process é instanciado quando é executada a funcionalidade de criar processo e é composto por objetos das classes WorkProduct, ProcessRole e Activity. Os relacionamentos entre Process e tais classes também possuem navegabilidade bidirecional. Esta instância de Process é persistida como elemento raiz do arquivo XML. A Figura 4 representa o modelo com as alterações mencionadas. FIGURA 4 MODELO ADAPTADO DA ESTRUTURA DE UM PROCESSO SPEM. Feitas as modificações, foi criado um novo projeto EMF através do Eclipse tendo o modelo de classes SPEM alterado como insumo. Foram gerados, então, o modelo core e o modelo gerador. Através do modelo gerador foi gerado o código correspondente ao modelo core, bem como, os casos de teste. 133

4 Resultados A ferramenta, denominada acase SPEM, possui quatro funções básicas: criar, consultar, atualizar e excluir processo, além de uma opção para encerrar a aplicação. A Figura 5 mostra tais funções no acase SPEM. FIGURA 5 PRINCIPAIS FUNÇÕES DO ACASE SPEM. De acordo com o número digitado, uma das funções será executada. A primeira opção (Create process) permite criar um processo baseado no SPEM e serializá-lo em formato XML. Durante a criação de um processo é possível criar artefatos (WorkProduct), papéis (ProcessRole), atividades (Activity) e passos (Step) para as atividades, de acordo com o modelo usado pela ferramenta. O arquivo XML receberá o mesmo nome dado ao processo durante sua criação e será gravado em C:\. A Figura 6 mostra um exemplo de criação de processo através do acase SPEM, onde o nome do processo é definido e estão sendo criadas as atividades Modelagem de Negócio e Requisitos. FIGURA 7 ATIVIDADES E PASSOS DO PROCESSO. Na inclusão de papéis é possível, desde então, associálos a atividades que, neste momento, já devem estar cadastradas. Também é possível criar os papéis e postergar a definição de suas associações. A associação é feita informando o índice da atividade a qual deseja-se associar ao papel. Sendo assim, são listadas todas as atividades cadastradas com seus índices. Posteriormente, modificações podem ser efetuadas sobre tais associações. A Figura 8 mostra um exemplo de criação de papel no acase SPEM, onde tal papel está sendo associado com uma atividade. FIGURA 6 CRIAÇÃO DE UM PROCESSO ATRAVÉS DO ACASE SPEM. Como exemplo de processo para ser instanciado pelo acase SPEM foi utilizado o processo de uma empresa de grande porte da área de tecnologia da informação. Tal processo estende o RUP e adiciona as áreas chaves de processo do Capability Maturity Model Integration (CMMI) como atividades, seguindo o metamodelo do SPEM. Com as atividades criadas, foram adicionados os passos que as compõem, através da funcionalidade Create Step. De acordo com o SPEM, atividades são compostas por passos e cada passo está associado a apenas uma atividade. Na API de serialização do EMF um atributo simples é serializado como um atributo XML; já atributos multivalorados são armazenados como elementos XML; quanto aos relacionamentos, num relacionamento de composição cada objeto composto é serializado como um elemento XML, e cada objeto que o compõe é armazenado como um elementofilho [2]. A Figura 7 mostra um recorte do arquivo XML logo após ter suas atividades e passos criados. FIGURA 8 CRIAÇÃO DE UM PAPEL. Toda associação no arquivo XML possui vínculos explícitos em ambos os objetos envolvidos, isto é, atributos de referência em ambos os elementos XML. Tais referências são feitas usando fragmentos URI que são usados para identificar os objetos em um recurso [2]. Dessa forma, se um elemento estiver associado com um objeto de uma coleção haverá um atributo com o nome da coleção neste elemento com o valor referenciando o objeto específico da coleção. O 134

5 formato usado pela implementação de recursos do EMF para identificar objetos em um recurso é onde Elemento identifica o tipo de elemento do objeto e o índice é um número que identifica aquele elemento no arquivo XML de acordo com a ordem de serialização, iniciando de 0 (zero). Um atributo de referência pode armazenar várias referências, de acordo com a multiplicidade do modelo. A Figura 9 representa os papéis do processo, onde há a representação de uma associação do papel Analista de negócio com a atividade de índice zero. FIGURA 9 REPRESENTAÇÃO DOS PAPÉIS DO PROCESSO EM XML. Outra opção do acase SPEM é a criação de artefatos. No momento de sua criação, um artefato pode ser associado a um papel que se torna seu responsável. Desta forma, no momento da criação de um artefato, são listados todos os papéis cadastrados para que seja efetuada a associação através do índice do papel. O SPEM determina que um artefato possui zero ou um papel responsável. Sendo assim, no momento da criação de cada artefato foi efetuada a associação com seus respectivos papéis responsáveis. A Figura 10 mostra um recorte dos artefatos criados e seus respectivos relacionamentos com papéis. Modelos em formato intercambiável: modelos podem ser persistidos em formato XML/XMI e ser facilmente utilizados por diversas ferramentas. Utilização de padrões de projeto: o código gerado pelo EMF segue padrões de projeto e boas práticas de desenvolvimento, o que torna o código mais fácil de ser reutilizado, entendido e modificado. Realiza a crítica do modelo: como foi observado através do acase SPEM, o EMF garante as restrições representadas no modelo. Dentre as limitações do EMF vale destacar as seguintes: Gera apenas código Java: o ideal é que uma ferramenta MDA forneça suporte a geração de código para mais de uma plataforma. Não gera o comportamento da aplicação: o modelo não representa aspectos dinâmicos da aplicação (apenas aspectos estruturais). Apesar das contribuições apresentadas, este trabalho possui limitações, que podem ser exploradas em trabalhos futuros, tais como: Modelagem visual: acase SPEM limita-se, atualmente, a instanciar processos de desenvolvimento através de uma interface baseada em linhas de comandos. Um trabalho futuro poderia desenvolver uma interface gráfica que permitisse ao usuário a modelagem visual do processo, tal qual uma ferramenta CASE. Execução de processos: considerando que um processo já tenha sido instanciado, ele poderia ser executado sob o controle da ferramenta, guiando os usuários do processo na execução de suas atividades e garantindo que as restrições do processo sejam respeitadas. REFERÊNCIAS BIBLIOGRÁFICAS FIGURA 10 ARTEFATOS E SEUS RELACIONAMENTOS COM PAPÉIS. CONCLUSÃO E TRABALHOS FUTUROS Este trabalho apresentou acase SPEM, uma ferramenta que permite a instanciação de processos baseados no metamodelo SPEM. Tal ferramenta foi concebida como uma prova de conceito, para avaliar a efetividade do framework EMF como uma ferramenta MDA. Foram apresentadas as principais funções da ferramenta, fundamentando-as sobre os conceitos relacionados ao metamodelo SPEM e ao framework EMF. Cabe ressaltar que além das operações de criação apresentadas (atividades, papéis e artefatos), a ferramenta ainda oferece suporte às operações de consulta, alteração e exclusão. No que concerne ao uso do EMF como ferramenta MDA, foram observados os seguintes pontos positivos: Ganho de produtividade: por gerar o código das classes de modelo e possuir uma API de persistência. [1] ARLOW, J.; NEUSTADT, I. Enterprise patterns and MDA: building better software with archetype patterns and UML. Boston, EUA: Addison-Wesley, [2] BUDINSKY, F. E. A. Eclipse Modeling Framework: a developer s guide. Boston: Addison-Wesley, [3] ECLIPSE PROJECT. EMF documents: generating an EMF model. Eclipse Modeling Framework, Disponível em: < Acesso em: junho [4] FRANKEL, D. S. Model Driven Architecture: applying MDA to enterprise computing. Indianapolis, EUA: Wiley Publishing, [5] KLEPPE, A.; WARMER, J.; BAST, W. MDA explained: the model driven architecture: practice and promise. Boston: Pearson, [6] MOORE, B. E. A. Eclipse development using the Graphical Editing Framework and the Eclipse Modeling Framework. [S.l.]: IBM Redbooks, [7] OMG. MDA guide version Object Management Group, Disponível em: < Acesso em: 10 set [8] OMG. Software Process Engineering Metamodel Specification, version 1.1. Object Management Group, Disponível em: < Acesso em: janeiro