1. Interação entre MDA e PMBOK para Suporte ao
Desenvolvimento 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 Sergipe
Sergipe, Brasil
joaomarco@dcomp.ufs.br, {tfeitoza, marcel.ufs, paulo.darc}@gmail.com
fraga_ufs@yahoo.com.br, rogerio@ufs.br
ABSTRACT conceitua¸˜o da MDA e do PMBOK, juntamente com uma
ca
Model-Driven Architecture (MDA) is a development metho- proposta de integra¸˜o entre os mesmos. Especificamente,
ca
dology where the modeling is the central focus. This mode- ser˜o abordados conceitos e tecnologias relacionadas com a
a
ling should be done in a way that is independent of a spe- MDA, como UML e CWM; os modelos definidos pela MDA;
cific platform. Thus, the model generated can be used to o ciclo de vida MDA; ferramentas CASE que suportam essa
develop the system across multiple platforms, which helps metodologia; uma descri¸˜o geral do PMBOK; uma sugest˜o
ca a
in future maintenance, upgrades and migration of the sys- de uso da MDA com o PMBOK; e, finalmente, as conclus˜es o
tem. In order to manage the development, the use of a guide e trabalhos futuros.
containing good management practices can be applied. The
guide that can be used is the PMBOK, which can be used
for various areas of knowledge, not only for projects of infor-
PALAVRAS-CHAVE
MDA, PMBOK, EAP
mation technology. This work brings a concept of MDA and
the PMBOK, along with a proposal for integration between
them. Specifically, it will be addressed concepts and tecno- 1. INTRODUÇÃO
logies related to MDA, such as UML and CWM; the models Atualmente, o r´pido desenvolvimento na ´rea da computa-
a a
defined by MDA; the MDA lifecycle; CASE tools that sup- ¸˜o est´ diminuindo bastante o tempo necess´rio para tornar
ca a a
port this methodology; a brief description of PMBOK; a uma determinada tecnologia obsoleta. Empresas que visam
suggestion of use of MDA alongside PMBOK; and, finally, manter seus sistemas sempre atuais gastam um tempo e es-
the conclusions and future work. for¸o consider´veis nas tarefas de atualiza¸˜o e migra¸˜o [6].
c a ca ca
Para solucionar esses problemas, surgem abordagens que vi-
RESUMO sam separar as funcionalidades de um sistema de sua imple-
Model-Driven Architecture, ou MDA, trata-se de uma me- menta¸˜o. Uma dessas abordagens ´ a MDA (Model-Driven
ca e
todologia de desenvolvimento onde a modelagem ´ o foco
e Architecture).
central. Essa modelagem deve ser feita de forma que seja
independente de uma plataforma espec´ ıfica. Dessa forma, A MDA ´ uma abordagem para o desenvolvimento de softwa-
e
o modelo gerado pode ser utilizado para o desenvolvimento res proposta pela OMG (Object Management Group) em
do sistema em diversas plataformas, o que ajuda em futuras 2001. De forma simplificada, a MDA visa, a partir do desen-
co co co
manuten¸˜es, atualiza¸˜es e migra¸˜es do sistema. De forma volvimento de v´rios modelos, capturar a l´gica do neg´cio
a o o
a gerenciar o desenvolvimento, a utiliza¸˜o de um guia con-
ca em uma forma independente de plataforma. A partir des-
tendo boas pr´ticas de gerenciamento pode ser aplicada. O
a ses modelos, seriam utilizadas ferramentas que gerariam o
guia citado trata-se do PMBOK, o qual pode ser utilizado c´digo do produto para uma determinada plataforma. Por-
o
para diversas ´rea de conhecimento, e n˜o s´ para proje-
a a o tanto, numa eventual mudan¸a de tecnologia, precisa-se ape-
c
tos de tecnologia da informa¸˜o. Este trabalho traz uma
ca nas aplicar uma ferramenta que transforme os modelos ge-
rados anteriormente em c´digo para essa nova tecnologia.
o
∗Orientador
Abordagens anteriores em desenvolvimento dirigido por mo-
delos falharam por um fenˆmeno denominado “vendor lock-
o
in”. Cada ferramenta anteriormente utilizava um formato
pr´prio, com um contrato de licen¸a restritivo [4]. Para so-
o c
lucionar esse problema, a OMG definiu um conjunto de pa-
dr˜es abertos para o desenvolvimento de software. Alguns
o
deles j´ existentes previamente, outros elaborados especial-
a
mente para a abordagem MDA. Por exemplo, pode-se citar:
UML (Unified Modeling Language), MOF (Meta-Object Fa-
cility) e XMI (XML Metadata Interchange).

2. e ca
Al´m da utiliza¸˜o de uma metodologia de desenvolvimento ıvel
metamodelos. E o n´ M3 ´ o n´ do meta-metamodelo,
ıvel e
como a MDA, ´ importante que haja uma gerˆncia do pro-
e e isto ´, o MOF. Um bom exemplo dessa arquitetura seria uma
e
cesso de desenvolvimento. A fim de organizar a pr´tica de
a aplica¸˜o de a¸˜es da bolsa de valores. No n´ M0 estariam
ca co ıvel
gerˆncia, foi lan¸ado o PMBOK (Project Management Body
e c informa¸˜es sobre as empresas e os valores das a¸˜es de cada
co co
of Knowlegde). O PMBOK corresponde a um guia que re´ ne u uma. No n´ M1 est˜o as defini¸˜es do banco de dados, que
ıvel a co
um s´rie de pr´ticas para a realiza¸˜o da gest˜o de projetos
e a ca a indica que o nome da empresa ´ do tipo String. O n´ M2
e ıvel
em diversas ´reas de conhecimento. Uma boa gest˜o de pro-
a a cont´m informa¸˜es sobre a estrutura do banco de dados,
e co
cessos pode resultar em bons resultados e redu¸˜o do tempo
ca por exemplo, que uma tabela ´ composta de registros, que
e
e esfor¸o aplicado nas tarefas de migra¸˜o e atualiza¸˜o de
c ca ca s˜o compostos de campos e que cada campo deve ter um
a
sistemas. tipo. Finalmente, o n´ M3 ´ o modelo MOF, que engloba
ıvel e
defini¸˜es para v´rios modelos e meta-modelos. O modelo
co a
As pr´ximas se¸˜es desse artigo estar˜o assim organizadas:
o co a MOF pode ser visto na Figura 1.
a se¸˜o 2 tratar´ sobre conceitos e tecnologias utilizadas em
ca a
MDA; a se¸˜o 3 abordar´ brevemente o PMBOK; a inte-
ca a
ra¸˜o entre PMBOK e MDA ser´ discutida na se¸˜o 4; e,
ca a ca
finalmente, a se¸˜o 5 apresentar´ as conclus˜es e os poss´
ca a o ı-
veis trabalhos futuros.
1.1 Trabalhos relacionados
Uma sugest˜o de crit´rios a serem considerados na avalia¸˜o
a e ca
de ferramentas utilizadas para uma abordagem MDA, bem
como as funcionalidades que uma ferramenta ideal apresen-
taria, est˜o dispon´
a ıveis em [6]. Em [4], ´ apresentado como
e
aplicar uma abordagem MDA no contexto de uma Enter-
prise Architecture, a partir do uso de boas pr´ticas e heur´
a ıs-
ticas para se atingir o sucesso da abordagem.
Um trabalho interessante a ser citado ´ o [14]. Este faz
e
um estudo aprofundado da implementa¸˜o de metodologias
ca
´geis para desenvolvimento de software (em espec´
a ıfico, o
Scrum) em conjunto com as pr´ticas de gerenciamento de
a
projetos do PMBOK. O resultado dessa combina¸˜o ´ bas-
ca e
tante criticada especialmente por aqueles que defendem a
ado¸˜o pura de apenas um dos dois. Apesar disso, ´ cons-
ca e
tatado que h´ sim a possibilidade de utilizar ambas juntas
a
e que seus resultados s˜o positivos.
a Figura 1: Modelo MOF
2. MDA: CONCEITOS E TECNOLOGIAS 2.1.2 UML - Unified Modelling Language
Nessa se¸˜o, ser˜o abordados tecnologias de suporte ` MDA,
ca a a UML ´ uma linguagem visual de modelagem baseada no
e
como MOF (Meta-Object Facility) e UML (Unified Model- conceito de orienta¸˜o a objetos. Ela foi criada por Grady
ca
ling Language). Ser˜o apresentados tamb´m os v´rios mode-
a e a Booch, James Rumbaugh e Ivar Jacobson [8]. Atualmente,
los definidos pela MDA, como CIM (Computation Indepen- a UML foi padronizada e ´ mantida pela OMG. Em MDA,
e
dent Model ) e PSM (Platform Specific Model ). Posterior- os modelos UML precisam estar bem definidos, para que as
mente, ser´ apresentado o ciclo de vida MDA e, por ultimo,
a ´ ferramentas possam trabalhar em cima deles. Um dos con-
algumas ferramentas CASE (Computer-Aided Software En- ceitos utilizados, principalmente na abordagem Agile MDA,
gineering) que suportam a MDA. ´ o de UML execut´vel [10]. Uma UML execut´vel ´ um
e a a e
perfil UML que define semˆnticas de execu¸˜o para um sub-
a ca
2.1 Tecnologias de suporte conjunto restrito da UML. Este subconjunto ´ computaci-
e
A OMG adota algumas tecnologias para MDA. A maioria onalmente completo, possibilitando a sua execu¸˜o. Esses
ca
e o a
delas ´ mantida pela pr´pria OMG. Ser˜o abordadas algu- modelos execut´veis se comportam como c´digo, mas est˜o
a o a
mas que servem para modelagem e gerenciamento de mo- num n´ ıvel de abstra¸˜o maior, mais pr´ximo da linguagem
ca o
delos. S˜o elas: MOF, UML, CWM (Common Warehouse
a do cliente.
Metamodel ) e XMI (XML Metadata Interchange). Apesar
de a OMG encorajar o uso dessas tecnologias para o desen- 2.1.3 CWM - Common Warehouse Metamodel
volvimento MDA, qualquer uma delas pode ser substitu´ ıda CWM ´ uma tecnologia para a troca de metamodelos dispo-
e
por uma equivalente. n´
ıveis em ambientes de data warehouses entre ferramentas,
plataformas e reposit´rios [7]. Especificado pela OMG e ba-
o
2.1.1 MOF - Meta-Object Facility seado em MOF, sua fun¸˜o ´ estender o modelo de objetos
ca e
MOF ´ uma tecnologia de meta-metamodelagem. Ela se
e da UML, fornecendo um framework para representar meta-
baseia num arquitetura de 4 n´ ıveis de modelagem [11]. O dados, desde os dados at´ as opera¸˜es das data warehouses.
e co
n´
ıvel M0 ´ o n´
e ıvel da informa¸˜o, dos dados propriamente
ca CWM permite que ambientes de dados diferentes possam se
ıvel e ıvel
ditos. O n´ M1 ´ o n´ de modelos. No n´ M2, temos
ıvel comunicar, trocando informa¸˜es.
co

3. 2.1.4 XMI - XML Metadata Interchange especificar rela¸˜es entre propriedades de uma entidade ou
co
XMI ´ um padr˜o de formato para a troca de modelos e
e a as intera¸˜es entre entidades distintas. Esse modelo se ca-
co
metamodelos UML e baseados em MOF atrav´s de XML
e racteriza, como o pr´prio nome indica, pela independˆncia
o e
[13]. Desenvolvido pela OMG, provˆ um framework para
e de plataforma, ou seja, ´ tecnologicamente neutra [9]. E
e ´
definir, trocar, manipular e integrar dados e objetos XML. projetado para que seja capaz de definir a arquitetura que
Atrav´s de uso de XMI, ´ poss´ realizar um mapeamento
e e ıvel o sistema ter´ em qualquer plataforma que venha a ser de-
a
de MOF para XML. finida, ainda que sem detalhes de implementa¸˜o.
ca
2.2 Modelos definidos pela MDA Exemplificando na comunica¸˜o abordada, tem-se como parte
ca
A MDA possui processos estabelecidos pela OMG, cujos re- do modelo independente de idioma a defini¸˜o de que se
ca
sultados de cada um d˜o-se como modelos diferentes. Cada
a trata de uma frase interrogativa (´ um pedido), portanto
e
modelo possui um n´ de independˆncia de maneira a pro-
ıvel e precisar´ de um elemento que atribua a interroga¸˜o ao idi-
a ca
porcionar um melhor reaproveitamento, seja para a mesma oma a ser adotado. Tamb´m ´ necess´rio definir os objetos
e e a
ca ca
aplica¸˜o em plataformas diferentes, seja para uma aplica¸˜o ca a e
da a¸˜o (a pessoa em quest˜o), os sujeitos (algu´m a quem
diferente que necessite de defini¸˜es equivalentes a outras
co se pedir ajuda) e a a¸˜o propriamente dita (ajudar). Esses
ca
previamente desenvolvidas. Segundo Beydeda [3], existem elementos existem em qualquer idioma, por´m, abordados
e
quatro tipos de camadas, descritas em ordem decrescente de com regras diferentes. Essas regras ainda n˜o foram envol-
a
independˆncia:
e vidas, tornando a constru¸˜o da id´ia (a pessoa precisa pedir
ca e
ajuda a algu´m) flex´ aos idiomas existentes.
e ıvel
i) CIM - Computation Independent Model 2.2.3 PSM - Platform Specific Model
ii) PIM - Platform Independent Model Designada uma plataforma, o modelo PIM ser´ transfor-
a
mado em um modelo PSM. Esse modelo ´ capaz de descre-
e
iii) PSM - Platform Specific Model ver como ser´ desenvolvido o sistema de maneira mais espe-
a
c´
ıfica, j´ que resultar´ da combina¸˜o de especifica¸˜es do
a a ca co
iv) ISM - Implementation Specific Model modelo anterior com detalhes de como o sistema funcionar´a
na plataforma em quest˜o.
a
Para tornar a compreens˜o dos modelos mais simples, ser´
a a
abordada uma analogia da gera¸˜o de c´digo de programa-
ca o Em analogia, ´ a aplica¸˜o das regras de sintaxe do idioma
e ca
ca e
¸˜o com o uso de idiomas. O que ´ coerente, pois um idi- em espec´ ca e
ıfico na constru¸˜o da id´ia escolhida. Sendo o
oma nada mais ´ que um c´digo utilizado pelas pessoas para
e o idioma portuguˆs, os elementos identificados devem seguir
e
que as mesmas possam se comunicar, da mesma forma que as regras gramaticais da l´
ıngua portuguesa. Por exemplo, o
o a a co
utiliza-se c´digos para comunicar `s m´quinas instru¸˜es do o c˜
elemento a se atribuir para caracterizar o c´digo (a ora¸ao)
que deve ser executado. Adotando como exemplo, tem-se como interrogativa seria o s´ ımbolo (signo) “?” no final da
uma situa¸˜o em que uma pessoa necessita da ajuda de uma
ca ora¸˜o. Caso fosse escolhido o idioma espanhol, os s´
ca ımbolos
outra e, portanto, precisa construir a ora¸˜o a ser utilizada
ca a utilizar seriam “¿” no in´ıcio, e “?” no final da ora¸˜o.
ca
para se comunicar.
Os detalhes das plataformas s˜o fornecidos pelo PDM.
a
2.2.1 CIM - Computation Independent Model
Em uma aplica¸˜o desenvolvida com MDA, faz-se necess´ria
ca a 2.2.4 PDM - Platform Definition Model
a cria¸˜o de modelos cujas defini¸˜es sejam independentes de
ca co O PDM n˜o ´ um modelo resultado dos processos MDA,
a e
estrutura e processamento do sistema [9]. Ou seja, modelos mas sim um modelo que fornece os conceitos t´cnicos de
e
voltados apenas ` compreens˜o das regras de neg´cio. Tal
a a o diferentes partes que comp˜e a plataforma, e os elementos
o
modelo chama-se Computation Independent Model (CIM). A ca ´
que o sistema pode oferecer ` aplica¸˜o. E a partir dele que
a
inten¸˜o principal deste ´ especificar o dom´
ca e ca
ınio da aplica¸˜o a
ser´ poss´ıvel a transforma¸˜o de PIM para PSM. Uma vez
ca
a ser definida e os servi¸os e entidades com ela envolvidas.
c que ´ escolhida a plataforma, faz-se necess´rio saber como
e a
Compete a ele identificar requisitos do dom´ınio, mas n˜o seu
a a mesma funciona e os servi¸os que oferece para que as de-
c
funcionamento interno ou especifica¸˜es t´cnicas. Trata-se
co e fini¸˜es estabelecidas no PIM possam ser realizadas.
co
apenas de uma abstra¸˜o, um conceito. Comparando com o
ca
exemplo adotado, esse modelo consiste na forma¸˜o de uma
ca Analogamente, o PDM seria a gram´tica do idioma esco-
a
id´ia, uma mensagem. Essa id´ia seria que a pessoa precisa
e e lhido, com todas as regras espec´
ıficas.
pedir ajuda de outra pessoa. Nenhuma palavra de idioma
algum foi envolvida ainda. Por esse mesmo motivo, sendo 2.2.5 ISM - Implementation Specific Model
puramente conceitual, ´ dependente da interpreta¸˜o dos
e ca Por fim, tendo o modelo da aplica¸˜o j´ adaptado para fun-
ca a
desenvolvedores (analista e especialista de neg´cio), e por-
o cionar na plataforma designada, o que resta a ser feito ´
e
tanto de mapeamento complexo. Portanto, torna-se invi´vel a o c´digo em si. O produto final da MDA. Este modelo ´
o e
o processamento autom´tico da transforma¸˜o do modelo
a ca tamb´m conhecido como ISM.
e
CIM para o modelo seguinte, PIM.
Este modelo seria, por fim, a ora¸˜o formada com a apli-
ca
2.2.2 PIM - Platform Independent Model ca¸˜o apropriada dos signos. “Pode me ajudar?” em por-
ca
O modelo PIM j´ ´ capaz de descrever caracter´
a e ısticas da tuguˆs, “¿Puede usted atenderme?” em espanhol, “Pouvez-
e
ca a ıvel fazer no CIM. Por exemplo,
aplica¸˜o que n˜o era poss´ vous m’aider ?” em francˆs, “Can You help me?” em inglˆs,
e e

4. servem como exemplos das v´rias formas que a mensagem
a modelos e uma s´rie de plugins para transforma¸˜o desses
e ca
(CIM) pode tomar. modelos. Suas caracter´
ısticas s˜o:
a
2.3 Ciclo de Vida MDA i) Design modular: o AndroMDA ´ dividido em m´dulos
e o
Focando no ciclo seguido pelos processos do MDA, obt´m- e
que podem ser divididos para atender `s necessidades
a
se o seguinte esquema apresentado na Figura 2. O ciclo
do usu´rio;
a
tem seu in´ıcio na an´lise de requisitos, onde ser˜o obtidas
a a
as informa¸˜es de neg´cio a respeito da aplica¸˜o a ser de-
co o ca ii) Suporta o meta-modelo UML 1.4, mas o suporte ao mo-
senvolvida. Desse processo, o resultado ´ o CIM. Este ser´
e a delo 2.0 j´ se encontra em desenvolvimento;
a
transformado em PIM com ajuda de ferramentas, mas essen-
cialmente com a¸˜es dos pr´prios projetistas, dada a grande
co o iii) Suporta a inclus˜o de meta-modelos customizados em
a
complexidade de o sistema interpretar e mapear o modelo MOF ou XMI e gera¸˜o de c´digo a partir deles;
ca o
CIM. Ap´s a transforma¸˜o, o PIM resultante ser´ parcial,
o ca a
sendo ainda analisado pelos projetistas envolvidos, onde ha- iv) Plugins para plataformas espec´
ıficas;
ver˜o os ajustes necess´rios para ent˜o o PIM ser definitivo.
a a a
Este ent˜o ser´, com ferramentas, transformado em PSM.
a a v) Atualmente dispon´ na vers˜o 3.3.
ıvel a
Este, por sua vez, sofrer´ novas transforma¸˜es que gerar˜o
a co a
o ISM (o c´digo propriamente dito).
o
Os plugins do AndroMDA s˜o chamados de cartuchos (car-
a
´ co a
Essas duas ultimas transforma¸˜es, a curto prazo, s˜o exe- tridges). Cada cartucho ´ respons´vel por transforma¸˜es
e a co
cutadas pelos programadores ainda com aux´ de ferramen-
ılio para uma determinada plataforma. Nativamente, o An-
tas. Futuramente, elas dever˜o ocorrer automaticamente [9],
a droMDA j´ possui cartuchos para as plataformas Spring,
a
cabendo ao programador apenas analisar os resultados e fa- JSF, Hibernate, Java, EJB 2 / 3, entre outros. A ferramenta
zer as modifica¸˜es cab´
co ıveis. As vantagens fornecidas pela tamb´m possui um kit para cria¸˜o de cartuchos novos ou
e ca
cria¸˜o desses modelos ser´ abordada no t´pico “Vantagens
ca a o ca a
customiza¸˜o dos j´ existentes [2].
e Desvantagens”. Depois de ter o c´digo pronto, ele entra
o
em testes, dando resultados que ser˜o levados em conside-
a Apesar de ser baseado na MDA, o AndroMDA n˜o realiza
a
ra¸˜o na nova an´lise do PIM obtido para altera¸˜es. Esse
ca a co transforma¸˜es do modelo PIM para o modelo PSM. A fer-
co
PIM modificado, passa pelas transforma¸˜es at´ chegar no-
co e ramenta j´ traduz do modelo PIM para c´digo fonte em uma
a o
vamente no ISM, como um processo iterativo. determinado plataforma, dependendo do cartucho escolhido
para realizar a transforma¸˜o. Vale ressaltar que o modelo
ca
PIM aceito pelo AndroMDA tem que ser modelado em outra
ferramenta e salvo no formato .XMI. Esse modelo deve ser
composto pelo diagrama de casos de uso, o diagrama de clas-
ses e o diagrama de atividades. Esses modelos ainda devem
levar em considera¸˜o o conceito de marcas, onde os elemen-
ca
tos dos diagramas s˜o marcados com esteri´tipos UML. Por
a o
exemplo, um caso de uso pode ser marcado com o esteri´- o
tipo ≪ F rontEndU seCase ≫, indicando que ´ um caso de
e
uso que interage com o usu´rio. A partir desses modelos, o
a
AndroMDA ´ capaz de gerar o c´digo fonte correspondente,
e o
automatizando grande parte do processo de desenvolvimento
[5].
2.4.2 OptimalJ
A OptimalJ ´ uma ferramenta comercial, constru´ por
e ıda
uma empresa chamada Compuware. Por ser constru´ em ıda
cima da IDE (Integrated Development Environment) Eclipse,
se caracteriza por ser um ambiente de desenvolvimento diri-
Figura 2: Ciclo de vida do MDA
gido a modelos voltado ` plataforma Java. Essa ferramenta
a
permite a cria¸˜o de modelos utilizando UML e MOF como
ca
2.4 Ferramentas CASE meta-metamodelo. Se encontra atualmente na vers˜o 4.3 a
Muitas ferramentas CASE podem ser utilizadas para au- e tem como caracter´ ıstica importante o fato de permitir o
xiliar a MDA atrav´s da constru¸˜o de modelos em UML
e ca desenvolvimento em trˆs etapas, cada uma contendo um mo-
e
e gerando c´digo a partir deles. Para a MDA, foram en-
o delo espec´
ıfico:
contradas duas ferramentas espec´ıficas que podem atuar de
maneira interessante dentro dessa metodologia. Essas ferra-
mentas s˜o o AndroMDA e a OptimalJ.
a i) O modelo de dom´
ınio, o qual equivale ao PIM;
ii) O modelo de aplica¸˜o, o qual equivale ao PSM;
ca
2.4.1 AndroMDA
´
Seu nome pronuncia-se andrˆmeda. E um framework de
o iii) O modelo de c´digo, representado pelo c´digo fonte
o o
c´digo aberto que utiliza a UML para a interpreta¸˜o de
o ca Java.

5. O modelo de dom´ ınio (PIM) ´ representado pelo diagrama
e cessos, onde, em cada fase, um conjunto de atividades s˜o
a
de classes e o diagrama de atividades. O diagrama de classes executadas de maneira a tornar o processo de desenvolvi-
modelado na OptimalJ apresenta algumas restri¸˜es, como
co mento o mais gerenci´vel poss´
a ıvel.
o fato de n˜o suportar a modelagem de interfaces. Com re-
a
la¸˜o ao diagrama de atividades, a ferramenta imp˜e que
ca o O ciclo de vida do projeto ´ apresentado na Figura 4, que
e
cada fluxo tenha que especificar o objeto que ´ passado de
e apresenta cinco grupo de processos de um projeto: de inici-
uma atividade para outra. O diagrama de casos de uso e a¸˜o, de planejamento, de execu¸˜o, de controle e monito-
ca ca
o conceito de marcas n˜o s˜o necess´rios para que a ferra-
a a a ramento e de encerramento.
menta realize a transforma¸˜o entre o PIM e o PSM. Essa
ca
transforma¸˜o utiliza regras para mapear os elementos do
ca
modelo fonte para o modelo alvo. Vale ressaltar que ao apli-
car essa transforma¸˜o, a OptimalJ insere uma arquitetura
ca
de camadas ao modelo PSM, al´m de realizar o registro da
e
transforma¸˜o, como ´ sugerido pela MDA [5].
ca e
Em [15] ´ apresentado um estudo de caso que mostra a cons-
e
tru¸˜o de um sistema de e-commerce, especificamente o Pet
ca
Store desenvolvido pela Sun para demonstrar padr˜es deo
projeto. O estudo desenvolveu o sistema utilizando a pla-
taforma .NET, a plataforma J2EE de forma manual e com
o OptimalJ, seguindo as etapas da MDA. A Figura 3 mos-
tra uma gr´fico onde ´ poss´
a e ıvel ver o n´ mero de linhas de
u
c´digo escritas manualmente em cada um dos m´todos ado-
o e
tados. Dessa forma, ´ poss´
e ıvel verificar que o n´ mero total
u
de linhas de c´digo que foram escritas manualmente depois
o
de se utilizar a OptimalJ foi consideravelmente inferior aos
outros m´todos adotados, demonstrando o quanto uma fer-
e
ramente pode auxiliar o processo de desenvolvimento. 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 ´reas de
a
conhecimentos definidos pelo PMBOK:
i) Escopo;
ii) Tempo;
iii) Custos;
iv) Qualidade;
v) Recursos humanos;
vi) Comunica¸˜es;
co
vii) Riscos;
viii) Aquisi¸˜es;
co
Figura 3: Quantidade de linhas de c´digo escritas
o ix) Integra¸˜o.
ca
manualmente
Segundo o PMBOK [12], uma boa gerˆncia do escopo do
e
3. PMBOK - PROJECT MANAGEMENT projeto garante que todo o trabalho necess´rio ser´ bem
a a
BODY OF KNOWLEDGE entendido e evitar´ trabalhos que n˜o estejam dentro do
a a
O PMBOK ´ um guia editado e publicado pelo PMI (Project
e escopo do projeto.
Management Institute) que re´ ne o que se considera ser as
u
melhores pr´ticas em gest˜o de projetos em v´rias ´reas de
a a a a Ao final da fase de planejamento do escopo do projeto, os
conhecimento. artefatos criados consistem de uma declara¸˜o do escopo do
ca
projeto e do produto, incluindo sua Estrutura Anal´ıtica do
O guia est´ na terceira edi¸˜o, publicada em 2004, e tem
a ca Projeto (EAP) e um dicion´rio da EAP, que garantir´ um
a a
se tornado uma referˆncia mundial na gerˆncia de projetos.
e e correto entendimento de todos os integrantes da equipe do
O guia define o ciclo de vida do projeto por grupos de pro- projeto.

6. A estrutura anal´ıtica do projeto apresenta uma decomposi-
¸˜o hier´rquica de todos os pacotes de trabalho necess´rios
ca a a
ao objetivo do projeto, incluindo atividades ligadas ` sua
a
gerˆncia e ao processo de desenvolvimento em si.
e
4. SUGESTÃO DE USO DA MDA COM O
PMBOK
Segundo a especifica¸˜o da MDA, durante o desenvolvimento
ca
de sistemas complexos, ´ preciso que sejam feitos sucessivos
e
refinamentos nos seus modelos at´ um ponto em que todo o
e
escopo do produto seja alcan¸ado pelo projeto, assim como
c
apresentado na Figura 5.
Figura 6: Exemplo de EAP
de desenvolvimento de software. O adequado detalhamento
da entrega referente ao software poder´ ser usada durante a
a
aplica¸˜o de MDA no sentido de encontrar quantos e quais
ca
modelos independentes de arquitetura ser˜o gerados, assim,
a
poderemos evitar os refinamentos dos modelos mais espec´ ı-
ficos, o que trar´ um ganho de tempo significativo [6].
a
5. CONCLUSÕES
O princ´ıpio da MDA ´ o uso de modelos para abstrair a pla-
e
taforma na qual o produto ser´ implementado. Entretanto,
a
a etapa de modelagem n˜o ´ devidamente realizada no ce-
a e
n´rio atual da engenharia de software. Al´m disso, a MDA
a e
n˜o provˆ uma estrutura de gerenciamento de projeto. Ba-
a e
seado neste fato, propˆs-se o uso das pr´ticas de gerˆncia de
o a e
projetos do PMBOK.
Figura 5: Processo para sistemas complexos No decorrer do trabalho, constatou-se que sistemas comple-
xos poderiam ser melhor gerenciados com o uso da EAP. Tal
ue e
Uma conseq¨ˆncia direta desta abordagem ´ o excessivo ca c co
avalia¸˜o foi alcan¸ada dadas as sucessivas transforma¸˜es
tempo gasto nos refinamentos, j´ que, como apresentado na
a sofridas por um sistema complexo numa abordagem MDA.
Figura 4, a atividade de refinamento ´ executada para todos
e
os n´ıveis de modelagem, desde os modelos independentes 5.1 Vantagens e desvantagens
de plataforma, at´ o modelo espec´
e ıfico. Uma t´cnica que
e A gera¸˜o de modelos na MDA, apesar de consumir um
ca
permite reduzir o tempo gasto pelos sucessivos refinamentos consider´vel esfor¸o e tempo, possui benef´
a c ıcios. Um deles,
nos v´rios n´
a e a
ıveis de modelagem ´ aplicar o m´ximo desta como j´ mencionado, ´ a possibilidade de reutiliz´-los em
a e a
atividade ao modelo de mais alto n´ ıvel, j´ que este ´ desen-
a e uma outra aplica¸˜o de requisitos semelhantes. Em [14],
ca
volvido atrav´s de uma linguagem mais pr´xima do dom´
e o ınio apresentam-se outras vantagens do uso de MDA: facilidade
do neg´cio e permite um melhor entendimento pelas diver-
o de manuten¸˜o e documenta¸˜o (como as mudan¸as devem
ca ca c
sas partes envolvidas no projeto de desenvolvimento. Esta ser feitas nos modelos, estes est˜o sempre atualizados, im-
a
t´cnica permite n˜o s´ a redu¸˜o no tempo de desenvolvi-
e a o ca pedindo a defasagem que normalmente ocorrem entre a do-
mento do sistema, mas tamb´m um melhor entendimento do
e cumenta¸˜o e o produto final em modelos de desenvolvi-
ca
escopo do produto de software em quest˜o, o que acaba por
a mento tradicionais) e portabilidade (de um mesmo PIM, que
reduzir os riscos associados e os custos do projeto. por defini¸˜o ´ independente de plataforma, pode-se gerar a
ca e
mesma aplica¸˜o em diferentes plataformas).
ca
Uma outra vantagem de concentrar o trabalho de refinar o
trabalho ao m´ximo concentrando-se no modelo de mais alto
a Entretanto, como apresentado em [1], a utiliza¸˜o de MDA
ca
n´ da MDA ´ que ele geralmente ´ feito em um momento
ıvel e e tem alguns pr´-requisitos, alguns deles bastante severos. Den-
e
inicial do projeto. Isso permite um conhecimento anteci- tre eles, apontamos: a equipe de desenvolvimento deve ter
pado dos riscos e um melhor planejamento de respostas e modeladores de grande habilidade, algo ainda incomum no
alternativas a eles. Ainda na fase de planejamento do pro- mercado; o atual conjunto de ferramentas para MDA ainda
jeto de desenvolvimento, segundo o PMBOK [12] a defini¸˜oca n˜o suporta todas as etapas de desenvolvimento contidas na
a
ca a
da EAP permite uma organiza¸˜o hier´rquica do escopo to- e
especifica¸˜o; al´m disso, esse atual conjunto ´ relativamente
ca e
tal do projeto de maneira a subdividir todo o trabalho em pequeno em rela¸˜o ` quantidade de ferramentas dispon´
ca a ıveis
partes menores, mais f´ceis de ser executadas, gerenciadas e
a para outras metodologias, tais como RUP (Rational Unified
dimensionadas. Process) e XP (eXtreme Programming); o suporte para es-
trat´gias de teste por estas ferramentas ainda ´ insatisfat´-
e e o
A Figura 6, apresenta uma EAP ilustrativa de um projeto rio.

7. A longo prazo, as duas ultimas transforma¸˜es, de PIM a
´ co [11] OMG - Object Management Group. Meta-Object
PSM e de PSM a ISM, ser˜o automatizadas. Isso torna
a Facility (MOF) Specification.
muito simples o desenvolvimento de software, tal como, por [12] Project Management Institute. Project Management
analogia, se tornou a programa¸˜o de baixo n´
ca ıvel para alto Body of Knowlewdge Guide, 3 edition, 2004.
n´ıvel. Contudo, talvez esse seja o maior desafio da MDA. [13] R. Santos. XMI. Faculdade de Ciˆncias e Tecnologia
e
O foco do desenvolvimento de softwares se torna a etapa de da Universidade Nova de Lisboa, 2004.
modelagem e documenta¸˜o, em contraste com as metodo-
ca [14] A. Tavares. Gerˆncia de projeto com PMBOK e
e
logias atuais, em especial as ´geis. A etapa de codifica¸˜o
a ca Scrum. Master’s thesis, Faculdade Cenecista Nossa
perde importˆncia, sendo realizada apenas para determina-
a Senhora dos Anjos, Gravata´ı/RS, 2008.
das partes em que as ferramentas n˜o foram capazes de re-
a [15] S. Witkop. Driving business agility with model driven
alizar atrav´s dos modelos fornecidos. Os programadores
e architecture. Ohio/Pennsylvania Solution Centre.
n˜o mais utilizam linguagens tradicionais, como C# e Java,
a
mas sim em QVT (Query/View/Transformation). Todas
essas mudan¸as acabam por afastar os desenvolvedores de
c
softwares, receosos em utilizar uma metodologia ainda n˜o a
solidificada.
5.2 Trabalhos futuros
Para poss´ ıveis trabalhos futuros, sugere-se analisar o uso
de outras metodologias de gerˆncia de projetos (por exem-
e
plo, MPS.BR) para auxiliar no desenvolvimento de produtos
usando MDA, visto que a mesma n˜o fornece uma estrutura
a
de gerenciamento. Sugere-se ainda verificar se h´ outros ar-
a
tefatos do PMBOK que possam ser utilizados numa aborda-
gem MDA. Outra poss´ extens˜o do trabalho ´ a aplica¸˜o
ıvel a e ca
da 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-driven
Software Development. Birkh¨user, 2005.
a
[4] A. W. Brown. MDA redux: Practical realization of
Model Driven Architecture. In Proceedings of the
Seventh International Conference on
Composition-Based Software Systems, pages 174–183,
2008.
[5] G. L. P. Caliari. Transforma¸˜es e mapeamentos da
co
MDA e sua implementa¸˜o em trˆs ferramentas.
ca e
Master’s thesis, Escola Polit´cnica da Universidade de
e
S˜o Paulo, 2007.
a
[6] T. Calic and S. Egbert. Tools for MDA software
development: Evaluation criteria and set of desirable
features. In Proceedings of the Fifth International
Conference on Information Technology: New
Generations, pages 44–50, 2008.
[7] D. T. Chang and J. D. Poole. Common Warehouse
Metamodel (CWM). In OMG First Workshop on
UML in the .com Enterprise: Modeling CORBA,
Components, XML/XMI and Metadata, 2000.
[8] A. Esmin. Modelando com UML - Unified Modeling
Language.
http://www.dcc.ufla.br/infocomp/artigos/v1.1/tutorialUML.pdf,
2000.
[9] P. Jandl Junior. Uma an´lise da OMG Model Driven
a
Architecture. An´lise, (11), 2005.
a
[10] S. J. Mellor. Agile MDA.
http://www.omg.org/mda/mda files/Agile MDA.pdf.