THIAGO MORAES EXTRAÇÃO DO COMPORTAMENTO ESPECIFICADO EM MODELOS UML USANDO O ECLIPSE MODELING FRAMEWORK JOINVILLE SC

Transcrição

1 THIAGO MORAES EXTRAÇÃO DO COMPORTAMENTO ESPECIFICADO EM MODELOS UML USANDO O ECLIPSE MODELING FRAMEWORK JOINVILLE SC 2012

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS - CCT DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO - DCC THIAGO MORAES EXTRAÇÃO DO COMPORTAMENTO ESPECIFICADO EM MODELOS UML USANDO O ECLIPSE MODELING FRAMEWORK Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como requisito para a obtenção do grau de Bacharel em Ciência da Computação Orientador: Dr. Marco Aurélio Wehrmeister JOINVILLE SC 2012

3 THIAGO MORAES EXTRAÇÃO DO COMPORTAMENTO ESPECIFICADO EM MODELOS UML USANDO O ECLIPSE MODELING FRAMEWORK Trabalho de conclusão de curso aprovado como requisito para obtenção do título de Bacharel, no curso de Ciência da Computação da Universidade do Estado de Santa Catarina. Banca Examinadora: Orientador: Dr. Marco Aurélio Wehrmeister Universidade do Estado de Santa Catarina Membro Dr. Fabiano Baldo Universidade do Estado de Santa Catarina Membro Dra. Janine Kniess Universidade do Estado de Santa Catarina JOINVILLE-SC, 1 DE JUNHO DE 2012

4 RESUMO As experiências tem mostrado que o desenvolvimento de software orientado a código-fonte possui um grau de dificuldade relativamente elevado. A utilização da engenharia guiada por modelos (Model Driven Engineering, MDE) traz o conceito que a utilização de modelos é parte integrante do processo de desenvolvimento do software, assim como o código fonte. Várias técnicas de MDE usam a UML (Unified Modeling Language) como linguagem para a especificação de modelos. Embora a utilização dos diferentes diagramas fornecidos pela UML facilite a visualização do sistema, estes diagramas diferentes podem especificar a mesma característica (e.g. um determinado comportamento do sistema) de pontos de vista diferentes, levando a ambiguidade nas especificações. Uma solução é a transformação de modelos UML para algum outro modelo que contorne este impasse. Para este caso, pode-se utilizar o DERCS (Distributed Embedded Real-time Compact Specification). Neste contexto, este trabalho propõe uma implementação do pacote Behavior do modelo DERCS, que permite a especificação comportamental do sistema. O objetivo desta implementação é possibilitar a sua utilização em ferramentas CASE que utilizem a tecnologia fornecida pelo Eclipse Modeling Framework (EMF), que é um framework de código aberto com bastante aceitação pelos desenvolvedores de software e que possui várias ferramentas já disponíveis para utilização. Palavras-chave: MDE, DERCS, Eclipse Modeling Framework, UML

5 ABSTRACT Experience has shown that the software development oriented by source-code maintains a relatively high degree of difficulty. The MDE proposes that models are essential to the software development process, as well as source code. Several MDE techniques use UML (Unified Modeling Language) as a language for model specification. Although the use of different UML diagrams facilitates the visualization of the system, these different diagrams may specify the same characteristic (e.g. a specific behavior of the system) from different points of view, resulting in ambiguous specifications. One solution to overcome this problem is to transform UML models into another model. For this case, can be use the DERCS (Distributed Embedded Real-time Compact Specification). In this context, this work proposes a implementation of the Behavior package of the DERCS model. This package allows the specification system s behavior in a technology independent way. The main motivation of this implementation is to allow its usage in CASE tools that uses the Eclipse Modeling Framework (EMF), which represents an open source framework that is widely accepted by the software developers and also provides several tools already available for use. Key words: MDE, DERCS, Eclipse Modeling Framework, UML

6 LISTA DE FIGURAS Figura 2.1 Elementos MDE (LUCREDIO, 2009) Figura 2.2 Arquitetura de metamodelagem (LUCREDIO, 2009) Figura 2.3 Exemplo de diagrama de caso de uso Figura 2.4 Exemplo de diagrama de sequência (GUEDES, 2007) Figura 2.5 Elementos do modelo Ecore (DIAS, 2009) Figura 2.6 Exemplo modelo Ecore Figura 4.1 Elementos comportamentais do metamodelo DERCS: Magic Draw Figura 4.2 Elementos comportamentais do metamodelo DERCS: EMF Figura 4.3 Editor gráfico EMF Figura 5.1 Interação Movement Encode (WEHRMEISTER, 2009) Figura 5.2 UML2 interação Movement Encode (WEHRMEISTER, 2009) Figura 5.3 Fragmento combinado (WEHRMEISTER, 2009) Figura 5.4 UML2 interação General Behavior (WEHRMEISTER, 2009)

7 LISTA DE TABELAS Tabela 1 Exemplo código ATL Tabela 2 Vantagens e desvantagens trabalhos correlatos Tabela 3 Exemplo regra Behavior ATL Tabela 4 Resultado da transformação Interação Movement Encode Tabela 5 Regra transformação fragmento combinado Tabela 6 Resultado da transformação fragmento combinado Tabela 7 Comparação entre as transformações... 47

8 LISTA DE ACRÔNIMOS API Application Programmin Interface ATL Atlas Transformation Language BPEL4WS Business Process Execution Language for Web Services CIM Computation Independent Model EMF Eclipse Modeling Framework MDA Model-Driven Architecture MDE Model-Driven Engineering MOF Meta-Object Facility OCL Object Constraint Language OMG Object Management Group PIM Plataform Independent Model PSM Plataform Specific Model QVT Queries/Views/Transformations UAV Unmanned Aerial Vehicle UML Unified Modeling Language XML Extensible Markup Languague XMI XML Metadata Interchange

9 SUMÁRIO 1. INTRODUÇÃO E JUSTIFICATIVA OBJETIVOS METODOLOGIA ORGANIZAÇÃO DO TRABALHO CONCEITOS MODEL-DRIVEN ENGINEERING Vantagens e desvantagens do uso de MDE Componentes da MDE UNIFIED MODELING LANGUAGE Especificação estrutural Especificação comportamental Diagrama de casos de uso Diagrama de sequência Diagrama de atividades Diagrama de estados Diagrama de visão geral de interação Diagrama de comunicação Diagrama de temporização ECLIPSE MODELING FRAMEWORK Ecore ATL UML TRABALHOS CORRELATOS DISCUSSÃO IMPLEMENTANDO O PACOTE BEHAVIOR DO MODELO DERCS UTILIZANDO EMF/ATL DERCS... 33

10 4.2 DERCS EMF TRANSFORMAÇÃO DE MODELOS UML PARA MODELO DERCS EMF ESTUDO DE CASO VALIDAÇÃO DISCUSSÃO CONCLUSÃO E TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A ANEXO B ANEXO C... 69

11 11 1. INTRODUÇÃO E JUSTIFICATIVA Mesmo com os avanços na área de engenharia de software, o desenvolvimento de software ainda hoje possui problemas em aberto relacionados com a maneira como ele é desenvolvido. Isso se deve à crescente complexidade inerente ao software na atualidade. Um alto nível de dificuldade é observado através do esforço realizado na sua construção utilizando técnicas centradas na escrita de código fonte (KLEPPE; WARMER; BAST, 2003). Uma alternativa para este problema é a aplicação de técnicas de engenharia guiada por modelos (do inglês Model Driven Engineering, ou MDE) que apresentam metodologias para desenvolvimento de software focando na criação de modelos ao invés de código-fonte. Na MDE, os modelos são partes importantes do software tanto quanto o código, e não servem somente como guia para auxiliar os passos do desenvolvimento. Sua proposta é diminuir a interação manual com o código-fonte, i.e. escrita manual de código utilizando linguagens de programação, possibilitando aos desenvolvedores trabalhar em um nível mais elevado de abstração evitando as preocupações com as especificações necessárias para implementação dos requisitos em diferentes plataformas ou tecnologias (FRANCE; RUMPE, 2007). Para a criação de modelos se faz necessária a utilização de uma ferramenta de modelagem. Para possibilitar a análise automática através de um computador, os modelos criados por estas ferramentas devem ser semanticamente corretos e completos. Neste sentido, os modelos servem de entrada para transformações que irão gerar outros modelos e/ou o código-fonte do software em desenvolvimento (FRANCE; RUMPE, 2007). Para efetuar as transformações entre modelos se utiliza o conceito da metamodelagem que é seguido pela OMG (Object Management Group) e permite a definição e execução de transformações entre modelos diferentes. Sua arquitetura é dividida em quatro níveis: o primeiro nível corresponde aos dados; o segundo nível corresponde aos modelos ou meta-dados, o terceiro nível é o metamodelo onde é definida a especificação de um modelo, por fim, o quarto nível é utilizado na definição de metamodelos, ou seja, é um meta-metamodelo (BÉZIVIN, 2004). Mais detalhes serão discutidos na Seção 2.1. Um exemplo de linguagem de modelagem largamente utilizado é a Unified Modeling Language. A UML é uma linguagem de modelagem complexa que permite a

12 12 especificação de elementos de um sistema utilizando diferentes pontos de vista. Pode ser usada em diversas fases do desenvolvimento, permitindo tanto descrições com um grau de detalhamento, como especificações abstratas de um sistema. É utilizada normalmente para modelar sistemas orientados a objeto (OMG, 2009). A linguagem oferece treze diagramas diferentes: seis para a especificação estrutural e sete para a especificação comportamental. A especificação estrutural mostra a estrutura do sistema através de objetos, classes e tipo de dado. Como exemplo de diagramas estruturais podem-se citar os diagramas de classes, de pacotes e de objetos. Já a especificação comportamental preocupa-se com o comportamento dinâmico destes elementos. O comportamento pode ser dividido em duas perspectivas distintas: (i) como os elementos agem isoladamente e (ii) como eles agem em conjunto. Como exemplo de diagramas comportamentais, podem-se citar os diagramas de sequências, de atividades, de estados, entre outros (DOUGLASS, 2007). Embora estes diferentes diagramas disponíveis na UML facilitem a visualização dos recursos do sistema através de diferentes pontos de vista, esta diversidade pode levar a uma especificação ambígua. Isto é um problema, principalmente se alguma ferramenta de análise ou processamento de modelos precisar ser usada no projeto. Além disso, a UML não possui uma semântica definida para a interpretação conjunta dos vários diagramas que representam a especificação do comportamento do sistema. Consequentemente, computadores não podem executar automaticamente um modelo UML. Uma solução para isso é transformar os elementos de um diagrama UML em elementos de algum outro modelo, mais preciso e que forneça o mesmo nível de abstração sem vincular a especificação do sistema a nenhuma plataforma de implementação. Para este caso pode-se utilizar o modelo DERCS (do inglês Distributed Embedded Real-Time Compact Specifications). O DERCS é baseado em um subconjunto do metamodelo UML e do metamodelo do perfil MARTE (Modeling and Analysis of Real-Time and Embedded systems) (OMG, 2008), além do modelo conceitual de orientação a aspectos proposto por Schaeuruber (2006). Esse modelo tem por objetivo representar de uma forma precisa e sem ambiguidades as informações estruturais e comportamentais de um sistema embarcado de tempo real, usando conceitos da orientação a objetos (OO) e orientação a aspectos (OA) (WEHRMEISTER, 2009). Em sua implementação inicial, o DERCS utiliza a API de manipulação de modelos UML fornecida pela ferramenta de modelagem Magic Draw (NOMAGIC, 2010). A API

13 13 permite a manipulação dos elementos do metamodelo da UML, conforme descrito na sua especificação (OMG, 2010). Nas versões mais recentes, o Magic Draw e, consequentemente, a sua API deixaram de ser disponíveis gratuitamente para uso não comercial. Assim, somente versões mais antigas da ferramenta podem ser usadas gratuitamente. Tendo em vista este cenário, este trabalho propõe uma nova implementação do pacote Behavior (elementos que representam o comportamento de um sistema) do modelo DERCS utilizando o Eclipse Modeling Framework, que é um framework para transformações entre modelos bastante conhecido e utilizado na comunidade de códigoaberto. O EMF inclui funcionalidades como: geração de código para construção de aplicações a partir das definições de modelos, além de ferramentas para modelagem através do uso do seu próprio metamodelo, conhecido como Ecore. Este trabalho propõe uma implementação da transformação dos elementos de um diagrama comportamental da UML (i.e. diagrama de sequência) para elementos do metamodelo DERCS, conforme definido em Wehrmeister (2009). 1.1 OBJETIVOS Este trabalho tem como objetivo principal implementar todos os elementos do pacote Behavior do metamodelo DERCS utilizando o Eclipse Modeling Framework. Para que seja alcançado o objetivo geral, alguns objetivos específicos devem ser atingidos: i. aprender os conceitos de MDE, metamodelo da UML referente ao diagrama de sequências, DERCS, EMF, ATL, UML2 e Ecore. ii. implementar o modelo DERCS usando a EMF. iii. implementar a transformação dos elementos do metamodelo UML (i.e. diagramas de sequência) para os elementos do pacote Behavior do metamodelo DERCS utilizando ATL, conforme o mapeamento definido em Wehrmeister (2009) 1.2 METODOLOGIA No primeiro momento foi realizado um levantamento bibliográfico dos conceitos de Model Driven Engineering, DERCS, trabalhos correlatos, além do estudo dos elementos dos diagramas comportamentais da UML e sobre as ferramentas fornecidas no Eclipse Modeling Framework.

14 14 Após levantamento bibliográfico foi criada a especificação dos elementos comportamentais do modelo DERCS em EMF e a transformação de modelos em UML para DERCS. Depois de efetuada a transformação foi efetuada a validação dos resultados obtidos. A validação deste trabalho foi feita através de um estudo de caso. Mais especificamente o modelo UML UAV produzido em Wehrmeister (2009) foi utilizado para verificar a correção das transformações dos elementos do metamodelo da UML para os elementos do metamodelo DERCS. O mesmo modelo foi utilizado como entrada para as duas implementações do DERCS, ou seja, a implementação que usa a API da ferramenta Magic Draw desenvolvida por Wehrmeister (2009) e a implementação usando o EMF desenvolvida neste trabalho e o resultado das duas transformações foi analisado com base nas definições descritas em Wehrmeister (2009). 1.3 ORGANIZAÇÃO DO TRABALHO Este documento está dividido em seis capítulos. O primeiro capítulo, já apresentado, contém uma introdução ao trabalho proposto, apresentando uma contextualização do mesmo e seus objetivos a serem alcançados. O Capítulo 2 trata do embasamento teórico, apresentando definições sobre MDE, UML, e Ecore, necessários para o desenvolvimento do trabalho. O Capítulo 3 aborda trabalhos correlatos a este, identificando pontos comuns com este trabalho. O Capítulo 4 apresenta a modelagem do pacote comportamental do metamodelo DERCS feita na ferramenta EMF e a transformação entre os elementos do metamodelo UML para os elementos do metamodelo DERCS. O Capítulo 5 apresenta a validação deste trabalho, apresentando os resultados obtidos. O Capítulo 6 discute o tranbalho realizado, as dificuldades e desafios encontrados no desenvolvimento, o resultado obtido e trabalhos futuros.

15 15 2. CONCEITOS 2.1 MODEL-DRIVEN ENGINEERING A engenharia guiada por modelos (do inglês Model Driven Engineering, ou MDE) apresenta técnicas para desenvolvimento de software orientadas na criação de modelos ao invés da escrita manual de código-fonte. Porém, antes de iniciar a discussão sobre MDE, é preciso estabelecer o significado de modelo. De acordo com Bézivin (2004), existem diferentes definições (muitas vezes contraditórias) para a palavra modelo dependendo do contexto no qual o termo é utilizado. Segundo Rothenberg (1989), no contexto de sistemas computacionais, modelagem é a atividade de construir modelos para apresentar as especificações técnicas e/ou comportamentais de um software. Os modelos são usados para identificar características e funcionalidades que o sistema deverá ter. A MDE é uma abordagem que propõe a utilização de técnicas de transformação para o desenvolvimento de sistemas computacionais onde as implementações são geradas semi-automaticamente a partir de modelos ou especificações. Em tal abordagem, os modelos são utilizados como o principal artefato durante todo o ciclo de produção (SELIC, 2003). Sua proposta principal é fazer com que o contato manual com o código-fonte seja o menor possível, deixando o esforço voltado para o desenvolvimento de modelos de mais alto-nível. Assim, o modelo deixa de ser apenas um guia, uma referência para o desenvolvimento, tornando-se parte do software assim como o código-fonte Vantagens e desvantagens do uso de MDE Dentre as vantagens descritas por Kleppe, Warmer e Bast (2003) destacam-se: Produtividade: o tempo é mais bem aproveitado, já que é utilizado para criação de modelos de mais alto nível. Tarefas repetitivas podem ser implementadas nas transformações, salvando esforço e tempo que podem ser utilizados em atividades mais importantes, além de que um único modelo pode gerar uma quantidade grande de código-fonte. Portabilidade: utilizando um mesmo modelo, pode-se gerar código para diferentes plataformas.

16 16 Manutenção e documentação: as alterações são efetuadas diretamente nos modelos, mantendo a consistência dos mesmos com o código-fonte através da geração de código. Assim, a documentação mantem-se atualizada, o que acaba facilitando a manutenção. Ambler (2003) e Thomas (2004) destacam como desvantagens na utilização de MDE: Complexidade: a utilização de modelos requer o uso de ferramentas de modelagem, de geração e transformação, artefatos que adicionam complexidade ao processo de desenvolvimento do software. Rigidez: a maior parte do código-fonte é gerado através de modelos, ficando longe do alcance do desenvolvedor. Para pequenas modificações é necessário modificar diretamente no modelo. Desempenho: mesmo com a otimização podendo ser feita através de modelos de mais alto nível, os geradores acabam incluindo código-fonte desnecessário, podendo comprometer o desempenho Componentes da MDE Para utilizar técnicas de MDE alguns elementos são necessários no processo de desenvolvimento. A Figura 2.1 mostra os principais componentes utilizados nesta abordagem e como eles são combinados. Figura Elementos MDE (LUCREDIO, 2009)

17 17 É necessária a utilização de uma ferramenta de modelagem para a construção de modelos. Os modelos criados devem ser semanticamente corretos e completos, uma vez que podem ser analisados automaticamente por um computador. Os modelos servem de entrada para transformações que irão gerar outros modelos e/ou o código-fonte do software em desenvolvimento (FRANCE; RUMPE, 2007). Para efetuar as transformações, é necessária a construção de regras de mapeamento de transformação entre modelos e/ou de modelo para código-fonte. A ferramenta para criação destas regras deve possibilitar uma construção de forma natural, visto que a construção de transformadores é complexa. Por fim, é necessária a aplicação das regras de transformações criadas. A fim de auxiliar nestas tarefas, utiliza-se o conceito de meta-modelagem que é seguido pela OMG (Object Management Group) e apresentado na Figura 2.2. Este conceito permite a definição e execução de transformações genéricas. Figura Arquitetura de metamodelagem (LUCREDIO, 2009) Sua arquitetura é dividida em quatro níveis: o primeiro nível (M0) são os dados propriamente ditos; no segundo nível (M1) estão os modelos ou meta-dados. São os

18 18 modelos que descrevem as especificações estruturais e comportamentais de um sistema. Como exemplo, pode-se citar o modelo UML de um sistema de controle do ABS de um carro. O terceiro nível (M2) é o metamodelo, utilizado para definição de todos os elementos que compõem os modelos. Como exemplo, pode-se citar a especificação dos diagramas da UML e os elementos que compõem o metamodelo do DERCS. Por fim, o quarto nível (M3) é utilizado na definição de metamodelos, ou seja, um metametamodelo define elementos comuns para especificar linguagens de especificação de modelagem. Como exemplo, podem-se citar o meta-metamodelo MOF ou o Ecore (ver Seção 2.3.1) (LUCREDIO, 2009). Um exemplo de utilização desta definição para as abordagens da MDE é o Model-Driven Architecture (MDA) (OMG, 2004), que foi proposta pela OMG. A MDA define um sistema com foco na separação da especificação das suas funcionalidades e a especificação da plataforma tecnológica utilizada no desenvolvimento. Ou seja, os modelos criados no início do desenvolvimento não terão nenhuma dependência quanto às plataformas tecnológicas, ao invés disso, terão como escopo apenas a lógica funcional do sistema. O conjunto de normas que dão suporte a MDA são: Meta-Object Facility (MOF) (OMG, 2006), um padrão para a especificação de meta-metamodelos. Serve como base para definição de todas as linguagens de modelagem. Com a MOF, ferramentas de modelagem e transformação podem trabalhar em conjunto ou ser integradas. Unified Modeling Language (UML) (OMG, 2009), uma linguagem de modelagem de uso geral para especificação de sistemas, construída sobre o MOF. Queries/Views/Transformations (QVT) (OMG, 2008), uma norma que define os requisitos de uma linguagem para transformações entre modelos descritos utilizando a MOF. Permite a definição de regras para mapeamento entre modelos escritos em qualquer linguagem de modelagem. XML Metadata Interchange (XMI) (OMG, 2007), um padrão para a troca de informações entre metamodelos, especificada usando o dialeto XML. O XMI permite a troca de informações entre especificações baseadas em MOF como, por exemplo, a troca de modelos UML entre diferentes ferramentas de modelagem.

19 19 O MDA apresenta os conceitos de Modelo Independente de Computação (do inglês Computation Independent Model ou CIM), Modelo Independente de Plataforma (do inglês Platform Independent Model ou PIM) e Modelo Específico de Plataforma (do inglês Platform-Specific Model ou PSM) (LUCREDIO, 2009). O CIM descreve o domínio e os requisitos do sistema. O CIM consiste em um modelo do ponto de vista informacional, captando informações sobre os dados de um sistema. O CIM corresponde a uma visão do sistema de acordo com uma perspectiva que não depende de computação. O PIM descreve o funcionamento do sistema independentemente de qualquer plataforma e/ou tecnologia de implementação. Representa a funcionalidade de negócios e comportamento sem incluir aspectos técnicos. O PIM inclui: (i) um modelo do ponto de vista informacional, que capta informações sobre os dados de um sistema; e (ii) um modelo do ponto de vista computacional, que captura informações sobre o processamento de um sistema, independentemente de qualquer plataforma. O PSM descreve o funcionamento do sistema utilizando uma ou mais plataformas específicas. Assim como o PIM, o PSM pode descrever um modelo com informações sobre os dados de um sistema, e um modelo que captura informações sobre o processamento de um sistema, porém ambos baseados em uma plataforma ou tecnologia específica de implementação. Como o PSM tem como alvo uma plataforma específica, ele usa os recursos da plataforma especificados em um modelo de plataforma. Na MDA as transformações são utilizadas para converter um modelo em outro, até o código-fonte. Transformações entre CIM e PIM são menos sujeitas à automação pois envolvem maiores possibilidades de interpretação do sistema devido ao seu alto grau de abstração. Já as transformações de PSM para código-fonte são mais adequadas à automação, visto que o PSM utiliza informações detalhadas do sistema que estão mais próxima da tecnologia de implementação (LUCREDIO, 2009). 2.2 UNIFIED MODELING LANGUAGE A Linguagem de Modelagem Unificada (do inglês Unified Modeling Language ou UML) é uma linguagem para modelagem padrão para a modelagem de sistemas orientados a objetos. Permite a especificação, documentação, visualização e desenvolvimento de elementos de um sistema utilizando diferentes pontos de vista. Pode ser utilizada para modelar diversas fases do desenvolvimento, desde a

20 20 especificação da análise de requisitos até a finalização com a fase de testes, independente do sistema. Com a UML é possível modelar praticamente qualquer tipo de aplicação, rodando em qualquer tipo e combinação de hardware, sistema operacional, linguagem de programação e de rede (OMG, 2009). O objetivo da UML é auxiliar a definir as características de um sistema, como requisitos, comportamento e estrutura lógica. Isto pode ser alcançado através do uso de diagramas. Diagramas são especificações gráficas de um determinado conceito ou idéia por meio de figuras geométricas. O uso de diagramas fornecidos pela UML facilita a especificação do sistema e o seu entendimento. Ao todo são treze diagramas diferentes, divididos em diagramas para a especificação estrutural e diagramas para a especificação comportamental. O objetivo de existirem tantos diagramas é fornecer várias visões do sistema modelado, por diferentes pontos de vista, permitindo que um diagrama complete as informações de outro. É como se o sistema fosse modelado incrementalmente. Alguns diagramas tem um foco mais geral, mostrando uma visão ampla do sistema. Outros têm um foco mais específico, mostrando algumas características específicas do sistema ou de um determinado processo. Devido a isso, nem todos os diagramas são necessários para modelar um sistema (GUEDES, 2007) Especificação estrutural A especificação estrutural mostra a estruturação de um sistema, representando o aspecto estático do sistema. Há uma série de conceitos estruturais elementares na UML, como classes, objetos e tipos de dados. Estes elementos estruturais formam a base dos diagramas estruturais. A UML define seis diagramas para a especificação estrutural (GUEDES, 2007): diagrama de classe: representa a estrutura das classes do sistema modelado, demonstrando os atributos e métodos de cada classe, além dos relacionamentos entre classes. Serve de apoio para a maioria dos outros diagramas. diagrama de pacotes: utilizado para organizar o sistema em pacotes e mostrar a dependência entre eles. Um pacote representa um conjunto de classes. diagrama de componentes: utilizado para demonstrar os componentes do sistema, mostrando o relacionamento entre os componentes do software. diagrama de objetos: esta diretamente ligado ao diagrama de classes, utilizando a mesma notação. Porém, ao invés de representar as classes apresenta objetos

21 21 instanciados e as suas ligações, fornecendo uma visão dos valores armazenados por um objeto em um determinado instante da execução do sistema. Este diagrama representa a estrutura dinâmica de um sistema em termos de objetos instanciados a partir do conjunto de classes. diagrama de estrutura composta: é utilizado para modelar a estrutura interna de uma classe em termos de partes internas e portas. As interações entre as instancias das classes internas (partes) é mostrada através de portas e conectores. Adicionalmente, as portas indicam como uma classe interagem com outras classes. diagrama de distribuição: mostra as relações físicas entre os componentes de software e hardware de um sistema Especificação comportamental A especificação comportamental preocupa-se com o comportamento dinâmico dos elementos estruturais em um sistema. O comportamento pode ser dividido em duas perspectivas distintas: (i) como os elementos estruturais agem isoladamente e (ii) como agem em conjunto (GUEDES, 2007). A UML define sete diagramas para a representação comportamental de um sistema: diagrama de casos de uso, diagrama de estados, diagrama de atividades, diagrama de sequência, diagrama de visão geral de interação, diagrama de comunicação e diagrama de temporização Diagrama de casos de uso O diagrama casos de uso é utilizado durante a fase de análise de um projeto para identificar e particionar as funcionalidades de um sistema. O diagrama separa o sistema em atores e casos de uso. Os atores representam os usuários do sistema. Esses usuários podem ser humanos, outro computador, ou mesmo outros sistemas de software. Eles devem fornecer estímulos para essa parte do sistema. Graficamente, cada ator é representado por um boneco palito. Os casos de uso descrevem o comportamento do sistema quando um ator envia um estimulo particular para este sistema. Esse comportamento é descrito textualmente e descreve a natureza do estimulo que desencadeia o caso de uso. Os casos de uso são representados graficamente por elipses com o seu nome abaixo ou dentro da elipse. Atores e casos de uso são conectados por linhas que representam relacionamentos de associação, dependência e generalização. A Figura 2.3 apresenta um diagrama de casos de uso.

22 22 Figura 2.3 Exemplo de diagrama de caso de uso Diagrama de sequência O diagrama de sequência é uma representação gráfica da interação entre os objetos envolvidos em um determinado cenário de execução do sistema. Neste diagrama a colaboração dinâmica entre os objeto é mostrada enfatizando a perspectiva temporal (ou sequencial) na qual essa interação acontece. A comunicação entre os objetos é feita através da troca de mensagens. Por mensagem entende-se: (i) a solicitação (por parte de um objeto que envia a mensagem) de execução de alguma tarefa a ser desempenhada por algum outro objeto (i.e. o objeto que recebe a mensagem); ou (ii) a resposta a alguma mensagem de solicitação previamente enviada. Uma mensagem implica na existência de uma operação no objeto receptor, a qual será executada após o recebimento da mensagem de solicitação, e, opcionalmente, a existência de uma mensagem resposta do objeto receptor para o objeto solicitante indicando o término da execução desta operação. Existem quatro tipos de mensagens (GUEDES, 2007): mensagens síncronas: o objeto que envia uma mensagem aguarda até o fim do processamento da mensagem pelo objeto receptor para então continuar sua execução;

23 23 mensagens assíncronas: o objeto envia uma mensagem e continua o seu fluxo de execução, sem aguardar o fim do processamento da mensagem pelo objeto receptor; mensagens reflexivas: são enviadas de um objeto para ele mesmo, solicitando a execução de uma operação no seu contexto; mensagens de retorno: indicam o fim da execução de uma operação e seu uso é opcional. Quando construímos um diagrama de sequência, os seguintes elementos podem ser encontrados: objetos: são colocados em linha na parte superior do diagrama. São representados graficamente por um retângulo; atores: são objetos externos que interagem com o sistema através da solicitação de um determinado serviço, gerando os eventos que dão início ao processo. São representados graficamente por bonecos palito; linha de vida (lifeline): linha vertical tracejada que parte do retângulo que representa o objeto. Representa a vida de um objeto durante o cenário de execução descrito no diagrama; foco de controle: barras retangulares verticais que demonstram qual dos objetos tem o controle da execução em um determinado instante. O topo do retângulo indica o inicio da execução da operação solicitada pela mensagem e a base inferior representa o fim da execução desta operação. mensagens: linhas horizontais rotulada com o nome da mensagem (e possivelmente os seus argumentos) que partem da linha de vida do objeto emissor até o objeto receptor. Representam a troca de mensagem entre objetos; fragmentos combinados (combined fragments): retângulo que determina a área de abrangência do fragmento no diagrama. Estes fragmentos são utilizados para especificação de sequências de mensagens que tem algum comportamento especial, e.g. sequência executada caso uma condição seja verdadeira, repetição da sequência de mensagens, sequência de mensagens concorrentes, etc. A Figura 2.4 apresenta um exemplo de diagrama de sequência.

24 24 Figura Exemplo de diagrama de sequência (GUEDES, 2007). Para finalizar a discussão sobre o diagrama de sequências, é importante destacar que o passar do tempo é representado através da leitura do diagrama no sentido vertical de cima para baixo Diagrama de atividades O Diagrama de Atividade se preocupa em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes representando um método com certo grau de complexidade, ou então um processo completo do sistema. Entende-se por atividade um conjunto de ações que deve ser executado em sequência ou em paralelo, obedecendo a um fluxo de controle (GUEDES, 2007) Diagrama de estados Os diagramas de estado são utilizados para descrever todos os possíveis estados de um objeto, ajudando na compreensão de funcionalidades complexas do sistema ou o fluxo de negócios de áreas especializadas do sistema. O diagrama mostra os vários estados que um objeto pode entrar e as transições que ocorrem entre os estados. Além disso, pode-se usar o diagrama de estados para representar o comportamento global, em termos de estados e suas transições, de um sistema ou subsistema. Geralmente, este tipo

25 25 de diagrama é utilizado em sistemas onde os diferentes estados de uma aplicação são facilmente reconhecidos, como sistemas de controle ou sistemas de tempo real (GUEDES, 2007) Diagrama de visão geral de interação O diagrama de visão geral de interação é uma variação do diagrama de atividades, utilizando os mesmos elementos. Ele apresenta o fluxo de controle de um sistema de uma forma geral e pode conter dentro de cada atividade outro(s) diagrama(s) de interação (GUEDES, 2007) Diagrama de comunicação O diagrama de comunicação descreve a interação entre objetos em um sistema, através de mensagens. Segue o estilo do diagrama de sequência, porém sem se preocupar com o aspecto temporal do processo, concentrando-se apenas em como os objetos interagem e quais mensagens são trocadas durante o processo (GUEDES, 2007) Diagrama de temporização O diagrama de temporização é utilizado para explorar os comportamentos de um ou mais objetos ao longo de um determinado tempo. É uma forma especial de um diagrama de sequência, onde o foco principal está em demonstrar como os objetos se comportam (ou mudam) com o passar do tempo. Este diagrama modela iteração e evolução de estados, sendo utilizado frequentemente no desenvolvimento de software embarcado, ainda que ocasionalmente tenha seu uso para outros tipos de software (GUEDES, 2007). 2.3 ECLIPSE MODELING FRAMEWORK O Eclipse Modeling Framework é um framework para especificação e transformações entre modelos bastante conhecido e utilizado na comunidade de códigoaberto. O EMF unifica três importantes tecnologias: Java, XML e UML, permitindo que modelos sejam definidos através do uso de qualquer uma destas formas (BUDINSKY; STEINBERG, 2007). Com o EMF é possível criar metamodelos através do Ecore e executar transformações entre modelos utilizando o ATL. Além disto, oferece suporte a interpretação e validação de diagramas UML através do componente UML2 (ver Seção 2.3.3).

26 Ecore Para definir um modelo é preciso uma terminologia comum para descrevê-lo. Para utilizar as ferramentas de modelagem e geração do EMF precisa-se de um modelo com essas informações, um modelo para descrever modelos EMF, ou seja, um metamodelo. O metamodelo utilizado para representar modelos no EMF é chamado de Ecore. O Ecore é em si um modelo EMF e, portanto, é o seu próprio metamodelo. Seus padrões são baseados no MOF (ver Seção 2.1.2). O metamodelo Ecore contém as informações sobre definições das classes do modelo (BUDINSKY; STEINBERG, 2007). A Figura 2.5 apresenta os elementos do metamodelo Ecore. Figura 2.5 Elementos do metamodelo Ecore (DIAS, 2009). Seus principais elementos são: EClass: utilizado para representar uma classe modelada. EAttribute: utilizado para representar um atributo modelado. EReference: utilizado para representar um lado de uma associação entre classes EDataType: utilizado para representar o tipo de dado de um atributo.

27 27 Na Figura 2.6 pode ser visualizado um exemplo de um modelo criado utilizando o Ecore. Este modelo representa um fragmento do modelo criado para este trabalho. Figura 2.6 Exemplo modelo Ecore ATL A ATL (do inglês Atlas Transformation Language) é uma linguagem de transformação de modelos híbrida, ou seja, uma mistura de construções declarativas e imperativas e permite especificar qualquer transformação seja de modelos PIM para PSM, PIM para PIM, ou de PSM para PSM. Estas transformações permitem que outros modelos possam ser gerados a partir de um modelo de origem. Uma transformação utilizando ATL é composta de regras que definem como os elementos do modelo de origem são combinados para criar e inicializar os elementos do(s) modelo(s) de destino. É equivalente à linguagem QVT do OMG (BUDINSKY; STEINBERG, 2007). As transformações entre modelos são descritas nos módulos ATL (ATL modules). Nestes módulos são caracterizadas as regras que mapeiam as transformações dos modelos de origem para elementos do modelo de destino. Uma transformação ATL pode ser decomposta em três partes (BUDINSKY; STEINBERG, 2007): cabeçalho(header): utilizado para declarar as informações gerais, tais como o nome do módulo (nome da transformação que deve corresponder ao nome do arquivo), o metamodelo de entrada e o de saída, além da importação das bibliotecas necessárias para a transformação. assistentes(helpers): são sub-rotinas utilizadas para evitar a redundância de código.

28 28 deste trabalho. regras(rules): descrevem como elementos de saída (baseados no metamodelo de saída) são produzidos a partir de elementos de entrada (baseados no metamodelo de entrada). São construídos por associações entre um elemento de entrada e um elemento de saída. Existem três tipos de regras, que representam os dois diferentes tipos de construções disponíveis no ATL: a. matched rule: corresponde a programação declarativa e é o principal componente de uma transformação ATL. Descreve para qual tipo de elemento do modelo de destino será gerado um elemento do modelo de origem. Não aceita parâmetros. b. lazy rule: corresponde a programação imperativa e é estruturalmente idêntica a matched rule, porém só é executada quando invocada por outra rule. É obrigatório informar o elemento do modelo de origem. c. called rule: corresponde a programação imperativa e assim como a lazy rule somente é executada quando invocada por outra rule. Diferente da matched rule aceita parâmetros e como não faz correspondência entre elementos de diferentes modelos não inclui o elemento do modelo de origem. A Tabela 1 apresenta um trecho de código ATL, retirado da implementação Tabela 1 Exemplo código ATL. 1 module Behavior; 2 create OUT : BehaviorEcore from IN : UML2; 3 4 helper context UML2!Message def : isreturnaction () : 5 Boolean = self.messagesort.tostring() = 'reply'; 6 7 rule Interaction{ 8 from 9 f : UML2!Interaction (not f.isjpddinteraction()) 10 to 11 t : BehaviorEcore!Behavior( BehavioralElement<-f.fragment->iterate( 14 e;mes : OrderedSet(UML2!Element)=OrderedSet{} if e.getmessage().isreturnaction() then 17 mes->including(thismodule.getreturnaction(e.getmessage())) endif )) 19 }

29 lazy rule getreturnaction{ 22 from 23 f : UML2!Message 24 to 25 t : BehaviorEcore!ReturnAction( 26 Name <- f.name.tostring() 27 ) 28 } Nas linhas 1 e 2 pode ser observado o cabeçalho(header) onde é feita a declaração do módulo e a inicialização das variáveis relacionadas ao modelos de origem e destino utilizados na transformação. A variável BehaviorEcore referencia o modelo de saída e a variável UML2 referencia o modelo de entrada. Nas linhas 4 e 5 temos um assistente (helper) que é utilizado para verificar se o elemento do modelo de origem é um elemento ReturnAction do modelo de destino. Nas linhas 7 a 28 temos um exemplo de regra (rule). A mached rule Interaction identifica um elemento Interaction do modelo de origem e o transforma em um elemento Behavior do modelo de destino. Na linha 17 é feita a chamada a lazy rule getreturnaction que adiciona aos elementos do Behavior criado um elemento ReturnAction UML2 A UML2 é uma implementação do metamodelo UML 2.x da OMG utilizando EMF, mais especificamente o Ecore, permitindo que elementos da especificação da UML 2.x da OMG possam ser utilizados em transformações entre modelos especificados usando o Ecore. Os objetivos desse componente são: (i) fornecer uma implementação do metamodelo da UML para suportar o desenvolvimento de ferramentas de modelagens; (ii) um schema XMI comum para facilitar o intercâmbio de modelos.

30 30 3. TRABALHOS CORRELATOS Alguns trabalhos correlatos foram identificados com o objetivo de analisar suas características e compará-las com o trabalho realizado. Cobe (2004) propõe uma ferramenta MDA para obter modelos PSM, chamada Janaina. O autor propõe a integração de diagramas dinâmicos, em específico os diagramas de sequência, ao paradigma MDA. A ferramenta é divida três módulos: (i) o Parser, responsável por interpretar o modelo de entrada e produzir um modelo PIM, (ii) o ModelBuilder, que faz a transformação de modelos PIM para modelos PSM e (iii) e por último o CodeGenerator, responsável por ler os modelos em PSM e transformá-los em códigofonte. O autor encoraja que o formato do arquivo intermediário utilizado no módulo Parser seja XML, para que se tenha uma padronização de ferramentas que efetuem esse tipo de transformação. Bordbar e Staikopoulos (2007) apresentam uma transformação de diagramas de atividades em metamodelo BPEL4WS, que são metamodelos que dão suporte a modelagem de processos de negócios em Web Services. Para fazer a transformação de diagramas de atividade para BPEL4WS, os autores introduzem um conjunto de regras, utilizando a linguagem OCL para especificá-los, diferentemente deste trabalho que tem como objetivo utilizar a linguagem ATL para especificar as regras de transformações entre modelos. Knapp e Merz (2008) apresentam a ferramenta chamada HUGO, onde a técnica de verificação de modelos é aplicada para relacionar máquinas de estados UML e diagramas de interação. A verificação de modelos é usada para garantir que a execução do sistema (especificado usando diagramas de atividades) pode ser especificada também por um conjunto de interações entre máquinas de estado. Os autores propõe que como diagramas de máquinas de estado podem especificar o comportamento de um objeto em detalhes, pode-se gerar código-fonte através destes modelos, sem converter para outro modelo, aumentando a precisão do sistema resultante. Gogolla e Kollmann (2001) fazem uma engenharia reversa, introduzindo um metamodelo para retirar dados de um arquivo de código-fonte escrito em linguagem Java para gerar diagramas de colaboração. O metamodelo proposto é baseado na especificação da linguagem Java e foca nas partes que são necessárias para gerar um diagrama de colaboração. Os dados extraídos do código-fonte podem ser representados

31 31 como uma instância do metamodelo, que serão utilizados posteriormente na geração do diagrama. Depois de criada a instância do metamodelo, um conjunto de regras é aplicado para especificar como usar as informações representadas por ele para gerar o diagrama almejado. Chauvel e Jézéquel (2005) propõem materializar os vários pontos de variação semântica de diagramas de estados no próprio diagrama para evitar a codificação das escolhas semânticas nas ferramentas de modelagem. Um ponto de variação semântica em um metamodelo fornece intencionalmente um grau de liberdade para a interpretação semântica do metamodelo. Seguindo o conceito de MDA, estes modelos são processados como um modelo de entrada PIM para fornecer um modelo alvo PSM, onde toda a escolha de semântica e implementação ficam explícitas. O modelo gerado pode servir de base para geração de código, simulação ou verificação de modelos. 3.1 DISCUSSÃO Diferentes aplicações do uso de metamodelagem e diagramas comportamentais foram identificados através de pesquisa em trabalhos correlatos. Sendo assim, essas características serviram de base para determinar a relação entre os trabalhos correlatos e esse trabalho. A Tabela 2 apresenta as vantagens e desvantagens identificadas para cada trabalho apresentado. Tabela 2. Vantagens e desvantagens trabalhos correlatos Trabalho Vantagem Desvantagem Cobe (2004) Uso de um formato padrão Utilizar somente um para os modelos diagrama comportamental. intermediários. Knapp e Merz (2008) Verificação de modelos Limitação ao uso de pela ferramenta. diagramas de interação. Bordbar e Staikopoulos Transformação entre Utilizar somente diagrama (2007) modelos. de atividades. Gogolla e Kollmann (2001) Possibilita a geração de Geração de diagramas só e diagramas através do possível através de códigofonte código-fonte. escrito em linguagem Java.

32 32 Chauvel e Jézéquel (2005) Liberdade para a interpretação semântica de um diagrama. Não possui suporte ao UML 2.0 Como ponto positivo destes trabalhos pode-se destacar o uso de diagramas comportamentais para modelar um sistema ou parte dele. De forma semelhante, este é o primeiro ponto importante também abordado por este trabalho. O uso de um formato padrão para os modelos intermediários sugerido por Cobe (2004) é interessante por que facilita a integração das informações entre ferramentas. Destaca-se a verificação de modelos realizada pela ferramenta desenvolvida por Knapp, Merz (2008), uma vez que um modelo nem sempre está bem especificado, o que acarreta em problemas no desenvolvimento. Adicionalmente, o modelo desenvolvido por Chauvel, Jézéquel (2005) permite a verificação de modelos, possibilitando a materialização dos pontos de variação semântica de um diagrama, o que garante uma liberdade para a interpretação da semântica de um diagrama. Bordbar e Staikopoulos (2007) apresentam uma transformação de diagramas de atividades em metamodelo BPEL4WS utilizando a linguagem OCL para especificar as regras de transformação.a engenharia reversa proposta por Gogolla, Kollmann (2001) ajuda na geração um diagrama mesmo possuindo somente o código-fonte do software. O ponto negativo desta ferramenta é gerar somente diagramas de comunicação e somente através de código-fonte escrito em linguagem Java.

33 33 4. IMPLEMENTANDO O PACOTE BEHAVIOR DO MODELO DERCS UTILIZANDO EMF/ATL 4.1 DERCS Apesar do grande número de diagramas disponíveis na UML facilitarem a visualização de diferentes características do sistema, essa diversidade de diagramas pode levar a uma especificação ambígua devido à sobreposição e duplicação de informações. Além disso, a UML é considerada uma linguagem semiformal devido à falta de semântica formal para definir a interpretação das informações de especificação do sistema, que está geralmente espalhada em diversos diagramas (GUEDES, 2007). Consequentemente, os computadores não podem analisar ou executar modelos UML automaticamente. Uma solução para isso é transformar os elementos de um ou mais diagramas UML em elementos de algum outro modelo mais preciso e que forneça o mesmo nível de abstração sem vincular a especificação do sistema a nenhuma plataforma de implementação. Porém, esta transformação só tem sentido se este outro modelo fornecer um metamodelo mais preciso comparado ao metamodelo da UML. O modelo DERCS (do inglês Distributed Embedded Real-Time Compact Specifications) pode ser utilizado para este caso. Além do modelo conceitual de orientação a aspectos proposto por Schaeuruber (2006), o DERCS baseia-se em um subconjunto do metamodelo UML e do metamodelo do perfil MARTE (Modeling and Analysis of Real-Time and Embedded systems) (OMG, 2008). O modelo em questão tem por objetivo representar de uma forma precisa e sem ambiguidades as informações estruturais e comportamentais de um sistema embarcado de tempo real, usando conceitos da orientação a objetos (OO) e orientação a aspectos (AO) (WEHRMEISTER, 2009). O metamodelo DERCS define um sistema embarcado distribuído de tempo real como um conjunto de objetos que interagem entre si para fornecer a funcionalidade esperada do sistema. Os objetos representam os componentes de hardware e software. O comportamento do sistema é representado pelas ações e interações realizadas pelos objetos. Existem dois tipos de objetos: (i) objetos ativos, que são entidades autônomas que tem o seu próprio controle de fluxo (i.e. uma thread específica), permitindo que ações concorrentes possam ser executadas em paralelo com outros objetos ativos; (ii)

34 34 objetos passivos, que são aqueles que executam ações em sequência em resposta a mensagens recebidas de outro objeto (passivo ou ativo). Podem ser vistos como entidades que fornecem informações e serviços úteis a objetos ativos. A Figura 4.1 mostra os elementos comportamentais do metamodelo DERCS modelado utilizando a ferramenta Magic Draw. Figura 4. 1 Elementos comportamentais do metamodelo DERCS: Magic Draw (WEHRMEISTER, 2009). A classe behavior contém ações que devem ser executadas sequencialmente, uma após a outra. É composto de elementos comportamentais, que podem ser actions ou outros behavior, e local variables. Action representa as ações executadas dentro do contexto de um comportamento. Uma action é atômica, ou seja, após o inicio de sua execução não pode ser interrompida até o final de sua execução. Local variable representa as variáveis locais que podem ser criadas no âmbito de um comportamento. Um comportamento pode ser acionado em resposta a mensagens recebidas de outros objetos, ou seja, um comportamento pode ser visto como a execução de uma sequência de ações que começam em resposta a chamada de um método. O DERCS define o seu modelo de ações baseado no metamodelo da UML, provendo ações independentes de plataforma como:

35 35 AssignmentAction representa uma ação de atribuição de um valor a uma variável local ou um atributo de um objeto; ActionWithOutput subclasse de Action, representa ações que produzem resultado como consequência de sua execução; ExpressionAction subclasse de ActionWithOutput, representa ações que avaliam expressões matemáticas ou booleanas; ModifyStateAction representa ações que realizam uma transição de estado de um objeto; ObjectAction representa uma ação realizada sobre um objeto. Duas ações podem ser atribuídas a objetos: (i) CreateObjetcAction, que representa a ação de criar uma instância de uma classe, (ii) DestroyObjectAction, que representa a ação de destruir uma instância de uma classe; ReturnAction representa uma ação que retorna um valor a partir de um método; ArrayAction representa ações que lidam com arrays, tais como (i) InsertArrayElementAction, que representa a ação de inserção de um elemento em um array, (ii) RemoveArrayElement, que representa a ação de remoção de um elemento de um array. (iii) ArrayLenghtAction representa a informação de retorno com o tamanho do array; SendMessageAction representa a ação de envio de mensagem para outro objeto. O DERCS define que comportamentos poder ter pré e pós-condições que devem ser mantidas respectivamente antes e depois da execução da sequência de ações. Précondições indicam que os comportamentos iniciam a execução de suas ações somente se a expressão booleana for verdadeira; pós-condições indicam que o comportamento repete a execução da sequência de ações até que a expressão booleana se torne verdadeira. Comportamentos também podem ser executados em resposta a ocorrência de eventos. Um evento é associado a um objeto que contém métodos capazes de lidar com este evento. Assim, quando ocorre um evento, ele dispara uma ação de envio de mensagem para um dos métodos de um objeto associado a este evento. O DERCS define dois tipos de eventos: (i) externos e (ii) internos.

36 36 Os eventos externos indicam as ocorrências que acontecem no ambiente externo no qual o sistema está inserido. Os eventos internos são detecções de ocorrências durante a execução do sistema, como: SendMessageEvent, que representa um evento que ocorre quando uma mensagem é enviada de um objeto para outro; ReceiveMessageEvent, que representa em evento que acontece quando uma mensagem é recebida por um objeto; StateEvent, que representa um evento relacionado ao estado de um objeto. Existem três tipos de eventos de estado: (i) ExitStateEvent, que representa um evento que acontece quando um objeto sai de um estado, (ii) EntryStateEvent, que representa um evento que acontece quando o objeto entra em um novo estado e (iii) StateTransitionEvent, que representa a mudança de estado de um objeto. Além disso, eventos especificam disparos sequenciais e paralelos. Disparos sequenciais indicam que o comportamento do objeto disparado deve manter a execução até que o comportamento em execução termine. Já os disparos paralelos indicam que o comportamento do objeto associado pode iniciar sua execução concorrentemente com os outros comportamentos em execução. 4.2 DERCS EMF Em sua implementação inicial, o DERCS utiliza uma API de manipulação de modelos fornecida pela ferramenta de modelagem Magic Draw (NOMAGIC, 2010). A API permite a manipulação dos elementos do metamodelo da UML, conforme descrito na sua especificação (OMG, 2010). Em suas novas versões, o Magic Draw e, consequentemente, a sua API deixaram de ser disponíveis gratuitamente, ficando somente versões mais antigas disponíveis para uso gratuito. Para este trabalho, a modelagem dos elementos comportamentais do DERCS apresentados na Figura 4.1 foi refeita utilizando o Eclipse Modeling Framework. A Figura 4.2 mostra os elementos comportamentais do DERCS modelados com a ferramenta EMF.

37 Figura Elementos comportamentais do metamodelo DERCS: EMF 36

38 37 Por se tratar de uma ferramenta que utiliza, na maior parte do tempo, editores gráficos para criar o metamodelo, o uso da ferramenta Eclipse Modeling Framework para especificar o metamodelo DERCS ocorreu sem grandes dificuldades. Todas as classes e suas relações foram facilmente criadas apenas clicando no ícone da barra de ferramentas que representa o item a ser criado e arrastando para a tela onde o metamodelo está sendo desenhado. A Figura 4.3 apresenta o ambiente do editor gráfico do EMF. Figura 4.3 Editor gráfico EMF. Para criar a representação de uma classe basta clicar no ícone correspondente as classes (EClass) e clicar novamente no espaço reservado para a modelagem. Os atributos das classes (EAttribute) são adicionados clicando no espaço reservado para atributos na classe em que se deseja adicionar uma propriedade. Para criar as relações entre as classes, basta clicar no ícone que representa as relações (EReference) e clicar nas duas classes que se deseja estabelecer a ligação no modelo. Para especificar o modelo no EMF, utilizou-se neste trabalho o modelo criado anteriormente utilizando a ferramenta Magic Drawn, além da documentação JavaDoc do código-fonte original do metamodelo DERCS. Essas informações foram suficientes para construção da versão

39 38 inicial do novo metamodelo. Todas as trinta e quatro classes do metamodelo original e suas relações foram criadas nesta nova implementação. 4.3 TRANSFORMAÇÃO DE MODELOS UML PARA MODELO DERCS EMF O metamodelo DERCS pode representar o comportamento de um sistema de uma forma mais sucinta que o metamodelo UML. O DERCS utiliza menos elementos para representar a mesma informação (i.e. comportamento do sistema) em comparação a UML, que utiliza diferentes elementos para representar características semelhantes. Neste sentido não existe uma relação direta entre muitos elementos do metamodelo DERCS com os elementos do metamodelo UML. Assim, para efetuar uma transformação de um modelo UML para um modelo DERCS algumas verificações precisam ser feitas. Estas verificações são definidas nas regras que mapeiam os elementos do diagrama UML para elementos do metamodelo DERCS. Este trabalho implementa a transformação dos elementos de um diagrama de sequência da UML para os elementos comportamentais do metamodelo DERCS, conforme definido em Wehrmeister (2009). Para efetuar a transformação dos elementos de um metamodelo UML para elementos de um metamodelo DERCS EMF foi utilizada a linguagem ATL, já descrita no Capítulo 2.3.2, o código-fonte do DERCS original e o diagrama UML de estudo de caso UAV utilizado em Wehrmeister (2009). Algumas verificações no código-fonte das transformações são efetuadas para identificar qual elemento do metamodelo DERCS EMF será gerado a partir de um elemento do metamodelo UML. A Tabela 3 abaixo mostra um exemplo de transformação definida neste trabalho, mais especificamente a regra responsável pela geração do elemento Behavior do metamodelo DERCS EMF. Tabela 3 Exemplo regra Behavior ATL. 1 rule Interaction{ 2 from 3 f : UML2!Interaction (not f.isjpddinteraction()) 4 to 5 t : BehaviorEcore!Behavior( 6 Name <- if f.message.assequence().at(1).signature.oclisundefined() then 7 f.message.assequence().at(1).receiveevent.covered.assequence().at(1).represents. 8 type.name.tostring() 9 else 10 f.message.assequence().at(1).signature.class.name.tostring() + '.' + 11 f.message.assequence().at(1).signature.name.tostring() + '()' 12 endif

40 39 13,BehavioralElement <- f.fragment->iterate(e; mes : OrderedSet(UML2!Element) = OrderedSet{} 14 if e.oclistypeof(uml2!messageoccurrencespecification) then 15 if e.event.oclistypeof(uml2!callevent) or e.event.oclistypeof(uml2!creationevent) then 16 if e.getmessage().isreturnaction() then 17 mes->including(thismodule.getreturnaction(e.getmessage())) 18 else if e.getmessage().isassignaction() then 19 mes->including(thismodule.getassigmentaction(e.getmessage())) 20 else if e.getmessage().iscreateobjectaction() then 21 mes->including(thismodule.getcreateobjectaction(e.getmessage())) 22 else if e.getmessage().isexpressionaction() then 23 mes->including(thismodule.getexpressionaction(e.getmessage())) 24 else if e.getmessage().signature.class.name.tostring() + '.' + 25 e.getmessage().signature.name.tostring() + '()' = t.name then 26 Mes 27 else 28 mes->including(thismodule.getsendmessage(e.getmessage())) 29 endif 30 endif 31 endif 32 endif 33 endif 34 else 35 Mes 36 endif Na linha 1 está definida o nome da regra. As linhas 2 e 3 definem o elemento de origem, neste exemplo uma interação do diagrama UML. Nas linhas 4 e 5 é definido o elemento de destino. A partir da linha 13 é iniciada a verificação dos elementos do modelo de origem. Na linha 14 é verificado se o elemento do modelo de origem que está sendo analisado é uma mensagem. Caso seja, nas linhas é analisando através de suas propriedades qual o elemento do modelo de destino correspondente. Todas as regras de transformação do pacote comportamental do DERCS foram implementadas em ATL. Por utilizar uma ferramenta específica para a transformação entre modelos, houve uma redução considerável de linhas de código-fonte. Isto foi constatado nas transformações implementadas neste trabalho em relação a quantidade de linhas de código-fonte da implementação original do DERCS que foi feita em linguagem Java utilizando a API Magic Drawn. A implementação das transformações deste trabalho foram escritas em 268 linhas de código-fonte e as transformações da implementação original foram escritas em aproximadamente 1300 linhas de código-fonte.

41 40 A reprodução do metamodelo DERCS utilizando o EMF ocorreu sem grandes dificuldades, porém alguns obstáculos, como o mapeamento dos elementos da UML, foram encontrados no desenvolvimento das transformações utilizando a ATL devido ao pouco conhecimento desta linguagem. Este foi um dos grandes desafios deste trabalho. Talvez, com um maior tempo disponível para aumentar o conhecimento na linguagem, possa ser possível efetuar melhorias no código, simplificando-o e/ou até melhorando seu desempenho.

42 41 5 ESTUDO DE CASO 5.1 VALIDAÇÃO A validação dos resultados obtidos na transformação foi feita através da comparação entre os elementos gerados pelo DERCS e o DERCS EMF utilizando o estudo de caso UAV desenvolvido em Wehrmeister (2009). O modelo UML UAV foi utilizado para a transformação no modelo DERCS EMF e DERCS original. O resultado da transformação utilizando a implementação original do DERCS foi comparado manualmente ao resultado da transformação feita utilizando o DERCS original, comparando quantidade de elementos gerados em ambas as implementações. Como mencionado anteriormente, a UML tem várias maneiras diferentes para especificar o comportamento de um sistema. O DERCS propõe uma forma mais simplificada para a representação do comportamento de um sistema comparado ao metamodelo UML. Por esta razão não existe um mapeamento direto um-para-um a partir dos elementos do metamodelo UML para os elementos comportamentais do metamodelo DERCS. Assim, é necessário efetuar algumas interpretações do comportamento extraído de diagramas UML. Para ilustrar esta interpretação deve-se considerar o diagrama de sequência apresentado na Figura 5.1. Figura Interação Movement Encode (WEHRMEISTER, 2009).

43 42 A mensagem 1: MovementEncoder.run() possui cinco mensagens aninhadas (i.e. mensagens 2, 3, 4, 5 e 6). Um elemento Behavior do metamodelo DERCS EMF contendo três elementos SendMessageAction (referente as mensagens 2, 4 e 5) e dois elementos ReturnAction (referente as mensagens 3 e 6) é criado e associado ao método representado pela mensagem. Na Figura 5.2 é possível visualizar os elementos da interação Movement Encode, apresentada na Figura 5.1, em UML2. Figura 5.2 UML2 interação Movement Encode (WEHRMEISTER, 2009).

44 43 O elemento 1 Lifeline representa o elemento movencode:movementencoder. Os elementos 2-5 representam a mensagem 2:getRotation() e os elementos 6-9 representam a mensagem 3:rotation. A ATL gera por padrão como resultado da transformação um arquivo em formato XMI. A Tabela 4 mostra o resultado da transformação da interação apresentada na Figura 5.1. Neste arquivo estão definidos os componentes do DERCS e cada um desses elementos recebe seu equivalente do estudo de caso. O código fonte da transformação da interação Movement Encode e das transformações implementadas neste trabalho podem ser observados na Seção 4.3 e no anexo B deste documento, respectivamente. Tabela 4 - Resultado da transformação Interação Movement Encode. 1 <behavior:behavior Name="MovementEncoder.run()"> 2 Name="MovementSensorDriver.getRotation()"/> 3 <BehavioralElement xsi:type="behavior:returnaction" Name="rotation"/> 4 Name="MovementEncoder.encodeRotation()"/> 5 Name="MovementSensorDriver.getPace()"/> 6 <BehavioralElement xsi:type="behavior:returnaction" Name="pace"/> 7 <BehavioralElement xsi:type= behavior:sendmessageaction Name= MovementEncoder.encodePace() /> 8 </behavior:behavior> É importante ressaltar que fragmentos combinados também são considerados na análise dos diagramas de sequência no momento das transformações. Fragmentos combinados representam uma sequência de mensagens que possuem um comportamento específico, ou seja, podem representar interações condicionais ou repetições. Quando um fragmento combinado é detectado, um novo elemento Behavior é criado. Todas as ações criadas a partir de mensagens que estão delimitadas pelo fragmento combinado são inseridas aos elementos relacionados ao Behavior criado. A Figura 5.3 apresenta um exemplo de diagrama de sequência com fragmento combinado.

45 44 Figura Fragmento combinado (WEHRMEISTER, 2009). A mensagem 1: WindSensorDriver.getWindSpeed() contém duas mensagens aninhadas, além de um fragmento combinado. Com isto um elemento Behavior do metamodelo DERCS EMF contendo um elemento AssigmentAction (relacionado a mensagem 2), um elemento ReturnAction (relacionado a mensagem 5) e um elemento Behavior para representar o loop do fragmento combinado contendo dois elementos AssigmentAction (representando as mensagens 3 e 4) é criado e associado ao método representado pela mensagem. Na Figura 5.4 é possível visualizar os elementos da interação General Behavior, apresentada na Figura 5.3, em UML2.

46 45 Figura 5.4 UML2 interação General Behavior (WEHRMEISTER, 2009). O elemento 1 Lifeline representa o elemento swind:windsensordriver, os elementos 2-5 representam a mensagem 2:ASSIGN(INT X, 100), o elemento 6 Combined Fragment representa o fragmento combinado loop e os elementos 7-10 representam a mensagem 3:ASSIGN(x, x+i*3). A Tabela 5 abaixo mostra a regra executada na transformação da interação General Behavior apresentada na Figura 5.3. Tabela 5 Regra transformação fragmento combinado 1 rule Interaction{ 2 from 3 f : UML2!Interaction (not f.isjpddinteraction())