Interação entre MDA e PMBOK para Suporte aoDesenvolvimento de Aplicações Complexas

João Marco C. Silva, Thiago L. Feitoza, Marcel L. Oliveira,Paulo E. Osses, Thiago F. Freire, Rogério P. C. Nascimento

∗

Universidade Federal de SergipeSergipe, Brasil

joaomarco@dcomp.ufs.br, {tfeitoza, marcel.ufs, paulo.darc}@gmail.comfraga_ufs@yahoo.com.br, rogerio@ufs.br

ABSTRACTModel-Driven Architecture (MDA) is a development metho-dology where the modeling is the central focus. This mode-ling should be done in a way that is independent of a spe-cific platform. Thus, the model generated can be used todevelop the system across multiple platforms, which helpsin future maintenance, upgrades and migration of the sys-tem. In order to manage the development, the use of a guidecontaining good management practices can be applied. Theguide that can be used is the PMBOK, which can be usedfor various areas of knowledge, not only for projects of infor-mation technology. This work brings a concept of MDA andthe PMBOK, along with a proposal for integration betweenthem. Specifically, it will be addressed concepts and tecno-logies related to MDA, such as UML and CWM; the modelsdefined by MDA; the MDA lifecycle; CASE tools that sup-port this methodology; a brief description of PMBOK; asuggestion of use of MDA alongside PMBOK; and, finally,the conclusions and future work.

RESUMOModel-Driven Architecture, ou MDA, trata-se de uma me-todologia de desenvolvimento onde a modelagem e o fococentral. Essa modelagem deve ser feita de forma que sejaindependente de uma plataforma especıfica. Dessa forma,o modelo gerado pode ser utilizado para o desenvolvimentodo sistema em diversas plataformas, o que ajuda em futurasmanutencoes, atualizacoes e migracoes do sistema. De formaa gerenciar o desenvolvimento, a utilizacao de um guia con-tendo boas praticas de gerenciamento pode ser aplicada. Oguia citado trata-se do PMBOK, o qual pode ser utilizadopara diversas area de conhecimento, e nao so para proje-tos de tecnologia da informacao. Este trabalho traz uma

∗Orientador

conceituacao da MDA e do PMBOK, juntamente com umaproposta de integracao entre os mesmos. Especificamente,serao abordados conceitos e tecnologias relacionadas com aMDA, como UML e CWM; os modelos definidos pela MDA;o ciclo de vida MDA; ferramentas CASE que suportam essametodologia; uma descricao geral do PMBOK; uma sugestaode uso da MDA com o PMBOK; e, finalmente, as conclusoese trabalhos futuros.

PALAVRAS-CHAVEMDA, PMBOK, EAP

1. INTRODUÇÃOAtualmente, o rapido desenvolvimento na area da computa-cao esta diminuindo bastante o tempo necessario para tornaruma determinada tecnologia obsoleta. Empresas que visammanter seus sistemas sempre atuais gastam um tempo e es-forco consideraveis nas tarefas de atualizacao e migracao [6].Para solucionar esses problemas, surgem abordagens que vi-sam separar as funcionalidades de um sistema de sua imple-mentacao. Uma dessas abordagens e a MDA (Model-DrivenArchitecture).

A MDA e uma abordagem para o desenvolvimento de softwa-res proposta pela OMG (Object Management Group) em2001. De forma simplificada, a MDA visa, a partir do desen-volvimento de varios modelos, capturar a logica do negocioem uma forma independente de plataforma. A partir des-ses modelos, seriam utilizadas ferramentas que gerariam ocodigo do produto para uma determinada plataforma. Por-tanto, numa eventual mudanca de tecnologia, precisa-se ape-nas aplicar uma ferramenta que transforme os modelos ge-rados anteriormente em codigo para essa nova tecnologia.

Abordagens anteriores em desenvolvimento dirigido por mo-delos falharam por um fenomeno denominado “vendor lock-in”. Cada ferramenta anteriormente utilizava um formatoproprio, com um contrato de licenca restritivo [4]. Para so-lucionar esse problema, a OMG definiu um conjunto de pa-droes abertos para o desenvolvimento de software. Algunsdeles ja existentes previamente, outros elaborados especial-mente para a abordagem MDA. Por exemplo, pode-se citar:UML (Unified Modeling Language), MOF (Meta-Object Fa-cility) e XMI (XML Metadata Interchange).

Alem da utilizacao de uma metodologia de desenvolvimentocomo a MDA, e importante que haja uma gerencia do pro-cesso de desenvolvimento. A fim de organizar a pratica degerencia, foi lancado o PMBOK (Project Management Bodyof Knowlegde). O PMBOK corresponde a um guia que reuneum serie de praticas para a realizacao da gestao de projetosem diversas areas de conhecimento. Uma boa gestao de pro-cessos pode resultar em bons resultados e reducao do tempoe esforco aplicado nas tarefas de migracao e atualizacao desistemas.

As proximas secoes desse artigo estarao assim organizadas:a secao 2 tratara sobre conceitos e tecnologias utilizadas emMDA; a secao 3 abordara brevemente o PMBOK; a inte-racao entre PMBOK e MDA sera discutida na secao 4; e,finalmente, a secao 5 apresentara as conclusoes e os possı-veis trabalhos futuros.

1.1 Trabalhos relacionadosUma sugestao de criterios a serem considerados na avaliacaode ferramentas utilizadas para uma abordagem MDA, bemcomo as funcionalidades que uma ferramenta ideal apresen-taria, estao disponıveis em [6]. Em [4], e apresentado comoaplicar uma abordagem MDA no contexto de uma Enter-prise Architecture, a partir do uso de boas praticas e heurıs-ticas para se atingir o sucesso da abordagem.

Um trabalho interessante a ser citado e o [14]. Este fazum estudo aprofundado da implementacao de metodologiasageis para desenvolvimento de software (em especıfico, oScrum) em conjunto com as praticas de gerenciamento deprojetos do PMBOK. O resultado dessa combinacao e bas-tante criticada especialmente por aqueles que defendem aadocao pura de apenas um dos dois. Apesar disso, e cons-tatado que ha sim a possibilidade de utilizar ambas juntase que seus resultados sao positivos.

2. MDA: CONCEITOS E TECNOLOGIASNessa secao, serao abordados tecnologias de suporte a MDA,como MOF (Meta-Object Facility) e UML (Unified Model-ling Language). Serao apresentados tambem os varios mode-los definidos pela MDA, como CIM (Computation Indepen-dent Model) e PSM (Platform Specific Model). Posterior-mente, sera apresentado o ciclo de vida MDA e, por ultimo,algumas ferramentas CASE (Computer-Aided Software En-gineering) que suportam a MDA.

2.1 Tecnologias de suporteA OMG adota algumas tecnologias para MDA. A maioriadelas e mantida pela propria OMG. Serao abordadas algu-mas que servem para modelagem e gerenciamento de mo-delos. Sao elas: MOF, UML, CWM (Common WarehouseMetamodel) e XMI (XML Metadata Interchange). Apesarde a OMG encorajar o uso dessas tecnologias para o desen-volvimento MDA, qualquer uma delas pode ser substituıdapor uma equivalente.

2.1.1 MOF - Meta-Object FacilityMOF e uma tecnologia de meta-metamodelagem. Ela sebaseia num arquitetura de 4 nıveis de modelagem [11]. Onıvel M0 e o nıvel da informacao, dos dados propriamenteditos. O nıvel M1 e o nıvel de modelos. No nıvel M2, temos

metamodelos. E o nıvel M3 e o nıvel do meta-metamodelo,isto e, o MOF. Um bom exemplo dessa arquitetura seria umaaplicacao de acoes da bolsa de valores. No nıvel M0 estariaminformacoes sobre as empresas e os valores das acoes de cadauma. No nıvel M1 estao as definicoes do banco de dados, queindica que o nome da empresa e do tipo String. O nıvel M2contem informacoes sobre a estrutura do banco de dados,por exemplo, que uma tabela e composta de registros, quesao compostos de campos e que cada campo deve ter umtipo. Finalmente, o nıvel M3 e o modelo MOF, que englobadefinicoes para varios modelos e meta-modelos. O modeloMOF pode ser visto na Figura 1.

Figura 1: Modelo MOF

2.1.2 UML - Unified Modelling LanguageUML e uma linguagem visual de modelagem baseada noconceito de orientacao a objetos. Ela foi criada por GradyBooch, James Rumbaugh e Ivar Jacobson [8]. Atualmente,a UML foi padronizada e e mantida pela OMG. Em MDA,os modelos UML precisam estar bem definidos, para que asferramentas possam trabalhar em cima deles. Um dos con-ceitos utilizados, principalmente na abordagem Agile MDA,e o de UML executavel [10]. Uma UML executavel e umperfil UML que define semanticas de execucao para um sub-conjunto restrito da UML. Este subconjunto e computaci-onalmente completo, possibilitando a sua execucao. Essesmodelos executaveis se comportam como codigo, mas estaonum nıvel de abstracao maior, mais proximo da linguagemdo cliente.

2.1.3 CWM - Common Warehouse MetamodelCWM e uma tecnologia para a troca de metamodelos dispo-nıveis em ambientes de data warehouses entre ferramentas,plataformas e repositorios [7]. Especificado pela OMG e ba-seado em MOF, sua funcao e estender o modelo de objetosda UML, fornecendo um framework para representar meta-dados, desde os dados ate as operacoes das data warehouses.CWM permite que ambientes de dados diferentes possam secomunicar, trocando informacoes.

2.1.4 XMI - XML Metadata InterchangeXMI e um padrao de formato para a troca de modelos emetamodelos UML e baseados em MOF atraves de XML[13]. Desenvolvido pela OMG, prove um framework paradefinir, trocar, manipular e integrar dados e objetos XML.Atraves de uso de XMI, e possıvel realizar um mapeamentode MOF para XML.

2.2 Modelos definidos pela MDAA MDA possui processos estabelecidos pela OMG, cujos re-sultados de cada um dao-se como modelos diferentes. Cadamodelo possui um nıvel de independencia de maneira a pro-porcionar um melhor reaproveitamento, seja para a mesmaaplicacao em plataformas diferentes, seja para uma aplicacaodiferente que necessite de definicoes equivalentes a outraspreviamente desenvolvidas. Segundo Beydeda [3], existemquatro tipos de camadas, descritas em ordem decrescente deindependencia:

i) CIM - Computation Independent Model

ii) PIM - Platform Independent Model

iii) PSM - Platform Specific Model

iv) ISM - Implementation Specific Model

Para tornar a compreensao dos modelos mais simples, seraabordada uma analogia da geracao de codigo de programa-cao com o uso de idiomas. O que e coerente, pois um idi-oma nada mais e que um codigo utilizado pelas pessoas paraque as mesmas possam se comunicar, da mesma forma queutiliza-se codigos para comunicar as maquinas instrucoes doque deve ser executado. Adotando como exemplo, tem-seuma situacao em que uma pessoa necessita da ajuda de umaoutra e, portanto, precisa construir a oracao a ser utilizadapara se comunicar.

2.2.1 CIM - Computation Independent ModelEm uma aplicacao desenvolvida com MDA, faz-se necessariaa criacao de modelos cujas definicoes sejam independentes deestrutura e processamento do sistema [9]. Ou seja, modelosvoltados apenas a compreensao das regras de negocio. Talmodelo chama-se Computation Independent Model (CIM). Aintencao principal deste e especificar o domınio da aplicacaoa ser definida e os servicos e entidades com ela envolvidas.Compete a ele identificar requisitos do domınio, mas nao seufuncionamento interno ou especificacoes tecnicas. Trata-seapenas de uma abstracao, um conceito. Comparando com oexemplo adotado, esse modelo consiste na formacao de umaideia, uma mensagem. Essa ideia seria que a pessoa precisapedir ajuda de outra pessoa. Nenhuma palavra de idiomaalgum foi envolvida ainda. Por esse mesmo motivo, sendopuramente conceitual, e dependente da interpretacao dosdesenvolvedores (analista e especialista de negocio), e por-tanto de mapeamento complexo. Portanto, torna-se inviavelo processamento automatico da transformacao do modeloCIM para o modelo seguinte, PIM.

2.2.2 PIM - Platform Independent ModelO modelo PIM ja e capaz de descrever caracterısticas daaplicacao que nao era possıvel fazer no CIM. Por exemplo,

especificar relacoes entre propriedades de uma entidade ouas interacoes entre entidades distintas. Esse modelo se ca-racteriza, como o proprio nome indica, pela independenciade plataforma, ou seja, e tecnologicamente neutra [9]. Eprojetado para que seja capaz de definir a arquitetura queo sistema tera em qualquer plataforma que venha a ser de-finida, ainda que sem detalhes de implementacao.

Exemplificando na comunicacao abordada, tem-se como partedo modelo independente de idioma a definicao de que setrata de uma frase interrogativa (e um pedido), portantoprecisara de um elemento que atribua a interrogacao ao idi-oma a ser adotado. Tambem e necessario definir os objetosda acao (a pessoa em questao), os sujeitos (alguem a quemse pedir ajuda) e a acao propriamente dita (ajudar). Esseselementos existem em qualquer idioma, porem, abordadoscom regras diferentes. Essas regras ainda nao foram envol-vidas, tornando a construcao da ideia (a pessoa precisa pedirajuda a alguem) flexıvel aos idiomas existentes.

2.2.3 PSM - Platform Specific ModelDesignada uma plataforma, o modelo PIM sera transfor-mado em um modelo PSM. Esse modelo e capaz de descre-ver como sera desenvolvido o sistema de maneira mais espe-cıfica, ja que resultara da combinacao de especificacoes domodelo anterior com detalhes de como o sistema funcionarana plataforma em questao.

Em analogia, e a aplicacao das regras de sintaxe do idiomaem especıfico na construcao da ideia escolhida. Sendo oidioma portugues, os elementos identificados devem seguiras regras gramaticais da lıngua portuguesa. Por exemplo, oelemento a se atribuir para caracterizar o codigo (a oracao)como interrogativa seria o sımbolo (signo) “?” no final daoracao. Caso fosse escolhido o idioma espanhol, os sımbolosa utilizar seriam “¿” no inıcio, e “?” no final da oracao.

Os detalhes das plataformas sao fornecidos pelo PDM.

2.2.4 PDM - Platform Definition ModelO PDM nao e um modelo resultado dos processos MDA,mas sim um modelo que fornece os conceitos tecnicos dediferentes partes que compoe a plataforma, e os elementosque o sistema pode oferecer a aplicacao. E a partir dele quesera possıvel a transformacao de PIM para PSM. Uma vezque e escolhida a plataforma, faz-se necessario saber comoa mesma funciona e os servicos que oferece para que as de-finicoes estabelecidas no PIM possam ser realizadas.

Analogamente, o PDM seria a gramatica do idioma esco-lhido, com todas as regras especıficas.

2.2.5 ISM - Implementation Specific ModelPor fim, tendo o modelo da aplicacao ja adaptado para fun-cionar na plataforma designada, o que resta a ser feito eo codigo em si. O produto final da MDA. Este modelo etambem conhecido como ISM.

Este modelo seria, por fim, a oracao formada com a apli-cacao apropriada dos signos. “Pode me ajudar?” em por-tugues, “¿Puede usted atenderme?” em espanhol, “Pouvez-vous m’aider?” em frances, “Can You help me?” em ingles,

servem como exemplos das varias formas que a mensagem(CIM) pode tomar.

2.3 Ciclo de Vida MDAFocando no ciclo seguido pelos processos do MDA, obtem-se o seguinte esquema apresentado na Figura 2. O ciclotem seu inıcio na analise de requisitos, onde serao obtidasas informacoes de negocio a respeito da aplicacao a ser de-senvolvida. Desse processo, o resultado e o CIM. Este seratransformado em PIM com ajuda de ferramentas, mas essen-cialmente com acoes dos proprios projetistas, dada a grandecomplexidade de o sistema interpretar e mapear o modeloCIM. Apos a transformacao, o PIM resultante sera parcial,sendo ainda analisado pelos projetistas envolvidos, onde ha-verao os ajustes necessarios para entao o PIM ser definitivo.Este entao sera, com ferramentas, transformado em PSM.Este, por sua vez, sofrera novas transformacoes que geraraoo ISM (o codigo propriamente dito).

Essas duas ultimas transformacoes, a curto prazo, sao exe-cutadas pelos programadores ainda com auxılio de ferramen-tas. Futuramente, elas deverao ocorrer automaticamente [9],cabendo ao programador apenas analisar os resultados e fa-zer as modificacoes cabıveis. As vantagens fornecidas pelacriacao desses modelos sera abordada no topico “Vantagense Desvantagens”. Depois de ter o codigo pronto, ele entraem testes, dando resultados que serao levados em conside-racao na nova analise do PIM obtido para alteracoes. EssePIM modificado, passa pelas transformacoes ate chegar no-vamente no ISM, como um processo iterativo.

Figura 2: Ciclo de vida do MDA

2.4 Ferramentas CASEMuitas ferramentas CASE podem ser utilizadas para au-xiliar a MDA atraves da construcao de modelos em UMLe gerando codigo a partir deles. Para a MDA, foram en-contradas duas ferramentas especıficas que podem atuar demaneira interessante dentro dessa metodologia. Essas ferra-mentas sao o AndroMDA e a OptimalJ.

2.4.1 AndroMDASeu nome pronuncia-se andromeda. E um framework decodigo aberto que utiliza a UML para a interpretacao de

modelos e uma serie de plugins para transformacao dessesmodelos. Suas caracterısticas sao:

i) Design modular: o AndroMDA e dividido em modulosque podem ser divididos para atender as necessidadesdo usuario;

ii) Suporta o meta-modelo UML 1.4, mas o suporte ao mo-delo 2.0 ja se encontra em desenvolvimento;

iii) Suporta a inclusao de meta-modelos customizados emMOF ou XMI e geracao de codigo a partir deles;

iv) Plugins para plataformas especıficas;

v) Atualmente disponıvel na versao 3.3.

Os plugins do AndroMDA sao chamados de cartuchos (car-tridges). Cada cartucho e responsavel por transformacoespara uma determinada plataforma. Nativamente, o An-droMDA ja possui cartuchos para as plataformas Spring,JSF, Hibernate, Java, EJB 2 / 3, entre outros. A ferramentatambem possui um kit para criacao de cartuchos novos oucustomizacao dos ja existentes [2].

Apesar de ser baseado na MDA, o AndroMDA nao realizatransformacoes do modelo PIM para o modelo PSM. A fer-ramenta ja traduz do modelo PIM para codigo fonte em umadeterminado plataforma, dependendo do cartucho escolhidopara realizar a transformacao. Vale ressaltar que o modeloPIM aceito pelo AndroMDA tem que ser modelado em outraferramenta e salvo no formato .XMI. Esse modelo deve sercomposto pelo diagrama de casos de uso, o diagrama de clas-ses e o diagrama de atividades. Esses modelos ainda devemlevar em consideracao o conceito de marcas, onde os elemen-tos dos diagramas sao marcados com esteriotipos UML. Porexemplo, um caso de uso pode ser marcado com o esterio-tipo ≪ FrontEndUseCase ≫, indicando que e um caso deuso que interage com o usuario. A partir desses modelos, oAndroMDA e capaz de gerar o codigo fonte correspondente,automatizando grande parte do processo de desenvolvimento[5].

2.4.2 OptimalJA OptimalJ e uma ferramenta comercial, construıda poruma empresa chamada Compuware. Por ser construıda emcima da IDE (Integrated Development Environment) Eclipse,se caracteriza por ser um ambiente de desenvolvimento diri-gido a modelos voltado a plataforma Java. Essa ferramentapermite a criacao de modelos utilizando UML e MOF comometa-metamodelo. Se encontra atualmente na versao 4.3e tem como caracterıstica importante o fato de permitir odesenvolvimento em tres etapas, cada uma contendo um mo-delo especıfico:

i) O modelo de domınio, o qual equivale ao PIM;

ii) O modelo de aplicacao, o qual equivale ao PSM;

iii) O modelo de codigo, representado pelo codigo fonteJava.

O modelo de domınio (PIM) e representado pelo diagramade classes e o diagrama de atividades. O diagrama de classesmodelado na OptimalJ apresenta algumas restricoes, comoo fato de nao suportar a modelagem de interfaces. Com re-lacao ao diagrama de atividades, a ferramenta impoe quecada fluxo tenha que especificar o objeto que e passado deuma atividade para outra. O diagrama de casos de uso eo conceito de marcas nao sao necessarios para que a ferra-menta realize a transformacao entre o PIM e o PSM. Essatransformacao utiliza regras para mapear os elementos domodelo fonte para o modelo alvo. Vale ressaltar que ao apli-car essa transformacao, a OptimalJ insere uma arquiteturade camadas ao modelo PSM, alem de realizar o registro datransformacao, como e sugerido pela MDA [5].

Em [15] e apresentado um estudo de caso que mostra a cons-trucao de um sistema de e-commerce, especificamente o PetStore desenvolvido pela Sun para demonstrar padroes deprojeto. O estudo desenvolveu o sistema utilizando a pla-taforma .NET, a plataforma J2EE de forma manual e como OptimalJ, seguindo as etapas da MDA. A Figura 3 mos-tra uma grafico onde e possıvel ver o numero de linhas decodigo escritas manualmente em cada um dos metodos ado-tados. Dessa forma, e possıvel verificar que o numero totalde linhas de codigo que foram escritas manualmente depoisde se utilizar a OptimalJ foi consideravelmente inferior aosoutros metodos adotados, demonstrando o quanto uma fer-ramente pode auxiliar o processo de desenvolvimento.

Figura 3: Quantidade de linhas de codigo escritasmanualmente

3. PMBOK - PROJECT MANAGEMENTBODY OF KNOWLEDGE

O PMBOK e um guia editado e publicado pelo PMI (ProjectManagement Institute) que reune o que se considera ser asmelhores praticas em gestao de projetos em varias areas deconhecimento.

O guia esta na terceira edicao, publicada em 2004, e temse tornado uma referencia mundial na gerencia de projetos.O guia define o ciclo de vida do projeto por grupos de pro-

cessos, onde, em cada fase, um conjunto de atividades saoexecutadas de maneira a tornar o processo de desenvolvi-mento o mais gerenciavel possıvel.

O ciclo de vida do projeto e apresentado na Figura 4, queapresenta cinco grupo de processos de um projeto: de inici-acao, de planejamento, de execucao, de controle e monito-ramento e de encerramento.

Figura 4: Ciclo de vida do projeto

Cada grupo de processos do ciclo de vida do projeto con-siste em atividades relacionadas a uma das nove areas deconhecimentos definidos pelo PMBOK:

i) Escopo;

ii) Tempo;

iii) Custos;

iv) Qualidade;

v) Recursos humanos;

vi) Comunicacoes;

vii) Riscos;

viii) Aquisicoes;

ix) Integracao.

Segundo o PMBOK [12], uma boa gerencia do escopo doprojeto garante que todo o trabalho necessario sera bementendido e evitara trabalhos que nao estejam dentro doescopo do projeto.

Ao final da fase de planejamento do escopo do projeto, osartefatos criados consistem de uma declaracao do escopo doprojeto e do produto, incluindo sua Estrutura Analıtica doProjeto (EAP) e um dicionario da EAP, que garantira umcorreto entendimento de todos os integrantes da equipe doprojeto.

A estrutura analıtica do projeto apresenta uma decomposi-cao hierarquica de todos os pacotes de trabalho necessariosao objetivo do projeto, incluindo atividades ligadas a suagerencia e ao processo de desenvolvimento em si.

4. SUGESTÃO DE USO DA MDA COM OPMBOK

Segundo a especificacao da MDA, durante o desenvolvimentode sistemas complexos, e preciso que sejam feitos sucessivosrefinamentos nos seus modelos ate um ponto em que todo oescopo do produto seja alcancado pelo projeto, assim comoapresentado na Figura 5.

Figura 5: Processo para sistemas complexos

Uma consequencia direta desta abordagem e o excessivotempo gasto nos refinamentos, ja que, como apresentado naFigura 4, a atividade de refinamento e executada para todosos nıveis de modelagem, desde os modelos independentesde plataforma, ate o modelo especıfico. Uma tecnica quepermite reduzir o tempo gasto pelos sucessivos refinamentosnos varios nıveis de modelagem e aplicar o maximo destaatividade ao modelo de mais alto nıvel, ja que este e desen-volvido atraves de uma linguagem mais proxima do domıniodo negocio e permite um melhor entendimento pelas diver-sas partes envolvidas no projeto de desenvolvimento. Estatecnica permite nao so a reducao no tempo de desenvolvi-mento do sistema, mas tambem um melhor entendimento doescopo do produto de software em questao, o que acaba porreduzir os riscos associados e os custos do projeto.

Uma outra vantagem de concentrar o trabalho de refinar otrabalho ao maximo concentrando-se no modelo de mais altonıvel da MDA e que ele geralmente e feito em um momentoinicial do projeto. Isso permite um conhecimento anteci-pado dos riscos e um melhor planejamento de respostas ealternativas a eles. Ainda na fase de planejamento do pro-jeto de desenvolvimento, segundo o PMBOK [12] a definicaoda EAP permite uma organizacao hierarquica do escopo to-tal do projeto de maneira a subdividir todo o trabalho empartes menores, mais faceis de ser executadas, gerenciadas edimensionadas.

A Figura 6, apresenta uma EAP ilustrativa de um projeto

Figura 6: Exemplo de EAP

de desenvolvimento de software. O adequado detalhamentoda entrega referente ao software podera ser usada durante aaplicacao de MDA no sentido de encontrar quantos e quaismodelos independentes de arquitetura serao gerados, assim,poderemos evitar os refinamentos dos modelos mais especı-ficos, o que trara um ganho de tempo significativo [6].

5. CONCLUSÕESO princıpio da MDA e o uso de modelos para abstrair a pla-taforma na qual o produto sera implementado. Entretanto,a etapa de modelagem nao e devidamente realizada no ce-nario atual da engenharia de software. Alem disso, a MDAnao prove uma estrutura de gerenciamento de projeto. Ba-seado neste fato, propos-se o uso das praticas de gerencia deprojetos do PMBOK.

No decorrer do trabalho, constatou-se que sistemas comple-xos poderiam ser melhor gerenciados com o uso da EAP. Talavaliacao foi alcancada dadas as sucessivas transformacoessofridas por um sistema complexo numa abordagem MDA.

5.1 Vantagens e desvantagensA geracao de modelos na MDA, apesar de consumir umconsideravel esforco e tempo, possui benefıcios. Um deles,como ja mencionado, e a possibilidade de reutiliza-los emuma outra aplicacao de requisitos semelhantes. Em [14],apresentam-se outras vantagens do uso de MDA: facilidadede manutencao e documentacao (como as mudancas devemser feitas nos modelos, estes estao sempre atualizados, im-pedindo a defasagem que normalmente ocorrem entre a do-cumentacao e o produto final em modelos de desenvolvi-mento tradicionais) e portabilidade (de um mesmo PIM, quepor definicao e independente de plataforma, pode-se gerar amesma aplicacao em diferentes plataformas).

Entretanto, como apresentado em [1], a utilizacao de MDAtem alguns pre-requisitos, alguns deles bastante severos. Den-tre eles, apontamos: a equipe de desenvolvimento deve termodeladores de grande habilidade, algo ainda incomum nomercado; o atual conjunto de ferramentas para MDA aindanao suporta todas as etapas de desenvolvimento contidas naespecificacao; alem disso, esse atual conjunto e relativamentepequeno em relacao a quantidade de ferramentas disponıveispara outras metodologias, tais como RUP (Rational UnifiedProcess) e XP (eXtreme Programming); o suporte para es-trategias de teste por estas ferramentas ainda e insatisfato-rio.

A longo prazo, as duas ultimas transformacoes, de PIM aPSM e de PSM a ISM, serao automatizadas. Isso tornamuito simples o desenvolvimento de software, tal como, poranalogia, se tornou a programacao de baixo nıvel para altonıvel. Contudo, talvez esse seja o maior desafio da MDA.O foco do desenvolvimento de softwares se torna a etapa demodelagem e documentacao, em contraste com as metodo-logias atuais, em especial as ageis. A etapa de codificacaoperde importancia, sendo realizada apenas para determina-das partes em que as ferramentas nao foram capazes de re-alizar atraves dos modelos fornecidos. Os programadoresnao mais utilizam linguagens tradicionais, como C# e Java,mas sim em QVT (Query/View/Transformation). Todasessas mudancas acabam por afastar os desenvolvedores desoftwares, receosos em utilizar uma metodologia ainda naosolidificada.

5.2 Trabalhos futurosPara possıveis trabalhos futuros, sugere-se analisar o usode outras metodologias de gerencia de projetos (por exem-plo, MPS.BR) para auxiliar no desenvolvimento de produtosusando MDA, visto que a mesma nao fornece uma estruturade gerenciamento. Sugere-se ainda verificar se ha outros ar-tefatos do PMBOK que possam ser utilizados numa aborda-gem MDA. Outra possıvel extensao do trabalho e a aplicacaoda proposta para o desenvolvimento de um produto.

6. REFERÊNCIAS[1] S. W. Amber. Are you ready for the MDA.

http://www.agilemodeling.com/essays/readyForMDA.htm,2004.

[2] AndroMDA Team. AndroMDA.http://www.andromda.org/.

[3] S. Beydeda, M. Book, and V. Gruhn. Model-drivenSoftware Development. Birkhauser, 2005.

[4] A. W. Brown. MDA redux: Practical realization ofModel Driven Architecture. In Proceedings of theSeventh International Conference onComposition-Based Software Systems, pages 174–183,2008.

[5] G. L. P. Caliari. Transformacoes e mapeamentos daMDA e sua implementacao em tres ferramentas.Master’s thesis, Escola Politecnica da Universidade deSao Paulo, 2007.

[6] T. Calic and S. Egbert. Tools for MDA softwaredevelopment: Evaluation criteria and set of desirablefeatures. In Proceedings of the Fifth InternationalConference on Information Technology: NewGenerations, pages 44–50, 2008.

[7] D. T. Chang and J. D. Poole. Common WarehouseMetamodel (CWM). In OMG First Workshop onUML in the .com Enterprise: Modeling CORBA,Components, XML/XMI and Metadata, 2000.

[8] A. Esmin. Modelando com UML - Unified ModelingLanguage.http://www.dcc.ufla.br/infocomp/artigos/v1.1/tutorialUML.pdf,2000.

[9] P. Jandl Junior. Uma analise da OMG Model DrivenArchitecture. Analise, (11), 2005.

[10] S. J. Mellor. Agile MDA.http://www.omg.org/mda/mda files/Agile MDA.pdf.

[11] OMG - Object Management Group. Meta-ObjectFacility (MOF) Specification.

[12] Project Management Institute. Project ManagementBody of Knowlewdge Guide, 3 edition, 2004.

[13] R. Santos. XMI. Faculdade de Ciencias e Tecnologiada Universidade Nova de Lisboa, 2004.

[14] A. Tavares. Gerencia de projeto com PMBOK eScrum. Master’s thesis, Faculdade Cenecista NossaSenhora dos Anjos, Gravataı/RS, 2008.

[15] S. Witkop. Driving business agility with model drivenarchitecture. Ohio/Pennsylvania Solution Centre.