prospecÇÃo tecnolÓgica em model-driven...
TRANSCRIPT
PROSPECÇÃO TECNOLÓGICA EM MODEL-DRIVEN ARCHITECTURE
(MDA) ATRAVÉS DE CLASSIFICAÇÃO E ANÁLISE DA ESPECIFICAÇÃO OMG
Marcelo Arêas Rodrigues da Silva
Dissertação de Mestrado apresentada ao
Programa de Pós-graduação em Engenharia de
Sistemas e Computação, COPPE, da
Universidade Federal do Rio de Janeiro, como
parte dos requisitos necessários à obtenção do
título de Mestre em Engenharia de Sistemas e
Computação.
Orientadores: Jano Moreira de Souza
Rodrigo Salvador Monteiro
Rio de Janeiro
Setembro de 2011
PROSPECÇÃO TECNOLÓGICA EM MODEL-DRIVEN ARCHITECTURE
(MDA) ATRAVÉS DE CLASSIFICAÇÃO E ANÁLISE DA ESPECIFICAÇÃO OMG
Marcelo Arêas Rodrigues da Silva
DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO
LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA
(COPPE) DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE
DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE
EM CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.
Examinada por:
RIO DE JANEIRO, RJ – BRASIL
SETEMBRO DE 2011
iii
Silva, Marcelo Arêas Rodrigues da
Prospecção tecnológica em Model-Driven Architecture (MDA)
através de classificação e análise da especificação OMG / Marcelo
Arêas Rodrigues da Silva. – Rio de Janeiro: UFRJ/COPPE, 2011.
XIII, 112 p.: il.; 29,7 cm.
Orientadores: Jano Moreira de Souza
Rodrigo Salvador Monteiro
Dissertação (mestrado) – UFRJ / COPPE / Programa de
Engenharia de Sistemas e Computação, 2011.
Referências bibliográficas: p. 82 - 91
1. Prospecção tecnológica 2. Arquitetura orientada a modelo I.
Souza, Jano Moreira de et al. II. Universidade Federal do Rio de
Janeiro, COPPE, Programa de Engenharia de Sistemas e
Computação. III. Título
iv
DEDICATÓRIA
Aos meus pais, pelo amor, carinho e
apoio que nunca me faltaram.
v
AGRADECIMENTOS
A Deus, pela vida, oportunidades, força e paciência concedida nos momentos
certos.
Aos meus pais Mara Cláudia e Célio Rodrigues, por me criarem com a dose
certa de amor e responsabilidade, por me ensinarem os valores de moral e ética, por
todo o incentivo que recebi durante o mestrado e durante a toda a vida.
Aos meus avôs e avós, vivos e falecidos, Gelcy, Joaquim, Dalva e Romeu. Por
todo o carinho que recebo e recebi, guardados na memória e no coração.
Ao meu irmão Raphael Arêas, pelas inúmeras partidas de vídeo game para
relaxar e descontrair nos momentos de estresse.
Aos meus orientadores Rodrigo Monteiro e Jano Moreira de Souza, por
compartilharem comigo suas ideias e pelo suporte durante esta jornada, essenciais para
a conclusão deste trabalho.
Aos professores Geraldo Zimbrão, Leonardo Azevedo e Ricardo Barros, por
aceitarem participar desta banca, agregando valor a avaliação deste trabalho.
Aos meus amigos e irmãos de coração Fernando Bruno e João Gabriel, uma
amizade que vem desde os três anos de idade e se manterá viva para sempre.
Aos meus amigos Danielle Lima, Lêda Beatriz, Adriano Cesar, Francine Álamo,
pela amizade e por entenderem os meus sumiços.
Aos companheiros colegas de mestrado, pelo companheirismo durante este
caminho que percorremos juntos.
Aos colegas de todos os projetos que trabalhei: SICONV, SOMAR, GPE.
Obrigado por todo o conhecimento compartilhado, só trabalhei em equipes excelentes!
À CAPES, pelo apoio financeiro. À COPPETEC pelo meu crescimento
profissional. À UFRJ pelo excelente ensino.
Por fim, a todos que me ajudaram de alguma forma na realização deste trabalho.
Ter chegado até aqui me enche de orgulho e faz com que eu me sinta preparado para
enfrentar novos desafios.
vi
Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos
necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
PROSPECÇÃO TECNOLÓGICA EM MODEL-DRIVEN ARCHITECTURE
(MDA) ATRAVÉS DE CLASSIFICAÇÃO E ANÁLISE DA ESPECIFICAÇÃO OMG
Marcelo Arêas Rodrigues da Silva
Setembro / 2011
Orientadores: Jano Moreira de Souza
Rodrigo Salvador Monteiro
Programa: Engenharia de Sistemas e Computação
A metodologia MDA (Model-Driven Architecture) de desenvolvimento vem
ganhando espaço no cenário de desenvolvimento de software. A possibilidade de gerar
código através de modelos é um dos fatores que impulsionam essa metodologia a
ganhar novos adeptos.
A prospecção tecnológica visa o mapeamento do desenvolvimento científico e
tecnológico em uma determinada área, fornecendo um nível de informação muito
valioso para a construção de um futuro desejável. No presente trabalho foi realizada
uma extensa pesquisa na área MDA, onde cada trabalho ou estudo encontrado foi
classificado e analisado de acordo com uma taxonomia proposta. Foi efetuada uma
entrevista com pesquisadores, profissionais de TI e estudantes com conhecimento na
área. Esse cenário possibilitou a identificação de prospecção tecnológica em MDA,
assim como o estado da arte.
vii
Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the
requirements for the degree of Master of Science (M.Sc.)
TECHNOLOGICAL FORECASTING IN MODEL-DRIVEN ARCHITECTURE
(MDA) THROUGH CLASSIFICATION AND ANALYSIS OF OMG SPECIFICATION
Marcelo Arêas Rodrigues da Silva
September / 2011
Advisors: Jano Moreira de Souza
Rodrigo Salvador Monteiro
Department: Systems and Computing Engineering
The MDA (Model-Driven Architecture) methodology is being increasingly used
among software developers. The possibility of code generating through models is one of
the factors that boost this methodology to gain new followers.
The technological forecasting aims to map the scientific and technological
development in a given area, providing a valuable information level to build a desirable
future. In the present work was carried out an extensive research at MDA area. Each
paper or study found has been classified and analyzed according to a proposed
taxonomy. An interview was conducted with researchers, IT professionals and students
with knowledge in the area. This scenario allowed the identification of technological
forecasting in MDA, as well as the state of the art.
viii
SUMÁRIO
1. Introdução ................................................................................................................. 1
1.1 Motivação .......................................................................................................... 1
1.2 Definição do Problema ...................................................................................... 2
1.3 Contribuições ..................................................................................................... 4
1.4 Organização ....................................................................................................... 4
2. Revisão de Literatura ................................................................................................ 5
2.1 Arquitetura Orientada a Modelo (MDA) ........................................................... 5
2.1.1 Modelos e Metamodelos (CIM, PIM, PSM) .............................................. 6
2.1.2 Transformação de Modelos ........................................................................ 8
2.1.3 Modelos Padronizados (UML,MOF,XMI) ................................................. 9
2.1.4 Benefícios ................................................................................................. 10
2.2 Prospecção Tecnológica .................................................................................. 11
2.2.1 Metodologias ............................................................................................ 11
2.2.2 Monitoramento e Análise de Tendências ................................................. 12
2.2.3 Modelos computacionais e ferramentas analíticas ................................... 12
2.2.4 Opinião de especialistas, criatividade e cenários...................................... 14
3. Trabalhos Relacionados .......................................................................................... 17
4. Classificação Proposta e Análise Geral .................................................................. 19
4.1 Revisão Sistemática ......................................................................................... 19
4.2 Metodologia de pesquisa ................................................................................. 20
4.3 Classificação .................................................................................................... 22
4.3.1 CIM ........................................................................................................... 24
4.3.1.1 Escopo ................................................................................................... 24
4.3.1.2 Trabalhos e Considerações ................................................................... 25
4.3.2 Transformação CIM PIM .................................................................... 29
4.3.2.1 Escopo ................................................................................................... 29
4.3.2.2 Trabalhos e Considerações ................................................................... 30
4.3.3 PIM ........................................................................................................... 36
4.3.3.1 Escopo ................................................................................................... 36
4.3.3.2 Trabalhos e Considerações ................................................................... 36
4.3.4 Mapeamento de Modelo (Model Mapping) ............................................. 42
ix
4.3.4.1 Escopo ................................................................................................... 42
4.3.4.2 Trabalhos e Considerações ................................................................... 43
4.3.5 Transformação PIM PSM .................................................................... 49
4.3.5.1 Escopo ................................................................................................... 49
4.3.5.2 Trabalhos e Considerações ................................................................... 49
4.4 Análise Geral ................................................................................................... 57
5. Análise dos Resultados ........................................................................................... 59
5.1 Pesquisa relacionada ........................................................................................ 59
5.2 Objetivos do questionário ................................................................................ 60
5.3 Pesquisa no contexto internacional .................................................................. 61
5.3.1 Análise geral ............................................................................................. 61
5.3.2 Análise por ramo de atividade .................................................................. 66
5.4 Pesquisa com desenvolvedores COPPETEC ................................................... 69
5.5 Pesquisa na Engenharia de Software ............................................................... 73
5.6 Considerações finais ........................................................................................ 77
6. Conclusões .............................................................................................................. 79
6.1 Contribuições ................................................................................................... 79
6.2 Lições aprendidas e trabalho futuro ................................................................. 81
7. Referências Bibliográficas ...................................................................................... 82
ANEXO I – QUESTIONÁRIO SOBRE PROSPECÇÃO TECNOLÓGICA EM MDA92
ANEXO II – RESUMO DAS RESPOSTAS AO QUESTIONÁRIO ............................ 95
ANEXO III – TABELA DE CLASSIFICAÇÃO DOS TRABALHOS ....................... 104
x
LISTA DE FIGURAS
Figura 1 - Arquitetura Orientada a Modelo ...................................................................... 6
Figura 2 - O processo de transformação de modelos........................................................ 7
Figura 3 - Transformação de modelo ............................................................................... 9
Figura 4 - Classificação de acordo com a especificação OMG ...................................... 24
Figura 5 - Modelo Conceitual CIM ................................................................................ 26
Figura 6 - Pontos de conformidade ................................................................................ 28
Figura 7 - Pontos de vista MDA ..................................................................................... 31
Figura 8 - MDA estendido .............................................................................................. 31
Figura 9 - Visão geral da proposta com SBP ................................................................. 33
Figura 10 - Posicionamento do SBVR em uma Arquitetura Orientada a Modelo ......... 34
Figura 11 - Um exemplo do domínio e aplicações ......................................................... 38
Figura 12 - Modelo de Interação Abstrata em um processo de desenvolvimento MDA 40
Figura 13 - O framework do modelo alvo baseado em JSF ........................................... 45
Figura 14 - Níveis de modelos e linguagens .................................................................. 46
Figura 15 - Ferramenta MDA com o processador de linguagem Natural MDA ............ 50
Figura 16 - Representação das áreas de alto nível de uma Transformação de Modelo .. 52
Figura 17 - MDA para queries independentes de plataformas ....................................... 54
Figura 18 - Análise subjetiva da distribuição de trabalhos ............................................. 57
Figura 19 - Ganho de produtividade com geração de código ......................................... 77
xi
LISTA DE TABELAS
Tabela 1 - Listagem de periódicos .................................................................................. 21
Tabela 2 - Mapeamento de modelos MDA e artefatos WRSPM ................................... 43
Tabela 3 - Experiência com MDA: Pesquisador X Profissional de TI ........................... 67
Tabela 4 - Geração de código: Pesquisador X Profissional de TI .................................. 69
Tabela 5 - Atividade principal: COPPETEC X Internacional ........................................ 70
Tabela 6 - Geração de código: COPPETEC X Internacional ......................................... 71
Tabela 7 - Nível de formação: Internacional X Engenharia de Software ....................... 73
Tabela 8 - Atividade principal: Internacional X Engenharia de Software ..................... 74
Tabela 9 - Geração de código: COPPETEC X Internacional X ES ............................... 75
xii
LISTA DE GRÁFICOS
Gráfico 1 – Nível de formação, pela amostra internacional ........................................... 62
Gráfico 2 - Atividade principal, pela amostra internacional .......................................... 62
Gráfico 3 - Experiência com MDA, pela amostra internacional .................................... 63
Gráfico 4 - Opinião sobre geração de código, pela amostra internacional ..................... 64
Gráfico 5 - Áreas a aperfeiçoar, pela amostra internacional .......................................... 65
Gráfico 6 – Opinião sobre a popularização da MDA, pela amostra internacional ......... 65
Gráfico 7 - Comparativo da formação: Pesquisador X Profissional de TI ..................... 67
Gráfico 8 - Comparativo experiência com MDA: Pesquisador x Profissional de TI ..... 68
Gráfico 9 - Comparativo da formação: COPPETEC x Internacional ............................. 70
Gráfico 10 - Comparativo da opinião sobre popularização da MDA: COPPETEC X
Internacional ................................................................................................................... 72
Gráfico 11 - Experiência com MDA, pela Engenharia de Software .............................. 74
Gráfico 12 - Áreas a aperfeiçoar, pela Engenharia de Software .................................... 75
Gráfico 13 - Comparativo da opinião sobre popularização da MDA: COPPETEC X
Internacional X Engenharia de Software ........................................................................ 76
xiii
LISTA DE SÍMBOLOS
ABNT Associação Brasileira de Normas Técnicas.
ANTLR
AMMA
Another Tool for Language Recognition
ATLAS Model Management Architecture
BPM Business Process Management
BPMN Business Process Model and Notation
CIM Computational Independent Model
CSCW Computer Supported Cooperative Work
DSL Domain-Specific Language
DW Data Warehouse
EJB Enterprise JavaBeans
FSM Functional Size Measurement
HTML HyperText Markup Language
JDBC Java Database Connectivity
JDO Java Data Objects
JSP JavaServer Page
KDM Knowledge Discovery Metamodel
LEL Language Extended Lexicon
MDA Model-Driven Architecture
MDD Model-Driven Development
MDE Model-Driven Engineering
MOF Meta Object Facility
MVC Model-View-Controller
OCL Object Constraint Language
OLAP On-Line Analytical Processing
OMG Object Managemento Group
PIM Platform Independent Model
PSM Platform Specifc Model
QVT Query/View/Transformation
RM-ODP Reference Model of Open Distributed Processing
SBP Secure Busines Process
SBVR Semantics of Business Vocabulary and Business Rules
SEM Software Resource Modeling
SOA Service Oriented Architecture
TFM4MDA Topological Functioning Modeling for Model-Driven Architecture
UML Unified Modeling Language
UML-RSDS UML Reactive System Design Support
XMI XML Metadata Interchange
xUML Executable UML
1
1.Introdução
O Object Management Group (OMG) (OMG, 2010) criou a metodologia MDA
de desenvolvimento de software que possibilita a criação de aplicações completas
através de modelos. É possível criar sistemas web complexos com grande parte do
código sendo gerado através de modelos, com específicos pontos de implementação do
sistema. Esse paradigma de desenvolvimento, diferente do comum, faz a MDA chamar
atenção de desenvolvedores para seu aprendizado e uso em busca de velocidade e
produtividade.
O OMG criou uma especificação para a MDA. Com o passar dos anos
pesquisadores com interesse no assunto começaram a realizar pesquisas sobre o tema,
enquanto outros se preocuparam mais em trabalhar em determinada área, visando a sua
evolução. Entretanto, pode haver áreas da especificação que tenham estado fora da meta
de trabalho dos pesquisadores. Diversos são os motivos que poderiam ter acarretado o
abandono dessas áreas, dentre os quais se destacam:
Especificação muito ambiciosa e, por isso, fora da realidade atual;
Área já bem evoluída;
Poucos pesquisadores trabalhando com MDA e ainda assim, focados em
outras áreas.
Como qualquer tecnologia em evolução, a MDA que existe hoje é diferente de
quando foi planejada e, muito provavelmente, diferente da que será daqui a alguns anos.
Seria interessante para a comunidade científica que existisse alguma forma de se prever
o futuro dessa metodologia, sabendo, de antemão, que novas técnicas estão por vir e o
nível de evolução que pode ser alcançado em uma determinada área. Também seria de
grande valia poder identificar quais são as áreas que já alcançaram um bom nível de
evolução e quais áreas necessitam de maior esforço para que possam obter melhor
desenvolvimento.
1.1 Motivação
A escolha da MDA como tema deste trabalho se deu devido ao apreço do autor a
esta metodologia de desenvolvimento. Ao pesquisar sobre a MDA em busca de
2
possíveis problemas em aberto, notou-se que a especificação feita pela OMG é falha em
alguns pontos. Após pesquisar alguns trabalhos nesta área também foi notado que
existem trabalhos e ferramentas que não seguem exatamente o que está descrito na
especificação. Dado esse cenário, parecia evidente que a MDA não se apresenta como
uma área bem definida.
Para a comunidade acadêmica, é importante que uma área como a MDA, que
vem sendo adotada como metodologia de desenvolvimento, se encontre bem definida e
de forma organizada. A organização possibilita uma visão clara do estado da arte para
que seja possível o direcionamento de esforços nas novas pesquisas que venham a
surgir.
Nesse contexto, surgiu a principal motivação deste trabalho, a possibilidade de
identificar o estado da arte e realizar prospecção em MDA. A prospecção não se limita
em somente “prever o futuro”, mas também em guiar os trabalhos existentes para que se
construa o futuro que deseja.
Desta maneira, este trabalho foi realizado com o objetivo de realizar prospecções
nas linhas de pesquisa da MDA que foram identificadas, de forma a conseguir
identificar áreas carentes de desenvolvimento e descobrir o que pode se esperar do
desenvolvimento futuro de cada área. A prospecção realizada neste trabalho foi
realizada a partir de artigos publicados na área e um formulário de perguntas e
respostas, direcionado para profissionais, pesquisadores e estudantes que possuem
conhecimento MDA, visando obter opiniões a respeito desta tecnologia em nível
nacional e internacional.
1.2 Definição do Problema
O problema alvo deste trabalho é o desenvolvimento atual da MDA. Não é
possível, atualmente, definir a que ponto estão as atuais pesquisas em desenvolvimento
acerca da MDA. Para resolver este problema, o presente trabalho se propõe a realizar
uma grande pesquisa na área da Arquitetura Orientada a Modelo, mapear os trabalhos
encontrados, classificando-os de acordo com uma taxonomia proposta, e identificar
prospecções tecnológicas na área.
Para realizar a pesquisa foram considerados artigos indexados em bases
científicas, dissertações de mestrado, teses de doutorado e outros trabalhos conexos.
Infelizmente não seria possível fazer uma varredura por toda a extensão da área sem
3
deixar de fora um ou outro trabalho e, buscando aumentar o alcance dessa varredura foi
preparado um formulário com perguntas acerca da MDA. Este formulário foi postado
no fórum do DBWorld (DBWORLD, 2011), enviado para a lista da International
Conference on Computer Science and Applications (ICCSA, 2011), para a lista de
Engenharia de Software da Sociedade Brasileira de Computação (SBC, 2011) e da
COPPE (COPPE, 2011), para a SEWORLD (SEWORLD, 2011) e para
desenvolvedores da COPPETEC que já trabalharam com MDA.
O formulário contém indagações que procuram identificar o perfil do
entrevistado, perguntas acerca da metodologia MDA, uma área para resposta discursiva
livre e um espaço onde o pesquisado pode informar referências de artigos e trabalhos
publicados por ele ou outros que tenham sua recomendação. O formulário completo se
encontra no Anexo I deste trabalho.
A análise das respostas do formulário permite que se tenha uma visão global da
metodologia MDA, como ela é vista e quais são as opiniões sobre esta área por parte da
comunidade científica, acadêmica e profissionais do mercado.
A prospecção tecnológica tem como objetivo descrever em algum momento
futuro a emergência, o desempenho, as características ou os impactos de uma tecnologia
(PORTER, 1991).
A pesquisa realizada proporcionou a análise de trabalhos, onde ficou evidente
que muitos deles possuíam a seção “Trabalho Futuros” ou outra seção de nome similar,
cujo conteúdo se mostra útil para a realização de uma prospecção tecnológica nessa
área. Existem também técnicas de prospecção que utilizam a opinião de especialistas,
através de entrevistas e surveys. Tais técnicas utilizadas em conjunto são capazes de
fornecer uma visão mais esclarecedora do estado da MDA, suas áreas, e, também, quais
caminhos seguir.
Ao final deste trabalho, o seu principal objetivo é conceder ao leitor uma visão
das linhas de pesquisa em MDA, através do seu atual estado da arte. É essencial que, ao
final da leitura, o leitor possua a visão do atual desenvolvimento e entenda o que se
pode esperar futuramente em cada uma das linhas. A seguir, em 1.3, encontra-se uma
listagem com as contribuições deste trabalho.
4
1.3 Contribuições
As contribuições do presente trabalho são:
i. Proposição de uma taxonomia de classificação de trabalhos dentro do contexto
da MDA;
ii. Identificação do estado da arte e prospecção tecnológica, sob o aspecto de cada
categoria da taxonomia proposta;
iii. Identificação do cumprimento, em todas as suas linhas de pesquisa, da proposta
inicial da especificação OMG;
iv. Identificação de quais linhas de pesquisa da MDA se encontram já
desenvolvidas, e quais apresentam carência de desenvolvimento;
v. Identificação de quais linhas de pesquisa da MDA vêm recebendo maior ou
menor foco por parte de pesquisadores da área;
vi. Estabelecimento de diferenças acerca de como o MDA é encarado, a partir do
ponto de vista acadêmico, científico e do mercado de trabalho;
vii. Disponibilização do estudo para se tornar um ponto de partida para posteriores
trabalhos em MDA, servindo como um guia de referência nesta área.
1.4 Organização
Este trabalho está organizado da seguinte forma:
O capítulo 1 diz respeito à introdução ao tema deste trabalho e sua estrutura; o
capítulo 2 faz um estudo bibliográfico sobre a metodologia de desenvolvimento MDA e
técnicas de prospecção; o capítulo 3 apresenta outros trabalhos relacionados ao tema e
em que pontos os trabalhos se diferenciam; o capítulo 4 destina-se a classificação
proposta e a análise dos trabalhos pesquisados; o capítulo 5 dedica-se à análise e
compilação dos dados coletados na entrevista, sob uma visão, tanto geral, quanto à
formada por determinados grupos; o capítulo 6 apresenta as conclusões, descrevendo as
principais contribuições do presente trabalho, assim como as direções futuras.
Ao final, são apresentadas as referências bibliográficas e os anexos desta
dissertação. A geração das referências foi realizada a partir do Mendeley Desktop
(http://www.mendeley.com) e o estilo de citação utilizado foi o ABNT.
5
2. Revisão de Literatura
2.1 Arquitetura Orientada a Modelo (MDA)
O Desenvolvimento Orientado a Modelo (em inglês, Model-Driven Development
ou MDD) é uma das possíveis soluções para aumentar a velocidade do desenvolvimento
de um aplicativo computacional e, ao mesmo tempo, diminuir o seu custo. Por esses
dois motivos, o MDD tente a aumentar o poder de utilização de modelos para esta
finalidade (OMG, 2003). Para entender o que é Arquitetura Orientada a Modelo, (em
inglês, Model-Driven Architecture, ou MDA) é importante definir também o que é
MDD e explicitar a diferença entre ambos.
Desenvolvimento Orientado a Modelo é um paradigma de desenvolvimento de
software, que promove o uso de modelos em diferentes níveis de abstração e realiza
transformações entre estes com o objetivo de gerar a implementação de uma aplicação
concreta (HOVSEPYAN et al., 2006).
Já Arquitetura Orientada a Modelo é a visão do MDD pelo OMG (Object
Management Group) (OMG, 2003). O objetivo principal da abordagem MDA é a
geração de uma aplicação lógica independente da tecnologia que será utilizada para
implementar o sistema. A OMG tenta alcançar este objetivo especificando mecanismos
de padronização e notações de ferramentas de interoperabilidade (KLEPPE et al.,
2003).
Para deixar clara a diferença entre MDD e MDA, se pode dizer que MDD é um
paradigma genérico de desenvolvimento de software que pode ser aplicado de diferentes
maneiras, enquanto o MDA, definido pela OMG, visa descrever sistemas usando suas
padronizações pré-definidas.
A abordagem MDA proporciona o fácil entendimento de sistemas complexos e
do mundo real, fornecendo uma abstração do sistema físico, como mostra a Figura 1.
Conforme definido pelo (OMG, 2003) em sua especificação, o compromisso do MDA é
permitir a definição de uma aplicação que possa ser lida pela máquina e modelos de
dados que permitam uma flexibilidade de:
Implementação;
Integração;
Manutenção;
6
Teste e simulação.
(adaptada de ALMEIDA, P. DE, 2008)
2.1.1 Modelos e Metamodelos (CIM, PIM, PSM)
A OMG utiliza a Unified Modeling Language (UML) (UML, 2003) para a
modelagem de sistemas. Seu objetivo central é a criação de modelos distintos para os
diferentes níveis de abstração e o estabelecimento de uma ligação entre esses modelos
até chegar à implementação do sistema. A alguns desses modelos são independentes de
plataforma, enquanto outros, mais próximos à codificação, são voltados a uma
plataforma específica (MOREIRA, 2010).
De acordo com Miller, apud (ALMEIDA, P. DE, 2008), cada modelo é um
ponto de vista do sistema no que diz respeito aos conceitos de arquitetura e às regras de
estruturação que tenta abstrair. A OMG criou modelos em três níveis de abstrações, que
serão detalhados nas seções que seguem. São eles: Computational Independent Model
(CIM), Platform Independent Model (PIM) e Platform Specific Model (PSM). A Figura
2 apresenta as transformações entre cada nível de abstração.
Figura 1 - Arquitetura Orientada a Modelo
7
Figura 2 - O processo de transformação de modelos
(adaptada de ALMEIDA, P. DE, 2008)
Computation Independent Model (CIM)
Em português Modelo Independente de Computação, um CIM pode ser visto
como um elemento contratual, a serviço para conferir se os requisitos do cliente foram
corretamente realizados (ALMEIDA, P. DE, 2008). O CIM não deve conter detalhes da
estrutura do sistema, ele deve realizar uma ponte ligando de um lado os especialistas do
domínio e seus requisitos e, do outro lado os especialistas na elaboração do projeto e
construção do sistema (OMG, 2003).
Platform Independent Model (PIM)
O Modelo Independente de Plataforma (PIM) não deve conter particularidade
alguma de uma plataforma em específico, tal que seja adequado para ser usado em
diferentes plataformas, de tipos similares (OMG, 2003). O PIM deve ser uma
representação geral, em um alto nível de abstração, que capture a semântica e os
requisitos do domínio e seja preciso o suficiente para suportar uma transformação para a
próxima etapa do desenvolvimento.
8
Platform Specific Model (PSM)
Uma vez que o PIM já foi bem definido, nele é realizado um mapeamento que
visa permitir a transformação para uma plataforma em específico. O modelo resultante
da transformação é o Modelo Específico de Plataforma (PSM). Desta forma, é possível
perceber que a partir de um mesmo conjunto de modelos PIM é possível gerar um ou
mais PSM, para plataformas distintas, dependendo da variedade de mapeamentos que se
aplica.
Através do PSM uma ferramenta de transformação é capaz de gerar o código da
plataforma adotada, pois este modelo apresenta todas as informações já contidas no PIM
e mais os detalhes específicos da plataforma escolhida (ALMEIDA, P. DE, 2008).
2.1.2 Transformação de Modelos
O MDA suporta um desenvolvimento iterativo através de sucessivas
transformações entre os modelos. Um mapeamento entre modelos utiliza um ou mais
modelos como entrada e gera um modelo como saída (CUNHA, 2007).
A transformação entre os modelos se apoia num conjunto de regras de
mapeamento entre estes, que podem estar descritos em linguagens distintas (BOWLES,
2004). Estas regras de mapeamento são utilizadas pela ferramenta de transformação
para seguir as padronizações necessárias. A partir do conjunto de um ou mais modelos
PIM usados como entrada é então, gerado na saída, um modelo PSM que representa a
plataforma escolhida. A Figura 3 ilustra esse cenário.
De forma análoga, um modelo PSM pode ser mapeado para código fonte através
de uma ferramenta de transformação. Este mapeamento é trivial porque o PSM possui
toda informação necessária para a geração do código (ALMEIDA, P. DE, 2008).
9
Figura 3 - Transformação de modelo
(adaptada de OMG, 2003)
2.1.3 Modelos Padronizados (UML,MOF,XMI)
Existem padrões de modelagem abertos que são suportados pela especificação
OMG. A base do MDA para modelagem são a UML (Unified Modelling Language)
(UML, 2010), MOF (Meta Object Facility) (MOF, 2010) e XMI (XML Metadata
Interchange) (XMI, 2010).
Unified Modeling Language (UML)
A Unified Modeling Language é um resultado das melhores práticas da
engenharia de modelagem e tem sido utilizada com sucesso na modelagem de sistemas
complexos, conforme descreve Gasevic apud (ALMEIDA, P. DE, 2008). A UML é uma
poderosa linguagem para representações gráficas de modelos de aplicações. Os modelos
mais populares construídos com UML são os diagramas de Caso de Uso, de Classe e de
Atividade.
Meta Object Facility (MOF)
O Meta Object Facility é uma adaptação da UML criado para atender aos
requisitos da abordagem MDA. O MOF define elementos essenciais, sintaxes e
estruturas de metamodelos. O MOF é também um padrão OMG e, de acordo com
10
(POOLE, 2001), define uma linguagem abstrata para a especificação de
metametamodelos, isto é, um modelo de um metamodelo.
Antes do MOF, as ferramentas de cada fornecedor usavam mecanismos
proprietários, isto gerava um problema para os usuários, que gostariam de utilizar várias
ferramentas no processo de desenvolvimento, como também para os fabricantes que
deveriam realizar a integração de suas ferramentas com as demais. Através dos seus
mapeamentos, o MOF soluciona estes problemas, permitindo que ferramentas
compartilhem informação sobre modelos UML.
XML Metadata Interchange (XMI)
O MDA também é baseado no padrão XMI (XML Metadata Interchange), que
define mapeamentos de modelos e metamodelos do MDA em documentos e schemas
XML. Um dos propósitos do XMI é definir como as tags XML são usadas para
representar modelos MOF em XML (XMI, 2007) e, como o XMI é baseado em XML,
metadados e instâncias podem ser empacotados no mesmo documento.
2.1.4 Benefícios
A abordagem MDA representa um importante recurso na área de
desenvolvimento de software, no sentido que esconde “detalhes tecnológicos e de
engenharia que são irrelevantes para a funcionalidade principal de um componente de
software” (OMG, 2003). Em seu trabalho (ALMEIDA, P. DE, 2008) Almeida, destaca
três benefícios:
Interoperabilidade
O MDA introduz uma formalização de mapeamento entre metamodelos. As
aplicações são construídas em torno de modelos, os quais são definidos por
metamodelos e que, por sua vez, descrevem uma plataforma de interoperabilidade entre
as aplicações. Ou seja, A interoperabilidade entre duas aplicações é garantida pelos
mapeamentos fornecidos pelos respectivos metamodelos e modelos.
Portabilidade
A portabilidade no MDA é alcançada pelas particularidades durante a
transformação da plataforma PIM pra PSM. O Modelo Independente de Plataforma
11
contém todas as informações necessárias para a geração de qualquer PSM completo,
cada um com a possibilidade de ser construído baseado em uma linguagem de
programação diferente.
Produtividade
O desenvolvimento de um software utilizando a abordagem MDA permite que o
desenvolvedor se mantenha focado nas regras de negócio quando está na fase de
modelagem. Preocupações com os detalhes técnicos e específicos da plataforma
escolhida só precisam ser levados em conta durante a transformação do modelo PIM
para PSM.
2.2 Prospecção Tecnológica
A prospecção tecnológica, de acordo com Caruso e Tigre (CARUSO; TIGRE,
2004), pode ser definida como um meio sistemático de mapear desenvolvimentos
científicos e tecnológicos futuros capazes de influenciar de forma significativa a
indústria, a economia ou a sociedade como um todo. Segundo Porter (PORTER, 1991),
o objetivo da prospecção tecnológica é descrever em algum momento futuro a
emergência, o desempenho, as características ou os impactos de uma tecnologia, além
de entender as forças que orientam o futuro para dar direção e foco em ações e
mudanças.
Os modelos de previsão clássica se dedicam a antecipação de um futuro dito
como único. De maneira oposta, a prospecção parte do princípio de que existem
diversos futuros possíveis (CARUSO; TIGRE, 2004). Com posse deste conhecimento
se torna viável a realização de ações no presente de forma a moldar a construção de um
futuro desejável, como ocorre, por exemplo, com a inovação tecnológica.
2.2.1 Metodologias
Em seu trabalho, Meade e Islam (MEADE; ISLAM, 1998) identificam 29
métodos apropriados para prospecção tecnológica e os classifica em três diferentes
categorias. De outra maneira, Porter (PORTER, 1991) realiza a classificação dos
12
métodos em sete categorias e, ainda, Skumanich e Silbernagel os classifica em cinco
(SKUMANICH; SILBERNAGEL, 1997).
Neste trabalho vamos utilizar a classificação proposta por Coelho (COELHO, G.
M., 2003), que realizou uma combinação dessas categorias agrupando-as, de acordo
com suas semelhanças, em três diferentes abordagens. Cada abordagem é composta por
diversas técnicas e cada técnica possui métodos que as descrevem. As seções seguintes
correspondem às três abordagens propostas por Coelho.
2.2.2 Monitoramento e Análise de Tendências
Monitoramento
Monitoramento é uma técnica básica e bastante utilizada. Baseia-se no
monitoramento do ambiente através de fontes de informação, acompanhando a evolução
dos fatos e identificando a ocorrência de pequenas mudanças. As fontes de informação
de natureza técnica são as mais comuns: revistas, patentes, catálogos, papers etc.
Segundo Coates, com o passar do tempo o monitoramento pode ser substituído (ou
evoluído) pela inteligência competitiva tecnológica, ampliando sua abrangência e
atuação (COATES, 2001).
Análise de Tendências
A Análise de Tendências parte do princípio de que os padrões utilizados no
passado serão mantidos no futuro (SANTOS, M. DE M. et al., 2004). De início,
escolhe-se um tema, uma variável e, ao longo do tempo, coleta-se informações sobre
essa mesma variável. Através de técnicas matemáticas e estatísticas essa variável é
extrapolada para um ponto no futuro. Com esse resultado em mãos a etapa seguinte é
realizar uma análise dessa projeção, podendo contar com opiniões de especialistas e, a
partir de então, estabelecer intervalos de confiança. Os métodos mais utilizados nessa
técnica são: Regressão, Curva S e Equações de Lotka-Volterra.
2.2.3 Modelos computacionais e ferramentas analíticas
A característica dessa abordagem é a utilização de ferramentas computacionais e
tecnologia da informação para realizar prospecções.
13
Simulação
Uma dessas técnicas é a Simulação, na qual se identifica variáveis e se cria um
modelo computacional com o objetivo de tentar prever como essas variáveis irão
interagir com o passar do tempo. Existem diferentes métodos de Simulação, como a
Matriz de Impactos Cruzados, KSIM e Sistemas dinâmicos.
Modelagem
A Modelagem envolve o uso de métodos analíticos formais para desenvolver
retratos do futuro (COELHO, G. M., 2003). O método da Árvore de relevância, também
conhecido como método “normativo”, baseia-se nos métodos de análise de sistemas. A
partir de problemas e necessidades futuras identifica-se o desempenho tecnológico
necessário para satisfazer essas necessidades (SANTOS, M. DE M. et al., 2004).
Outro método de Modelagem é o AHP (Analytical Hierarchy Process), criado
por Thomas Saatu, que se especializou na modelagem de problemas de decisão não
estruturada. O AHP executa essa tarefa em quatro estágios básicos: sistematizar o
julgamento em hierarquia ou árvore; fazer comparações elementares de pares; sintetizar
esses julgamentos de pares para chegar a julgamentos gerais; checar se os julgamentos
combinados são razoavelmente consistentes entre si (PORTER, 2004).
Data Mining, Text Mining, Cientometria, Biliometria
A Cientometria e a Bibliometria tratam da contagem de publicações e citações.
Essas ferramentas são muito utilizadas na comunidade científica para a identificação de
redes de cooperação e medição da produtividade científica.
Tanto a Data Mining como a Text Mining se utilizam de grandes repositórios de
dados para, a partir destes, extrair informações. O primeiro utiliza tecnologias de
reconhecimentos de padrões, técnicas estatísticas e matemáticas, enquanto o segundo
aplica técnicas de tratamento automático de linguagem natural e classificação
automática (COELHO, G. M., 2003). Esses dois métodos, utilizados juntamente com a
Cientometria e Bibliometria, possibilitam descobrir importantes informações dentre
milhões de dados.
14
2.2.4 Opinião de especialistas, criatividade e cenários
As técnicas desta abordagem têm em comum a fundamental participação
humana e a subjetividade. Consiste na antecipação de possibilidades futuras com base
em interação não estruturada entre especialistas, cada um deles apoiado exclusivamente
em seus conhecimentos (CARUSO; TIGRE, 2004).
Opinião de especialistas
A opinião de especialistas foi definida por Millet, apud (SKUMANICH;
SILBERNAGEL, 1997), como uma técnica “baseada na informação e lógica de
indivíduos com extraordinária familiaridade com o tema em questão” para construir
uma visão do futuro.
Opinião de especialistas – Delphi
Apesar de ser uma técnica fundamentada na intuição humana o método
qualitativo Delphi vem sendo utilizado com sucesso há muito tempo na prospecção.
Segundo Jones, apud (CARUSO; TIGRE, 2004), este é considerado o mais proeminente
dentre os métodos de prospecção baseados em consenso.
O método Delphi foi criado por Olaf Helmer e N. Rescher, na década de 50, nos
Estados Unidos e apresentado de forma estruturada por Helmer em 1968. De acordo
com Oliveira, apud (COELHO, G. M., 2003), o Delphi se distingue por três
características básicas: anonimato entre os especialistas integrantes do grupo; interação
com feedback controlado; respostas estatísticas do grupo.
O princípio do método é intuitivo e interativo. Implica a constituição de um
grupo de especialistas em determinada área do conhecimento que respondem a um
questionário. Os resultados dessa primeira fase são analisados e a síntese dos resultados
é comunicada aos membros do grupo que, após tomarem conhecimento do resultado,
respondem novamente. O produto final deverá ser uma previsão que contenha o ponto
de vista da maioria.
Opinião de especialistas - Web Delphi
O Web Delphi é uma ferramenta desenvolvida pelo Programa de Estudos do
Futuro da Universidade de São Paulo – USP, coordenado pelo Prof. James Wright, apud
(COELHO, G. M., 2003).
15
Baseado no método Delphi tradicional, é utilizado na prospecção de futuro e
formulação de estratégias em grupo, por meio da internet. É indicado para situações de
mudanças estruturais, inexistência de dados históricos ou horizontes de tempo muito
longos.
Opinião de especialistas – Avaliação Individual
A avaliação individual tem por objetivo obter a opinião de indivíduos sobre
determinado tema que podem vir a ser obtida pessoalmente, por telefone ou por correio
eletrônico. A consulta tipicamente envolve uma série de entrevistas pessoais. As
entrevistas podem ser estruturadas, não-estruturadas ou focadas (dirigidas a pessoas
com conhecimento pertinente ao tema) (SANTOS, M. DE M. et al., 2004).
Opinião de especialistas - Surveys
Um outro método que utiliza a opinião de especialistas é o survey, o qual é
frequentemente utilizado quando se torna difícil a realização de encontros pessoais.
Esse método se fundamenta na premissa de que a avaliação de um grupo tem uma maior
probabilidade de estar correta em relação a uma avaliação individual (COELHO, G. M.,
2003). As perguntas devem ser claras e na linguagem apropriada das pessoas que irão
responder. Também é comum permitir respostas abertas para captar a opinião de cada
um. Apesar de não haver o contato direto com os especialistas, esse método tem como
ponto positivo ser ágil e a baixo custo.
Criatividade
Criatividade é a capacidade de tentar visualizar futuros alternativos. Guilford,
apud (PORTER, 1991), cita cinco elementos essenciais para o desenvolvimento da
criatividade:
Fluência: gerar muitas ideias;
Flexibilidade: não se prender a velhos conceitos;
Originalidade: ter ideias diferenciais;
Percepção: conseguir fazer conexões e relações não óbvias;
Vigor: motivação e força para realizar
Alguns métodos de criatividade são bastante utilizados, como o Brainstorming,
Focus Group e Analogias.
16
Cenários
Cenários representam a descrição de uma situação futura e do conjunto de
eventos, que permitem a passagem da situação original para a situação futura. O futuro
é múltiplo e diversos futuros potenciais são possíveis: o caminho que leva a um futuro
ou outro não é necessariamente único. A descrição de um futuro potencial e a
progressão em direção a ele representa um cenário (GODET; ROUBELAT, 1996).
Michael Godet criou seu método denominado La Prospective, em 1983. Ainda
sobre a criação de cenários outro método é o SWOT (Strenghts, Weaknesses,
Opportunities, Threats), que poderia ser traduzido como Forças, Fraquezas, Ameaças e
Oportunidades.
17
3. Trabalhos Relacionados
Durante a pesquisa foram encontrados alguns trabalhos que também se
propuseram a realizar pesquisas em MDA, cada um com uma particularidade que o
diferencia.
Em seu trabalho, (ASADI; RAMSIN, 2008) Asadi e Ramsin fazem uma análise
de metodologias de desenvolvimento baseadas em MDA. Seis metodologias foram
selecionadas, com a escolha baseada na disponibilidade de recursos e documentação
apropriada. Essas metodologias são brevemente introduzidas, dispostas em uma tabela
de comparação e avaliadas de acordo com critérios estabelecidos pelos autores. Este
trabalho não leva em conta nenhum tipo de ferramenta ou área em específico da MDA.
O objetivo é a análise comparativa de metodologias de desenvolvimento.
Com uma abordagem diferente, em (CABOT; TENIENTE, 2006) é realizada
uma análise de ferramentas MDA, centrada em suas restrições. Estas ferramentas foram
classificadas em quatro subgrupos:
1. Ferramentas CASE;
2. Ferramentas MDA;
3. Ferramentas OCL;
4. Métodos MDD.
Cada uma das ferramentas passa por uma avaliação sob os critérios estabelecidos
pelos pesquisadores.
A proposta apresentada em (GIESE; HENKLER, 2006) é um survey de
abordagens MDD. Os autores estabelecem tipos de abordagens e requisitos do
desenvolvimento de software que devem ser atendidos. O objetivo principal do trabalho
é a realização de uma análise comparativa em relação aos tipos de abordagens
estabelecidos e, a partir desta análise, identificar requisitos que são ou não suportados
em cada abordagem.
Singh e Sood em (SINGH, Y.; SOOD, M., 2008) apresentam uma revisão dos
conceitos da MDA e sumarizam vantagens e desvantagens de seu uso, de acordo com
sua visão.
Dos trabalhos mencionados anteriormente (ASADI; RAMSIN, 2008), (CABOT;
TENIENTE, 2006) e (GIESE; HENKLER, 2006) realizam pesquisas em MDA, porém
cada um deste se restringe a uma área específica do conhecimento, como ferramentas de
desenvolvimento ou tipos de metodologias. Já (SINGH, Y.; SOOD, M., 2008) não se
18
aprofunda em pesquisas na área, mantendo o foco em fornecer uma perspectiva da
MDA, sob seus conceitos. De forma diferente o presente trabalho procura olhar toda a
MDA e analisar trabalhos realizados, adotando a especificação OMG como ponto de
visão. Ainda sob o aspecto da especificação este trabalho também se propõe a realizar
uma prospecção na área, tomando como ponto de partida a análise de outros trabalhos e
uma entrevista, no formato de questionário, realizada com conhecedores do assunto.
19
4. Classificação Proposta e Análise Geral
A MDA é uma metodologia que se encontra ramificada em diversas linhas de
pesquisa. A especificação criada pela OMG abrange os aspectos do CIM, PIM, PSM,
Transformação de Modelo, dentre outros. Dada a extensão desta área, a realização de
uma pesquisa não é uma tarefa trivial.
Para que se possa obter qualidade em uma pesquisa deste porte, é importante que
a pesquisa esteja fundamentada de acordo com técnicas da literatura. A seção a seguir
descreve o posicionamento da pesquisa realizada em relação à revisão sistemática.
4.1 Revisão Sistemática
Uma revisão sistemática, assim como outros tipos de estudo de revisão, é uma
forma de pesquisa que utiliza como fonte de dados a literatura sobre determinado tema.
Esse tipo de investigação disponibiliza um resumo das evidências relacionadas a uma
estratégia de intervenção específica, mediante a aplicação de métodos explícitos e
sistematizados de busca (SAMPAIO; MANCINI, 2007).
A revisão sistemática teve o seu início na medicina, porém é cada vez mais
comum o seu uso em outras áreas do conhecimento. Para a realização de uma revisão
sistemática, segundo The Cochrane Group (COCHRANE, 2011), é preciso seguir
detalhadamente uma sequência de sete passos:
I. Formulação da pergunta – uma pergunta bem formulada é o passo inicial na
realização da revisão sistemática;
II. Localização e seleção dos estudos – não existe uma única fonte de busca de
estudos. Determinar quais serão as bases utilizadas;
III. Avaliação crítica dos estudos – são critérios para determinar a exclusão e seleção
dos resultados da busca;
IV. Coleta de dados – todas as variáveis estudadas devem ser observadas. Algumas
vezes, pode ser necessário entrar em contato com o autor do trabalho para pedir
mais detalhes;
V. Análise e apresentação dos dados – baseado em pontos semelhantes entre os
trabalhos encontrados. Cada um dos agrupamentos deve ser preestabelecido no
projeto;
20
VI. Interpretação dos dados – interpretar a aplicabilidade dos resultados e determinar
informações relevantes;
VII. Aprimoramento e atualização da revisão – após terminada a revisão, esta sofrerá
críticas e sugestões que devem ser incorporadas às edições subseqüentes.
4.2 Metodologia de pesquisa
É importante o posicionamento da metodologia de pesquisa que foi utilizada no
presente trabalho em relação às técnicas da revisão sistemática, tendo como objetivo
informar ao leitor, com clareza, a forma como a pesquisa foi conduzida e estabelecer os
seus limites.
Para o passo I da revisão sistemática, o objetivo desta pesquisa é atingir uma
vasta quantidade de trabalhos, conjugada com a preocupação de que esta venha a
apresentar novas informações com ganho de qualidade. Inicialmente, as buscas foram
realizadas com a utilização de palavras mais abrangentes, como “MDA”, “Model
Driven Architecture”, “MDD”, “Model Driven Development”. Durante as buscas pôde
ser observada a existência de siglas homônimas, isto é, siglas de mesma grafia com
significados distintos. Como exemplo, tomemos a sigla MDA, que apresenta vários
significados como: Ministério do Desenvolvimento Agrário, Muscular Dystrophy
Association, Media Development Authority, Malaysian Dental Association dentre outros
possíveis existentes.
O passo II consiste na definição dos locais de pesquisa. Foram utilizadas as
bases de pesquisa DBLP Computer Science Bibliography (DBLP, 2011), ACM
Computing Surveys (ACM, 2011), ISI Web of Knowledge (ISI, 2011), Science Direct
(SCIENCEDIRECT, 2011), IEEE Digital Library (IEEE, 2011).
No passo III são definidos e aplicados os critérios de filtragem, que devem
decidir se um trabalho resultante da busca deve ou não entrar na seleção. O critério
adotado para a seleção dos artigos foi a análise das duas primeiras páginas de resultados
da busca, em cada uma das bases aplicadas.
A estes trabalhos foram, então, aplicados as duas fases do processo de filtragem
pertencentes ao passo III. A primeira fase consiste em definir como é efetuada a
exclusão de trabalhos. O critério de exclusão adotado foi através da verificação do título
21
e abstract, nessa ordem. Os trabalhos que não se enquadraram no contexto da pesquisa
foram excluídos e os outros foram adquiridos e lidos por inteiro.
A fase seguinte, ainda no passo III, consiste em definir o refinamento da busca.
Após identificar as linhas de pesquisa, todas as consultas em todas as bases definidas
foram refeitas, desta vez buscando por palavras-chaves mais específicas. Por exemplo,
para a categoria PIM foram realizadas novas buscas utilizando as palavras “Platform
Independent Model”, “PIM”, “Modelo Independente de Plataforma”. Esse processo foi
realizado para todas as categorias da taxonomia proposta. Com os novos resultados se
inicia um novo ciclo de leitura e exclusão dos trabalhos fora de contexto.
A Tabela 1 apresenta a listagem de alguns dos periódicos presentes no trabalho,
de acordo com o seu Qualis. Além destes também foram incluídos artigos da OOPSLA
(Object-Oriented Programming, Systems, Languages & Applications), importante
conferência anual na área, mantida pela ACM; e artigos que levam o nome de Oscar
Pastor, reconhecido autor desta área.
Tabela 1 - Listagem de periódicos
PERIÓDICO QUALIS
Software Quality Journal B2
IEEE Transactions on Power Systems B2
Science of Computer Programming B1
Requirements Engineering A2
International Journal of Software Engineering and Knowledge
Engineering
B1
IEEE Software A2
Lecture Notes in Computational Science and Engineering B2
Software and Systems Modeling B2
Knowledge-Based Systems A2
IEICE Transactions on Information and Systems B1
International Journal of Software Engineering and Knowledge
Engineering
B2
Information and Software Technology B1
Journal of Universal Computer Science B2
Em relação ao passo IV, a realização que mais se aproximou dele foi a busca
pelos artigos recomendados pelos entrevistados que responderam ao formulário de
perguntas. Outra maneira pela qual alguns trabalhos foram obtidos foi através de
22
citações de outros trabalhos. A inclusão destes é feita de forma gradual conforme são
observados durante a leitura.
No passo V devem ser definidos os grupos semelhantes. A seção 4.3 fala com
mais detalhes de como foi realizada a escolha das categorias para a classificação dos
trabalhos.
A realização efetuada em relação ao passo VI consistiu na identificação do
estado da arte e áreas com carência de pesquisa. Estes resultados foram possíveis de ser
obtidos somente após a definição e leitura de cada conjunto de trabalhos, agrupados por
categoria.
Por fim, o passo VII consiste na manutenção do estudo num momento futuro,
acrescentando novos trabalhos às categorias definidas.
4.3 Classificação
No início deste trabalho o que havia era um conjunto de artigos, dispostos ainda
de forma ainda desorganizada. Porém, era necessário realizar uma classificação para
que os trabalhos pudessem ficar dispostos em grupos. A primeira classificação realizada
teve como taxonomia o objetivo principal do trabalho. Esta classificação foi criada com
as cinco categorias descritas a seguir:
Níves de Modelagem;
Estudo de Caso;
Ferramentas;
Interação com Usuário;
Metamodelagem.
Nesta classificação apresentada, os trabalhos cujo objetivo principal é a
apresentação de estudos de caso foram enquadrados na categoria de mesmo nome. Os
trabalhos que se preocupavam em apresentar as descrições e funcionalidades de alguma
ferramenta se enquadravam na categoria que possuía este nome.
Havia casos de trabalhos que se enquadravam em mais de uma categoria, por
vezes em três. Criar novas categorias ou subdividi-las em outras, também não resolveria
o problema. A solução parecia ser a adoção de uma nova taxonomia.
23
Conforme prosseguia a leitura dos trabalhos, cada um deste recebia algumas
anotações e marcações sobre o seu principal assunto. Estas marcações foram decisivas
para a escolha da nova taxonomia.
A especificação criada pela OMG se encontra dividida numa forma sequencial
através das etapas do processo de desenvolvimento. Estas etapas do processo apareciam
frequentemente nas marcações feitas em cada trabalho, que identificavam o seu assunto
principal. Somado isto ao fato da MDA ter sido iniciada pelo OMG, a nova taxonomia
criada foi baseada na descrição da especificação OMG. Desta forma, os trabalhos se
encontram classificados nas categorias:
CIM;
Transformação CIM para PIM;
PIM;
Mapeamento de Modelo;
Transformação PIM para PSM;
É importante ressaltar que a ordem em que as categorias são apresentadas é a
ordem das etapas do processo de desenvolvimento MDA, seguindo o que se encontra
estabelecido na especificação.
As categorias CIM e PIM englobam os trabalhos que tratam do processo de
construção destes modelos. Os trabalhos cujo tema principal é o processo de
mapeamento ou transformação, se encontram em suas respectivas categorias.
A Figura 4 representa a classificação proposta, com a divisão das áreas de
acordo com a especificação OMG.
24
Figura 4 - Classificação de acordo com a especificação OMG
A ferramenta Mendeley Desktop (MENDELEY, 2010) foi escolhida para
realizar o gerenciamento dos trabalhos que se encontram nesta dissertação. Nela foi
criada uma biblioteca organizando os trabalhos de acordo com suas respectivas
categorias. Como o Mendeley funciona em sincronia com sua versão web, esta
biblioteca pode ser futuramente disponibilizada online.
As próximas subseções deste capítulo correspondem a cada uma das categorias
da classificação proposta. Em cada categoria foi aplicada a técnica de prospecção de
monitoramento. Elas iniciam-se com uma descrição do seu escopo, seguido por uma
série de trabalhos analisados e, ao final, o estado da arte e suas perspectivas futuras.
Adicionalmente, o Anexo III deste trabalho apresenta uma tabela relacionando
cada trabalho com as categorias em que ele se enquadra.
4.3.1 CIM
4.3.1.1 Escopo
O Computation Independent Model, ou Modelo Independente de Computação
tem o intuito de fazer a união entre os requisitos de negócios com os demais modelos
25
que são criados nas próximas etapas de desenvolvimento. O CIM deve ser capaz de
representar a aplicação em seu ambiente global (ALMEIDA, P. DE, 2008).
O especialista que realiza a construção do CIM deve capturar o conhecimento do
domínio e representá-lo em um modelo sem fazer referência a determinada
implementação ou tecnologia em particular.
Nesta categoria foram incluídos 13 trabalhos provenientes de pesquisas
realizadas nas bases já mencionadas.
O cuidado se faz necessário na classificação dos trabalhos, identificando o seu
tema principal para que este seja adequadamente enquadrado. O escopo desta categoria
abrange os trabalhos que discutem as informações que não podem faltar ao CIM e a
importância deste modelo para as demais fases do processo. Dentro desta categoria
também foram classificados os trabalhos que discutem e comparam diferentes
linguagens que podem ser utilizadas para construir o CIM e, por fim, esta categoria
também abrange os trabalhos que têm a iniciativa de formalizar e estabelecer um padrão
para este modelo.
4.3.1.2 Trabalhos e Considerações
O Modelo Independente de Computação é muito importante na fase inicial de
desenvolvimento de software, principalmente na construção de sistemas de informações
empresariais. Singh e Sood propõem, em seu trabalho (SINGH, YASHWANT; SOOD,
MANU, 2010), que um CIM pode ser retratado através de três diagramas:
Diagrama de Caso de Uso;
Diagrama de Atividades;
Diagrama de Sequência.
Estes três diagramas formam um modelo conceitual capaz de representar os
requisitos existentes em um sistema de informação empresarial. Na Figura 5 podem ser
observadas as divisões destes requisitos e a proposta do CIM.
26
Figura 5 - Modelo Conceitual CIM
(adaptada de SINGH; SOOD, 2010)
A priori a construção de um CIM pode ser muito subjetiva. Se o cliente não
demonstrar total segurança com os requisitos, essa comunicação pode vir a ser falha.
Para apoiar ambos envolvidos existe uma notação desenvolvida pelo OMG, a Business
Process Model and Notation (BPMN), definida em (BPMN, 2011). Cabe destacar que
existem algumas ferramentas que suportam essa notação e auxiliam no processo de
modelagem do CIM.
Em (FOUAD et al., 2010), Fouad et al. discutem que o BPMN não é suficiente
para representar todo o necessário nessa fase da modelagem. Como argumento para
defender esta afirmação é apresentado um exemplo onde um mesmo caso de uso é
modelado via UML e BMPN. A modelagem via UML se mostra mais completa. Esta
afirmação é corroborada em (HARRISON-BRONINSKI, 2006). Segundo este autor, o
BPMN é uma notação que não consegue representar satisfatoriamente o comportamento
humano no processo de negócio.
Outra proposta de construção do CIM é apresentada em (LEONARDI, M. C.;
MAUCO, M. V., 2009) e (DEBNATH et al., 2008). Estes trabalhos discutem a geração
da estrutura de um CIM através de modelos de linguagem natural. As linguagens
27
abordadas são a Language Extended Lexicon (LEL) e Scenario Model (LEITE et al.,
2000). O CIM resultante é gerado de uma maneira semi-automática.
Esta iniciativa de automatizar a construção do CIM, mesmo que ainda não seja
uma automatização de todo o modelo resultante, é interessante, pois encoraja o uso de
métodos e ferramentas para a construção do modelo, o que colabora no sentido de
reduzir o número de CIM’s produzidos manualmente.
Um CIM também pode ser atingido através de uma combinação de outros.
Garrido et al. em (GARRIDO et al., 2007) realizam a construção de modelos CIM’s
utilizando em conjunto UML e OWL (SMITH et al., 2004). O levantamento de
requisitos do negócio é suportado por um framework conceitual chamado AMENITIES,
apresentado em (MATE; SILVA, A., 2005). Nesta abordagem proposta todo o processo
de elaboração do CIM ocorre de forma colaborativa.
A análise orientada a objeto sugere técnicas semi-formais para a fase de
modelagem de domínio. Em (OSIS et al., 2007), foi introduzida a abordagem
Topological Functioning Modeling for Model Driven Architecture (TFM4MDA) que
suporta a construção de CIM.
A TFM4MDA faz grande uso de fundamentos matemáticos e tem como um de
seus preceitos o aumento do nível de formalização desta etapa do desenvolvimento de
software através de modelos. Osis et al. têm por objetivo elevar a capacidade de
manuseio com a linguagem natural, a fim de tornar possível a automatização de mais
passos da construção de CIM e obter uma diminuição da participação humana na
tomada de decisões.
O OMG, em 2005, iniciou o desenvolvimento de um novo padrão, o Semantics
of Business Vocabulary and Business Rules – SBVR. Este padrão deve ser a base para
que uma linguagem natural formal e detalhada seja capaz de descrever uma entidade
complexa. Em 2008 o OMG lançou um documento formal com a especificação do
SBVR (SBVR, 2008).
O SBVR, juntamente com o Knowledge Discovery Metamodel – KDM (KDM,
2008), são iniciativas do OMG para análise de software relacionado a sistemas de
informação. O KDM define uma ontologia que diz respeito a artefatos de software,
provendo uma formalização inicial da informação, enquanto o SBVR é mais usado para
28
a formalização de regras complexas de conformidade também relacionadas ao sistema
de informação.
O padrão SBVR utiliza MOF para fornecer recursos às regras de mapeamento
MOF/XMI e propõe o Inglês Estruturado (pseudo-código) como uma das possibilidades
de notação. A especificação SBVR define quatro pontos de conformidade:
Significado e Representação;
Formulação Lógica e Semântica;
Vocabulários de Negócios;
Regras de Negócios.
A Figura 6 representa estes quatro pontos:
Figura 6 - Pontos de conformidade
(adaptada de SBVR, 2008)
A seção 4.1.2 contém mais detalhes do SBVR e como este seria usado em uma
transformação CIM para PIM.
Como referências adicionais, o tema discutido nesta seção também pode ser
encontrado nos trabalhos (BRITTON; DEVOS, 2005) e (ZHANG, JIANFU et al.,
2010).
29
Após a finalização desta categoria foi possível notar tentativas de automatização
da construção do CIM. Entretanto, na maior parte dos trabalhos analisados constatou-se
que o CIM ainda é construído manualmente, tendo como um exemplo o uso manual de
UML. Diversas técnicas de construção do CIM se aplicam, sendo a Linguagem Natural
a técnica utilizada em maior escala.
Durante a leitura dos trabalhos foi realizado um monitoramento dos mesmos,
através de observação e análise dos trabalhos futuros. Neste ponto, foi observado um
esforço para evoluir a área na direção de estabelecer regras de transformação do modelo
de regras de negócio, baseado em heurística. Estas regras, no entanto, não se encontram
atualmente consolidadas.
O processo de construção de um CIM, apto a sofrer um processo de
transformação em que ocorra a geração de um PIM, refletindo as regras definidas no
CIM original, ainda é um problema em aberto.
Os trabalhos classificados nesta categoria demonstram uma preocupação em
reduzir a lacuna existente entre os requisitos do negócio e o processo de
desenvolvimento de software.
4.3.2 Transformação CIM PIM
4.3.2.1 Escopo
O Modelo Independente de Computação deve conter a descrição dos requisitos e
do domínio a partir de um ponto de vista do sistema e seu ambiente. O Modelo
Independente de Plataforma não inclui nenhum detalhe específico da plataforma, seu
objetivo principal é ser um conceito abstrato do sistema usando vocabulário do domínio
tanto quanto possível.
A especificação OMG afirma que o CIM, no contexto da MDA, tem um papel
importante no processo de desenvolvimento de sistemas, assegurando que o CIM é um
componente essencial para realizar a ponte entre os especialistas do domínio e os
elaboradores do sistema (OMG, 2003). Contudo, ao tratar das transformações de
modelos, a especificação se concentra nos detalhes da transformação do PIM para PSM
e não descreve informações de como obter um PIM, de maneira automatizada, a partir
do CIM.
30
Nesta seção foram incluídos 11 trabalhos, que tratam de estudos e propostas para
automatizar a geração de um PIM a partir de um CIM.
Esta parte da MDA corresponde a uma das falhas existentes na especificação
OMG. Os trabalhos classificados nesta categoria não implementam, de fato, a
transformação de um CIM para PIM. Estão aqui classificados os trabalhos que realizam
tentativas, mesmo que teóricas de prover essa transformação. Também se enquadram
nesta categoria os trabalhos que utilizam o Modelo Independente de Computação para
gerar, de forma automatizada, algum outro produto que não seja o PIM. E, por fim, esta
categoria também abrange as tentativas de realizar uma padronização dessa
transformação de modelo, ainda inexistente.
4.3.2.2 Trabalhos e Considerações
Uma proposta para realizar a transformação do CIM para o PIM é apresentada
em (FOUAD et al., 2010). Fouad et al. defendem o uso de UML para realizar a
representação do modelo CIM, sendo este mais completo para contemplar detalhes
necessários de regras de negócio que o BPMN. A proposta deste trabalho seria estender,
“enriquecer” o CIM, de forma que seja factível aplicar uma transformação visando à
obtenção de um PIM.
A Figura 7, marcada com A, retrata o CIM isolado do processo atual de
transformação em MDA. A Figura 8, marcada com B, ilustra a proposta de extensão do
CIM e como este passaria a integrar o processo de transformação.
31
Figura 7 - Pontos de vista MDA
(adaptada de FOUAD et al., 2010)
Figura 8 - MDA estendido
(adaptada de FOUAD et al., 2010)
Este trabalho descreve a arquitetura do framework de extensão ao MDA, o
SuperCIM, e sua aplicabilidade teórica em um estudo de caso, contudo não foi obtida
nenhuma transformação na prática. Ainda são necessários mais estudos para aprimorar a
abordagem e viabilizar o processo de transformação.
Em (VIDALES et al., 2008), Vidales et al. apresentam uma forma de combinar
aspectos básicos da especificação MDA com BPM (Business Process Management),
SOA (Service Oriented Architecture) e On Demand Business. Essa combinação seria
32
responsável por aprimorar o desenvolvimento de software, fornecendo uma maneira de
levar um CIM a um PIM.
O passo inicial é a utilização de BPM para definir um CIM, que deve conter as
lógicas de negócio. Este CIM é associado a modelos de softwares, baseados nos
serviços. O caminho para levar este CIM a um PIM é baseado na arquitetura SOA
(CHEN, YING, 2006), que deve realizar uma conexão entre os serviços da camada de
negócio e os serviços da camada de software. No trabalho também é descrito que seria
necessário alcançar o conceito On Demand Business para poder aplicar esse processo a
nível empresarial.
O grupo Garrido et al. apresentou uma proposta de aliar MDA com CSCW
(Computer Supported Cooperative Work), de forma a permitir o desenvolvimento de
aplicações groupware. Em seu trabalho (GARRIDO et al., 2007) eles utilizam CIM’s
baseados em ontologias, como OWL, e CIM’s baseados em UML. Para a construção do
CIM é utilizado um framework conceitual chamado AMENITIES, previamente
mencionado na seção 4.1.1.
Para realizar a integração entre os CIM’s os autores propõem um modelo
colaborativo, denominado por COMO-CIM. O COMO-CIM utilizaria uma notação
denominada COMO-UML, baseada em UML junto com diagrama de atividades. A
ideia é conseguir realizar uma transformação MDA para gerar de forma automática um
COMO-PIM, que seria um modelo PIM contendo as regras e serviços contemplados em
todos os CIM’s originais. Este passo, porém, ainda é apenas teórico.
A segurança dos processos de negócios é uma questão de suma importância em
qualquer ambiente empresarial, apesar disso a identificação dos requisitos de segurança
tem sido realizada de maneira confusa.
Em geral, há uma tendência a identificar os requisitos funcionais de segurança.
Este tipo de requisito (funcional) varia de acordo com o tipo de aplicação, enquanto que
os requisitos de segurança, de maneira geral, não variam em um alto nível de abstração
O SBP, em inglês Secure Business Process é apresentado em (RODRÍGUEZ et
al., 2007a). Em poucas palavras, o SBP se caracteriza por utilizar o BPMN-BPD e o
BPSec, duas extensões ao BMPN, para apoiar a captura dos requisitos de segurança
expressos pelo analista de negócios.
Em (RODRÍGUEZ et al., 2007b), Rodríguez et al. propõem uma maneira de se
obter um conjunto de casos de uso UML, que representa um PIM, a partir de uma
33
especificação SBP, que representa um CIM. A Figura 9 ilustra esta proposta através de
uma analogia com os componentes da MDA.
Figura 9 - Visão geral da proposta com SBP
(adaptada de RODRÍGUEZ et al., 2007b)
As transformações são descritas como um conjunto de regras QVT (QVT, 2008),
checklists e regras de refinamento. O trabalho descreve, através de um exemplo, como
esse conjunto de regras deve ser utilizado com a finalidade de se obter os casos de uso
UML.
Os casos de uso UML representam, de fato, um CIM, todavia o processo
descrito para sua obtenção é um protótipo, sendo executado manualmente. Ainda se faz
necessário realizar aperfeiçoamentos neste processo de obtenção do PIM, para que este
possa caracterizar uma transformação automatizada.
A transformação de CIM para PIM também se mostra de grande valia em outras
áreas da computação além do desenvolvimento de sistemas de informação.
Um grupo de estudiosos da área desenvolveu um método para a construção de
Data Warehouses (DWs) através da MDA (ZEPEDA et al., 2010). Este método utiliza
como entrada um CIM, devendo ser construído com diagramas de atividades UML e
carregar os requisitos do usuário, assim como a descrição lógica do banco de dados
operacional. Através de um processo automatizado, ocorre a identificação de esquemas
multidimensionais no banco de dados operacional e são criadas diferentes instâncias de
PIM multidimensionais. O passo final integra estes dois pontos de vista em um novo
34
modelo, a partir do qual se aplica um processo de transformação de modelo gerando o
código SQL que melhor reflete os requisitos do usuário.
Apesar de não haver a geração de um modelo PIM, Zepeda et al. realizaram de
forma eficiente operações automatizadas no CIM, produzindo código SQL como
resultado.
Conforme mencionado em 4.1.1, o OMG desenvolveu o padrão SBVR com o
objetivo de servir de base para que uma linguagem natural formal e detalhada seja capaz
de descrever uma entidade complexa (SBVR, 2008).
A especificação formal do SBVR inclui um posicionamento deste em relação à
MDA, descrevendo sua aplicabilidade no interior da camada de modelo de negócio. A
Figura 10 ilustra esse posicionamento:
Figura 10 - Posicionamento do SBVR em uma Arquitetura Orientada a Modelo
(adaptada de SBVR, 2008)
Na Figura 10 é possível notar que somente o uso de SBVR não é suficiente para
se obter a possibilidade de uma transformação no sentido de gerar um PIM.
35
O SBVR é voltado para conceitos, vocabulários e regras de negócios. Além
destes, outros aspectos do modelo de negócios também precisam ser desenvolvidos,
como processos de negócios e estrutura organizacional. A OMG defende que existem
outras iniciativas atuando nestes pontos.
Com abordagens diferentes, os trabalhos (CAO et al., 2009), (KHERRAF et al.,
2008) e (ZHANG, JIANFU et al., 2010) também tratam de iniciativas para a obtenção
de um PIM a partir de um CIM.
A partir da leitura dos trabalhos foi observado que não há, hoje, uma
transformação automatizada a partir do Modelo Independente de Computação que
resulte em um Modelo Independente de Plataforma. Conforme mencionado na seção
anterior, esta etapa do processo MDA ainda é um problema em aberto.
A especificação OMG é insatisfatória quanto a este tipo de transformação,
concentrando-se mais nos detalhes da transformação de PIM para PSM. Apesar disto, se
nota algum esforço para se obter o PIM a partir do CIM, dado a importância que seria
essa geração automática do PIM, de forma que este seria uma reflexão fiel de todas as
regras de negócio previamente estabelecidas no domínio.
Algumas dessas tentativas de obtenção do CIM foram realizadas com sucesso,
porém nenhuma totalmente automática. Em sua maioria essas tentativas são estudos que
propõem como deve ser realizada a transformação, todavia continuam no campo
teórico, ou são transformações realizadas manualmente e com o apoio de outros
componentes externos.
Como esta etapa do processo MDA não é atualmente automática, os trabalhos
futuros desta área se concentram justamente na tentativa da automatização da
transformação. Existem esforços para automatizar transformações atualmente manuais,
como também, para implementar propostas teóricas.
Dentre esses esforços se destaca a iniciativa do próprio OMG de padronização
do CIM. Como mencionado em (SBVR, 2008) o padrão SBVR é estabelecido como um
dos componentes para a descrição do modelo de negócios. Este padrão deve ser
utilizado em conjunto com outros componentes, ainda não existentes, para compor um
CIM padronizado, que deve fornecer suporte para viabilizar a criação de um processo de
transformação com a finalidade de se obter o PIM.
36
4.3.3 PIM
4.3.3.1 Escopo
O Platform Independent Model, ou Modelo Independente de Plataforma é
responsável por conter a descrição das funcionalidades do sistema com base nos
requisitos, sem carregar a descrição de alguma plataforma de execução em específico.
De forma ideal, o design da aplicação não deve considerar os aspectos da
tecnologia na qual esta será construída, tais como sistema operacional, linguagem de
programação, hardware, etc. Por esse motivo, o PIM deve conceder uma visão do
sistema adequável para qualquer tipo de plataforma de execução.
A partir das pesquisas realizadas nas bases anteriormente mencionadas foram
incluídos 16 trabalhos nesta categoria.
Os trabalhos que se encontram classificados nesta categoria devem ter o seu foco
voltado para a construção do Modelo Independente de Plataforma. Por “construção” do
PIM, entende-se que o trabalho deve relatar a linguagem utilizada durante a criação do
modelo, explicitar se criou ou fez uso de alguma técnica de modelagem, e qual o
objetivo pretende atingir com a criação do PIM.
4.3.3.2 Trabalhos e Considerações
Solms e Loubser afirmam que ainda há carência na definição do que precisa ser
incluído no Modelo Independente de Plataforma. Em seu trabalho (SOLMS;
LOUBSER, 2009), Solms e Louser realizam a formulação de alguns requisitos para o
PIM e apresentam o URDAD (SOLMS, 2007), uma análise algorítmica e metodologia
de projeto, que pode ser usado por especialistas do domínio, tais como analistas de
negócios, para gerar o PIM.
Com o propósito de conter informações suficientes para a implementação do
mapeamento em uma arquitetura posteriormente definida, o URDAD necessita que o
PIM contenha de forma obrigatória os seguintes artefatos:
Contratos de serviços;
Especificações do processo de negócios;
Request construction;
37
Especificação da estrutura de dados.
O trabalho contém exemplo de modelagem com a utilização de UML, contudo
não há detalhes de como deve ser realizado o mapeamento. Este ponto fica endereçado
aos especialistas do domínio ou a alguma ferramenta de transformação MDA.
Os pesquisadores Strong et al em (STRONG et al., 2009) propõem uma maneira
de construir o PIM de tal forma que possa reduzir os problemas de comunicação
existentes entre os modelos durante o processo de desenvolvimento de um sistema de
informação. Esses problemas na comunicação seriam causados por:
Excesso do nível de abstração do PIM;
Proliferação de documentos no nível PSM;
Sintaxe de linguagem complexa, com uma curva de aprendizado grande.
De acordo com Strong et al., um Modelo Independente de Plataforma pode
conter tanta ambiguidade que não é possível afirmar que uma ferramenta de
transformação consiga gerar modelos PSM a partir deste com cem por cento de sucesso.
Faz-se necessário mais especificações, que não devem ser armazenadas num repositório
junto ao PIM, porque este não pode conter informações específicas do sistema.
A solução proposta para este caso é a adoção de marcações no modelo PIM
contendo as informações que este necessita para gerar, num próximo passo, o Modelo
Específico de Plataforma. Essas marcações são chamadas de camadas transparentes e
ficam armazenadas num outro repositório. Por outro lado, diversas marcações podem
ser feitas para a geração futura de modelos de plataformas diferenciadas. Desta forma, o
PIM se mantém inalterado em seu repositório e as camadas transparentes permanecem
em outro.
Em seu trabalho (ALMEIDA, J. P. A. et al., 2004), Almeida et al. utilizam
diferentes pontos de vista (viewpoints) para classificar o nível de uma plataforma
abstrata. É utilizado o RM-ODP (VALLECILLO, 1999), um padrão que utiliza
viewpoints e, para cada um destes, existe um vocabulário e uma gramática. Nesse
trabalho Almeida utiliza o viewpoint da aplicação e da infra-estrutura.
Um trabalho desenvolvido posteriormente por Almeida et al. em (ALMEIDA, J.
P. et al., 2005) mostra que existem diferentes níveis de independência de plataforma.
38
Neste trabalho o foco é a discussão de uma abordagem de modelagem que é suportada
pelos padrões UML 2.0 e MOF 2.0, utilizando os conceitos de plataformas abstratas.
O Modelo Independente de Plataforma também pode ser utilizado no auxílio ao
desenvolvimento de sistemas web, através da reutilização de modelos. Em seu trabalho
(QUERALT; TENIENTE, 2007), Queralt e Teniente identificam grande número de
websites de comércio eletrônico existentes na grande rede. Estes sites possuem, em sua
maioria, estruturas semelhantes, posto serem muitas vezes empresas concorrentes do
mesmo setor comercial. Como exemplo, tomemos o eBay, Amazon, YahooShopping. Ou
num contexto brasileiro, Submarino, Americanas.com, Saraiva, Fnac.
Por conter aspectos estruturais semelhantes, Queralt e Teniente propõem a
construção de um PIM que atenda a esse domínio de negócio. Através deste PIM
genérico fica possível, mediante pequenas adaptações, derivar PIM’s para cada
aplicação em particular. A Figura 11 ilustra o papel do PIM genérico para este domínio
e sua relação com os PIM’s e PSM’s que podem ser derivados a partir deste.
Figura 11 - Um exemplo do domínio e aplicações
(adaptada de QUERALT; TENIENTE, 2007)
Este modelo de PIM genérico construído contribui diretamente com a redução de
custo e tempo do processo de desenvolvimento de novos websites, dentro do domínio
do comércio eletrônico.
39
Falda et al. em (FALDA et al., 2008) descreve uma maneira para realizar a
criação e execução de Modelos Independentes de Plataforma no campo de aplicações de
dados intensivos. O modelo é baseado em UML e deve ser capaz de processar dados de
grande porte usando alto nível de linguagem query.
Para a descrição de queries no modelo UML é utilizado a OCL – Object
Constraint Language, por ser uma linguagem textual independente. A OCL é um
componente padrão recomendado pela OMG na transformação de modelos (OCL,
2010).
Outra construção de PIM, que também faz uso do OCL, é proposta em
(KELSEN et al., 2007). Kelsen et al. desenvolveram uma linguagem para modelagem
chamada EP Language. Esta linguagem é baseada nos dois principais tipos de
elementos da modelagem: Eventos e Propriedades.
Os criadores atestam que se trata de uma linguagem declarativa, com um nível
de abstração maior do que as Action Languages. Esta linguagem é composta de
elementos gráficos, elementos textuais e deve ser aplicada juntamente com expressões
OCL. Apesar disto, a EP Language ainda precisa ser aprimorada para permitir uma
geração automática de código completa.
O trabalho de Delanote e Steegmans em (DELANOTE; STEEGMANS, 2006),
discute a falta de expressividade dos conceitos nos níveis mais altos de abstração do
PIM, forçando desenvolvedores a tomar decisões técnicas muito cedo no processo de
desenvolvimento.
Delanote e Steegmans observam que a reificação, técnica onde se faz a
utilização de objetos para representar certos artefatos, é muitas vezes utilizada para
contornar decisões que não deveriam ser tomadas ainda no nível do PIM. Para contornar
essa prática propõem-se a construção de um novo PIM.
O processo de transformação de um PIM em um PIM no próximo nível de
abstração adiciona mais informações técnicas e é uma maneira de facilitar o
mapeamento para a próxima transformação, onde será gerado um Modelo Específico de
Plataforma.
Para viabilizar esta transformação de um PIM base em outro PIM no próximo
nível de abstração e, com isso, prevenir o uso de reificação, é introduzido o Method
Class, uma extensão da UML que deve ser utilizada em conjunto com a OCL. Apesar
40
de realizar experiências com sucesso, os autores afirmam que a ideia precisa ser
aprimorada e ainda não criaram regras e definições de como eliminar todos os tipos de
reificações.
O trabalho de (VALVERDE et al., 2007) explora a vantagem do PIM, diferente
do PSM, não ser restrito à descrição de uma única plataforma, focando na interação
entre usuário e sistema.
Frequentemente uma interface precisa ser gerada para muitas plataformas
(Desktop, Web, celulares), fazendo reuso do mesmo modelo. Isto se torna possível se,
durante a construção do PIM, este contiver a descrição da interação com o usuário sem
levar em conta a plataforma para o qual é designado. Este é um processo para gerar
multiplataformas através de um mesmo modelo.
A Figura 12 retrata os detalhes da construção do PIM utilizando uma abordagem
chamada Abstract Interaction Model, ou Modelo de Interação Abstrata, que faz uso de
modelos de usuário e de interface abstrata. O método de transformação utilizado para a
posterior geração do PSM é o OO-Method.
Figura 12 - Modelo de Interação Abstrata em um processo de desenvolvimento
MDA
(adaptada de VALVERDE et al., 2007)
41
Em um ambiente de desenvolvimento orientado por modelagem, o modelo bem
construído é a chave para que a transformação possa ser bem sucedida. O trabalho em
(PASTOR et al., 2010) indica que a avaliação da qualidade do modelo realizada através
de técnicas de detecção de erro não se mostra muito satisfatória. Pastor et al. propõem o
Functional Size Measurement (FSM), um procedimento para detectar defeitos na
construção dos modelos independentes de plataforma, num ambiente de
desenvolvimento orientado a modelos. Os resultados obtidos indicam que o FSM é
eficiente na busca dos defeitos, classificando pelo tipo de defeito, como também se
mostra útil para encontrar defeitos diferentes dos que poderiam ser encontrados por uma
equipe de inspeção.
O trabalho de (BETTIN; BOAS, 2003) prevê a construção de um de uma
ferramenta open source denominada GMT – Generative Model Transformer. O objetivo
com o GMT é dar apoio, permitindo uma criação personalizável do Modelo
Independente de Plataforma. De acordo com Bettin e Boas, o GMT consiste de quatro
principais componentes:
Componente de mapeamento, que combina dois modelos XMI em um modelo
XMI;
Componente de transformação que utiliza XMI na entrada e saída;
Componente de geração de texto, utilizando XMI na entrada e texto (código) na
saída;
Componente de workflow, responsável por garantir o funcionamento dos três
componentes acima, junto com alguma ferramenta de transformação MDA, e
algum ambiente de desenvolvimento.
Outras referências sobre o Modelo Independente de Plataforma também pode ser
encontrado em (PASTOR; MOLINA, 2007), (ZHU et al., 2005) e (SILAGHI, 2004).
Após a finalização desta categoria foi possível notar que ainda existem
problemas no processo de construção do Modelo Independente de Plataforma. Um deles
é o fato de muitas vezes o PIM conter decisões de design específicas para uma
plataforma, estes aspectos deveriam ser descritos somente no PSM. A ocorrência desse
fato descaracteriza a independência do PIM.
42
A UML se mantém como a linguagem mais utilizada na construção do PIM,
porém a OCL vêm, com destaque, sendo empregada em conjunto. Os desenvolvedores
provavelmente estão usando esta abordagem para criar meios de construção de modelos
que sejam aptos a carregar detalhes do sistema, que não sejam tão simples de serem
representados apenas com a UML. Esta é uma prática recomendada pela OMG.
Através da observação e análise dos trabalhos futuros foi identificada uma
preocupação com a questão da independência do modelo. Existem diversas técnicas,
abordagens e linguagens sendo desenvolvidas para que o PIM não carregue detalhes
específicos da plataforma. Muitas destas técnicas conseguem realizar somente uma
construção básica ou restrita do modelo e ainda precisam ser aperfeiçoadas. Quanto à
especificação OMG, ela é insatisfatória neste ponto, limitando-se a definir o modelo,
mas sem conter regras de como contornar este problema.
Existe também uma iniciativa para estender o trabalho iniciado em (QUERALT;
TENIENTE, 2007). Neste trabalho foi construído um PIM genérico para o domínio de
comércio eletrônico. A ideia é a construção de um grande repositório disponível para
pesquisa contendo modelos de domínio de diversas áreas. Adicionalmente, se faz
necessária a criação de um manual contendo regras e especificações para a criação
destes modelos de domínio.
4.3.4 Mapeamento de Modelo (Model Mapping)
4.3.4.1 Escopo
O mapeamento de modelo, no contexto específico da MDA, é uma
especificação, que inclui regras e outras informações, constituindo uma etapa do
processo de desenvolvimento MDA que dá suporte à transformação do PIM para a
produção do PSM.
O mapeamento de modelo é a etapa onde são feitas as marcações e criados os
metamodelos. O mapeamento pode ser baseado nos tipos de elementos do modelo,
contendo regras que especificam como diferentes tipos de elemento PIM serão
posteriormente transformados em elementos do PSM. O mapeamento também pode
especificar como elementos de uma instância específica de modelo serão transformados
usando marcações.
43
Através de pesquisas realizadas nas bases anteriormente mencionadas e
indicações de especialistas na área, foram incluídos 13 trabalhos nesta categoria. Estes
trabalhos tratam de temas relacionados à manipulação de modelos e metamodelos.
Também estão classificados nesta seção os trabalhos que possuem em seu tema
principal a descrição de técnicas de mapeamento de um modelo PIM, preparando-o para
uma transformação na etapa seguinte do processo.
4.3.4.2 Trabalhos e Considerações
O processo de representação e transformação de modelo, num contexto geral,
envolve abordagens e diagramas da engenharia de requisitos. Entretanto, não está muito
claro de que forma os conceitos da engenharia de requisitos estão relacionados com os
modelos MDA. Siqueira e Silva, em seu trabalho (SIQUEIRA; SILVA, P. S. M., 2011)
almejam o aprimoramento da compreensão da MDA e a definição de quais artefatos são
esperados da perspectiva da engenharia de requisitos. Para alcançar tal objetivo é
apresentado o modelo WRSPM.
O modelo WRSPM é um modelo de referência para requisitos e especificações,
baseando-se em ideias e conceitos (GUNTER, C. A. et al., 2000). A Tabela 2 apresenta
um cruzamento do mapeamento de artefatos de desenvolvimento de software usando o
modelo WRSPM e os modelos MDA.
Tabela 2 - Mapeamento de modelos MDA e artefatos WRSPM
(adaptada de SIQUEIRA; SILVA, P. S. M., 2011)
MDA
CIM PIM PSM
WR
SP
M
Conhecimento de domínio X
Requisito X
Especificação X X
Programa X X
Plataforma X X
As relações entre os modelos CIM, PIM e PSM não são um para um. O
mapeamento proposto por Siqueira e Silva em seu trabalho contribui para o
44
entendimento dos modelos MDA através de uma perspectiva da engenharia de
requisitos.
O mapeamento das relações entre diferentes modelos é o princípio e a base para
a uma futura transformação. Em (HUANG et al., 2007) é proposta uma abordagem de
mapeamento de modelo baseado na análise de características sintáticas e semânticas das
linguagens de modelagem.
A abordagem descrita no trabalho por Huang et al. pode ser usada para construir
relações de mapeamento do modelo fonte para o modelo alvo, através de um modelo
alvo semântico e abstrato. Esta abordagem pode servir de guia teórico para apoiar a
transformação de modelo, mas também é, principalmente, uma medida para realizar
validação das regras de mapeamento entre os modelos em diferentes níveis de
abstração.
Os autores defendem o uso do padrão de projeto Model-View-Controller (MVC).
Por ser o JavaServer Faces (JSF) um framework MVC para o desenvolvimento de
aplicações Web (JSF, 2011), esta tecnologia é utilizada num estudo de caso.
45
Figura 13 - O framework do modelo alvo baseado em JSF
(adaptada de HUANG et al., 2007)
A Figura 13 representa um exemplo de aplicação utilizando JSF. É possível
notar que a camada de visão, responsável pela interface com o usuário, se encontra
claramente separada da lógica e dos dados da aplicação, situados na camada de modelo.
Esta mesma técnica de mapeamento de modelo baseado na análise de
características sintáticas e semânticas é utilizada novamente por um dos autores em
outros dois trabalhos, (HOU, 2010a) e em (HOU, 2010b), onde a abordagem é
exemplificada através de outros estudos de caso.
A metamodelagem é um meio essencial para sistematizar, formalizar,
padronizar, integrar, analisar e comparar modelos, técnicas, métodos e ferramentas. A
46
importância da metamodelagem cresce de acordo com o surgimento de novas
arquiteturas, técnicas e linguagens baseadas em UML e MDA.
Em (LEPPANEN, 2006) é apresentado um framework para integrar e comparar
concepções divergentes de metamodelagens em banco de dados, engenharia de software
e desenvolvimento de sistemas de informação.
Figura 14 - Níveis de modelos e linguagens
(adaptada de LEPPANEN, 2006)
Na Figura 14 é possível observar que conforme aumenta o nível de abstração,
mais suporte é necessário para representar a realidade. No nível 1 o modelo é
representado através de uma denotação do modelo. No nível 2 existe a linguagem,
47
representada através da denotação da linguagem. O ponto chave na relação dos níveis
de modelos e linguagens um com o outro é a sintaxe abstrata: uma denotação de modelo
é baseada em uma certa linguagem, que por sua vez é fundamentada em semântica e
sintaxe concreta.
Com o framework proposto Lappanem afirma que é possível realizar
comparações entre metamodelagens dos ramos da engenharia de software, banco de
dados e desenvolvimento de sistemas de informação. Os resultados dessas comparações
podem apoiar o desenvolvedor do projeto na identificação de inconsistências dos
modelos.
Os conceitos de metamodelos e transformações de modelo baseada em
metamodelos são ramos críticos na área MDA. O trabalho (FAVRE; MARTINEZ,
2006) analisa como definir a reusabilidade de componentes para padrões de projetos de
uma maneira que se encaixa com a metodologia MDA.
A reusabilidade pode trazer uma série de vantagens no processo de mapeamento,
entretanto não há uma definição formal de como definir o reuso de um componente.
Favre e Martinez propõem um framework arquitetural para definir famílias dos
componentes de padrões de projetos, contendo de maneira organizada metamodelos e
transformações de modelo. A este framework é dado o nome de “megamodelo”.
A notação megamodelo já havia sido utilizada anteriormente, por exemplo em
(BÉZIVIN, J. et al., 2004), onde se define por megamodelo qualquer modelo no qual,
pelo menos um de seus elementos representam e/ou se referem a modelos ou
metamodelos.
A contribuição do trabalho de Favre e Martinez se caracteriza por criar meios
para que os desenvolvedores não precisem analisar componentes um a um para definir a
sua reusabilidade, pois com o uso do MDA essas especificações são possíveis através
dos modelos e metamodelos. Contudo, a criação e o entendimento de metamodelos não
é uma tarefa trivial, acarretando a necessidade de desenvolvedores que possuam
conhecimento específico sobre o assunto.
Em seu trabalho, Judson afirma que transformações bem definidas devem
suportar uma rigorosa evolução do modelo, refinamento e geração de código. Em
(JUDSON et al., 2003), é realizado uma pesquisa focada no desenvolvimento de uma
técnica que suporte uma modelagem rigorosa. As transformações modeladas podem ser
48
usadas como base para o desenvolvimento de ferramentas que suportam a aplicação
rigorosa e sistemática de transformações reutilizáveis.
A técnica descrita no decorrer do trabalho consiste em descrever famílias de
transformações, a nível de metamodelo. Esses metamodelos, ao longo da aplicação da
técnica, são utilizados para a refatoração dos modelos, agindo como pontos contra os
quais as transformações de níveis de modelo podem ser verificadas para conformidade.
Como referências adicionais também abordam o tema desta seção os trabalhos
(NEKTARIOS GEORGALAS et al., 2004), (PASTOR; MOLINA, 2007), (SINGH,
YASHWANT; SOOD, MANU, 2009) e (ZHANG, JINGJUN; CHEN, YUEJUAN,
2009).
A partir da leitura dos trabalhos pesquisados foram observadas diferentes
técnicas de mapeamento, dentre as quais, vale destacar o mapeamento baseado no
cálculo de características semânticas. Ainda é necessário formalizar as definições do
modelo de arquitetura de componentes e reforçar as capacidades de expressividade
semântica. Por outro lado, esta técnica é interessante por servir de medida para a
validação de regras de mapeamento entre modelos de diferentes níveis de abstração.
Ainda sobre o mapeamento de modelos é importante ressaltar que existem
estudos visando uma formalização das regras de mapeamento. Não se sabe se é viável a
criação de uma especificação geral ou padrão, pois este é, na verdade, um estudo
contínuo, visto que novas ferramentas de transformação e novas técnicas de
mapeamento são constantemente criadas e a interação entre os modelos pode ser
realizada de formas variadas.
A metamodelagem ainda tem concepções bastante divergentes de suas
abordagens em seus domínios de aplicação. Existem pesquisas direcionadas para a
construção de algum método ou framework que possibilite o reconhecimento explícito
de características contextuais de cada camada de domínio.
O megamodelo se apresenta como uma maneira eficiente para a organização de
modelos e metamodelos na engenharia de software. Existem aplicações que utilizam
megamodelos, contudo, são geralmente exemplos locais e não parece haver um esforço
significativo na abstração da visão global.
49
4.3.5 Transformação PIM PSM
4.3.5.1 Escopo
A seção anterior tratou de regras de mapeamento e marcações que são realizadas
no PIM. A partir dessas marcações, o PIM se encontra preparado para uma
transformação no sentido de gerar um Modelo Específico de Plataforma (PSM). Este
modelo deve conter as informações previamente descritas no PIM, porém com a adição
de particularidades de uma determinada plataforma.
A transformação é a etapa imediatamente seguinte ao processo de mapeamento
de modelo e nesta categoria se encontram relacionados 21 trabalhos.
O escopo desta categoria corresponde aos às transformações realizadas em um
modelo PIM com a finalidade de se obter a geração de um PSM. Nesta categoria estão
incluídos os trabalhos que descrevem como ocorreu a obtenção do PSM a partir do PIM,
contendo ou não detalhes de quais ferramentas foram utilizadas neste processo. Os
trabalhos que descrevem a criação ou o uso de ferramentas de transformação também se
enquadram nesta categoria.
Algumas abordagens MDA fogem um pouco do padrão estabelecido pelo OMG.
São os casos de transformações de PIM que geram simultaneamente o PSM e o código
fonte. Os trabalhos que apresentam esta abordagem também estão incluídos nesta
categoria.
4.3.5.2 Trabalhos e Considerações
Os processos de transformação MDA, na direção PIM para PSM, comumente se
estendem até a geração de um esqueleto de código. Em (LEAL et al., 2006) é proposto
uma maneira para realizar a geração de parte do código executável.
Leal et al. apresentam a linguagem Natural MDA. Após esta linguagem é
definida uma gramática, que deve ser utilizada durante a transformação de modelo,
através do uso de Actions Specifications. Para a descrição dessa gramática foi escolhida
a ferramenta open source ANTLR - Another Tool for Language Recognition (PARR,
2009). A Figura 15 demonstra, em A o processo comum de geração de PSM e, em B, o
processo de geração proposto.
50
Figura 15 - Ferramenta MDA com o processador de linguagem Natural MDA
(adaptada de LEAL et al., 2006)
A geração de parte do código executável também foi realizada por Lano em
(LANO, 2008). O desenvolvedor especifica um PIM através de notações, como casos de
uso, diagramas de classe e máquinas de estado, com restrições, como classes
invariantes. Através dessas descrições é possível derivar PSM’s e implementações. Essa
abordagem foi intitulada Constraint-Driven Development (CDD).
Para o nível da especificação do PIM é utilizado UML-RSDS (Reactive System
Design Support), um subconjunto do UML. Foi criado um conjunto de ferramentas para
suportar a utilização da abordagem CDD com UML-RSDS. Os passos do CDD são:
51
Construção de casos de uso, diagramas de classe e máquinas de estado PIM
usando a ferramenta UML-RSDS;
Análise da consistência e completude dos modelos PIM;
Transcrição dos modelos para notação SMV para análise semântica
(utilizando ferramentas para esta notação);
Transformação de modelos para aprimorar a qualidade e refinar para um
PSM;
Geração de código Java a partir do modelo Java PSM.
Apesar de existirem alguns padrões bem estabelecidos de modelos de
plataforma, não há atualmente uma especificação bem definida entres estes modelos. O
trabalho de (CZARNECKI; HELSEN, 2003) se propõe a estabelecer uma possível
taxonomia para a classificação de algumas abordagens de transformação de modelo. A
taxonomia adotada é baseada em características do modelo que se diferenciam pelas
escolhas do design durante a modelagem. Essas escolhas são feitas de acordo com a
variação das áreas de alto nível do processo de modelagem. A Figura 16 descreve estas
áreas:
52
Figura 16 - Representação das áreas de alto nível de uma Transformação de
Modelo
(adaptada de CZARNECKI; HELSEN, 2003)
De acordo com Czarnecki e Helsen as atuais transformações de modelos no
sentido PIM para PSM podem ser classificadas em uma ou mais destas áreas propostas.
Os testes de software representam um grande impacto no custo do
desenvolvimento. Muitas vezes, os testes são criados de maneira aleatória e sem o apoio
de alguma metodologia. Como um sistema de informação pode estar em constante
mudança e evolução, também se faz comum a existência de testes defasados e sem
documentação satisfatória. Em (PINEL et al., 2011) é apresentado um método que
aplica o MDA na geração de fluxo de casos de testes.
A metodologia dos testes é baseada na modelagem, ao nível do PIM, de
diagramas de atividades UML, seguidos por uma transformação MDA. A ferramenta de
53
transformação escolhida foi o MDArte (MDARTE, 2011), uma ferramenta livre
disponível no Portal do Software Público Brasileiro (SOFTWAREPUBLICO, 2011).
No MDArte as transformações para o Modelo Específico de Plataforma são
orientadas por cartucho. O trabalho realizado descreve como foi executada a
implementação do cartucho responsável pela geração do código de teste, além de um
exemplo com detalhes de como construir um caso de teste. Neste exemplo é testado
uma pequena funcionalidade, entretanto o teste é realizado de maneira completa,
atuando tanto na camada de negócios, quanto na camada de apresentação.
O trabalho (FEILER et al., 2007) discute a integração de Executable UML
(XUML, 2008) com Architecture Analysis and Design Language (AADL) (SAE, 2009)
no desenvolvimento de sistemas MDA.
O Executable UML, também conhecido por xUML, é uma extensão do UML
que acrescenta precisão semântica aos modelos, permitindo assim uma descrição
completa dos PIM's, em ordem de proporcionar a geração de código a partir destes. A
utilização desta abordagem habitualmente resulta na obtenção do código sem a geração
do PSM. No entanto o PSM é necessário para atingir diferentes propriedades não-
funcionais do sistema.
O trabalho de Feiler et al. explica detalhadamente como efetuar a criação de um
modelo AADL a partir de um PIM modelado em xUML. O objetivo do trabalho é
continuar permitindo a criação de um PIM executável, com o uso de xUML, e adicionar
a possibilidade de criação do seu modelo correspondente PSM analisável. Isso se torna
possível pela característica da AADL, que permite a criação e exploração de PSM’s,
com suas propriedades não funcionais.
Segundo (PARDILLO et al., 2008), o processo de desenvolvimento de data
warehouses se inicia na especificação das propriedades estáticas e dinâmicas de
aplicações on-line analytical processing (OLAP) por meio de uma abstração intuitiva e
semanticamente rica, denominada modelo conceitual. Existe uma lacuna semântica
entre os níveis lógico e conceitual que reduzem a viabilidade do seu mapeamento e,
para construir uma ponte entre esses níveis, Pardillo et al. propõem a especificação de
uma álgebra OLAP no nível conceitual, totalmente independente de plataforma. Através
de transformação MDA essa álgebra tem condições de gerar um sistema OLAP.
54
Figura 17 - MDA para queries independentes de plataformas
(adaptada de PARDILLO et al., 2008)
A Figura 17 apresentada acima ilustra a arquitetura das transformações
envolvidas no processo. Após a seleção de uma plataforma lógica e o modelo de
mapeamento na direção do nível conceitual para o nível lógico, cada operação OCL
definida na álgebra OLAP é transformada em sua contraparte lógica na plataforma
escolhida, por meio da MDA.
A parte conceitual é representada pelo PIM e a parte lógica pelo PSM. A
transformação no sentido PIM para PSM e, posteriormente para código é apoiada por
padrões de linguagem de transformação, tais como Query/View/Transformation (QVT)
e MOF.
Uma das vantagens da MDA é a portabilidade do sistema para diferentes
plataformas. Esse é o foco de (CHEHADE et al., 2009), que busca automatizar a
transformação de PIM para PSM de forma a produzir mais de um Modelo Específico de
Plataforma.
O trabalho utiliza o MARTE (MARTE, 2011), um profile UML, para a
construção do PIM. Para que a transformação MDA possa ser executada de forma a
55
gerar dois modelos PSM’s distintos, os autores fazem uso do Software Resource
Modeling (SRM), que permite a descrição de serviços de sistemas operacionais e
plataformas de execução.
Chehade et al. demonstram como utilizar o SRM através de uma modelagem
realizada num nível entre o PIM e o PSM, dando suporte à transformação. Os autores
apresentam um exemplo onde a transformação de um mesmo PIM produz PSM’s na
linguagem Java e C++.
Em (MIRALVAND et al., 2009) é feito uma proposta formal e automática para
o refinamento de modelo no nível PIM até o nível PSM. Essa passagem de nível é
realizada através de um sistema de transformação de grafos.
O trabalho em questão descreve os passos para a geração de serviços específicos
de plataforma a partir de um modelo independente. O processo é realizado considerando
os níveis de abstração e regras do sistema de transformação de grafos.
Em comparação com a maioria das abordagens da literatura, esta proposta
considera as partes estruturais e comportamentais do modelo. Outras propostas, de
maneira geral, limitam-se em considerar apenas as partes estruturais.
O trabalho de (KURTEV et al., 2006) tem como principal objetivo demonstrar a
importante evolução das práticas da engenharia. Para sair do campo da teoria e
demonstrar de maneira prática, o trabalho apresenta uma série de problemas típicos que
podem ser resolvidos através de técnicas baseadas em DSL. O trabalho ilustra o poder
dos frameworks baseados em modelos, permitindo o uso e construção de uma grande
variedade de DSL’s que podem resolver problemas complexos de forma eficiente.
Ao longo do trabalho são descritos problemas comuns que poderiam ser
resolvidos através das técnicas propostas. Exemplos desses problemas são a
reusabilidade de ferramenta; combinação de produto e processo; transformações
flexíveis entre linguagens; gerenciamento de metadado. Por fim, Kurtev apresenta, uma
a uma, a solução para cada um dos problemas propostos, utilizando o ATLAS Model
Management Architecture, abreviado pela sigla AMMA.
O termo computação pervasiva, ou computação ubíqua é comumente utilizado
para descrever a presença da computação no cotidiano das pessoas, nas atividades do
56
dia-a-dia. O trabalho de (HEMME-UNGER et al., 2003) utiliza a MDA para o
desenvolvimento de computação ubíqua.
O interesse na MDA se faz presente na facilidade de geração de código através
de modelo, que permite direcionar o foco na lógica do negócio, sem precisar estar
atento para as complexidades da implementação. Contudo, Hemme-Unger et al.
reconhecem que a MDA possui algumas falhas na especificação e sua utilização fica
restrita ao desenvolvimento de componentes da aplicação.
Esses componentes são modelados representando o modelo PIM, e são passíveis
de transformação para a geração do PSM. O trabalho apresenta, ainda, as dificuldades
encontradas pelos estudantes por não encontrar uma ferramenta de modelagem genérica
e a descrição do workflow da aplicação que foi criada.
Outras discussões sobre a transformação de PIM para PSM podem ser
encontradas em (JOUAULT, FRÉDÉRIC et al., 2008), (JÚNIOR, 2009), (LIU, YANG;
MA, 2008), (PANACH, J. I. et al., 2008), (PASTOR; MOLINA, 2007), (VALVERDE
et al., 2007), (SINGH, YASHWANT; SOOD, MANU, 2009), (BETTIN; BOAS, 2003),
(AGRAWAL, 2003) e (AQUINO; VANDERDONCKT, 2010).
A partir da análise dos trabalhos enquadrados nesta categoria foi possível notar
que, dentre todas as linhas de pesquisa da MDA, esta parece ser a mais bem
desenvolvida.
Dentre os trabalhos pesquisados foi encontrado um grande número de propostas
e abordagens para a transformação de modelo. É provável que este número seja
justificado pelo fato de esta categoria estar voltada para os trabalhos que resultam em
um PSM, sendo este modelo a abstração mais próxima do produto final. Existem
trabalhos que descrevem métodos de geração de código diretamente do PIM, com
geração conjunta de PSM; técnicas de transformação apoiadas em grafos; uso de
ferramentas de transformação em conjunto com notações; uso de linguagem natural; e
outros.
Com relação aos objetivos da transformação, o resultado final nem sempre é
apenas um Modelo Específico da Plataforma. Algumas abordagens procuram a
produção de mais de um modelo, visando atender a plataformas distintas.
As técnicas de transformações PIM para PSM observadas cumprem o
estabelecido pela especificação OMG. Além disto, muitos trabalhos vão além do que
57
consta na especificação e conseguem atingir outras finalidades através da transformação
a partir do PIM.
O fato do processo de transformação PIM para PSM estar evoluído, bem
estabelecido, não significa ser esta uma área de pouca atuação. De forma oposta, esta
linha de pesquisa conta com uma vasta quantidade de trabalhos e estudos em
andamento. Estes fatos tornam esta categoria promissora e a tendência é que ela
apresente um desenvolvimento maior do que as outras.
4.4 Análise Geral
Ao longo de cada categoria apresentada na seção anterior é feito uma análise
individual, com a descrição do seu estado atual e suas perspectivas futuras.
Nesta parte do trabalho o objetivo é analisar a pesquisa realizada sob o ponto de
vista da MDA como um todo.
Como primícia tomemos a perspectiva da pesquisa. Durante as buscas por
artigos, trabalhos e outros, notou-se uma facilidade maior para encontrar trabalhos com
tema relacionado a transformação de modelo PIM para PSM. A categoria PIM e
mapeamento de modelo também apresentaram uma grande quantidade de trabalhos, mas
ainda não tanto quanto a área de transformação mencionada. De maneira oposta, as
categorias CIM e transformação CIM para PIM foram as que detinham um menor
número de trabalhos.
Enquanto que para o primeiro grupo (transformação PIM para PSM, PIM e
mapeamento de modelo) foi necessário uma “peneira” para selecionar os trabalhos que
seriam classificados, no segundo grupo (CIM e transformação CIM para PIM) o desafio
foi encontrar trabalhos que pudessem ser classificados nestas categorias.
Esta análise sobre facilidade de encontrar trabalhos é subjetiva e não há como
quantificá-la, porém a Figura 18 procura ilustrar esse cenário.
Figura 18 - Análise subjetiva da distribuição de trabalhos
58
Dentre os trabalhos que abordam a transformação CIM para PIM, a maioria são
propostas e estudos teóricos. Quando há uma aplicação prática esta foge dos conceitos
estabelecidos na especificação OMG. Por ser uma área ainda em aberto pode-se deduzir
que os pesquisadores que possuem estudos em andamento nessa área tendem a possuir
mais experiência em MDA.
A categoria com maior foco é a transformação PIM para PSM. Devido ser a área
que resulta em um produto final, é compreensível que esta seja a que contém o maior
número de trabalhos. Nesta área também se destacam diversas abordagens que
procuram gerar modelos para mais de uma plataforma, confirmando a portabilidade
preconizada pela metodologia MDA.
59
5.Análise dos Resultados
Este capítulo apresenta os resultados da entrevista realizada através da técnica de
prospecção que faz uso da opinião de especialistas, modalidade survey. Este tipo de
prospecção se caracteriza pela aplicação de um questionário submetido a um grupo de
indivíduos com conhecimento em MDA.
Nesse questionário foram coletados alguns dados necessários à caracterização da
amostra, compreendendo a formação acadêmica, qualificação profissional,
conhecimento e experiência com MDA, sondagem sobre a geração de código,
aperfeiçoamento, aspirações com respeito à metodologia, e um espaço para respostas
abertas, visando captar a opinião de cada um. A seção 5.2 descreve os objetivos do
questionário e o que se espera identificar através de cada uma de suas perguntas. No
Anexo I deste trabalho se encontra o modelo do formulário submetido.
As respostas do questionário foram analisadas de maneira global e de forma
condicionada pela atividade principal do entrevistado, permitindo assim, ser analisado
se indivíduos de diferentes ramos de atuação possuem visões distintas a respeito da
MDA.
5.1 Pesquisa relacionada
Posteriormente ao envio do questionário do presente trabalho, foi publicado um
estudo realizado sobre o uso da Model-Driven Engineering (MDE) na prática. O estudo,
publicado em maio de 2011, é focado na aplicação da MDE na indústria e o tempo
necessário para sua conclusão foi de aproximadamente um ano. Sua pesquisa foi
composta por questionário, entrevista e observação da prática em empresas.
Em (HUTCHINSON et al., 2011a) o estudo aborda o ponto de vista da
experiência com a MDE em três empresas: companhia de impressora, automóveis e
telecomunicações. Em (HUTCHINSON et al., 2011b) a análise é feita sobre a indústria
de maneira geral.
Apesar da pesquisa de Hutchinson et al. ser aplicada sobre um ramo específico,
a indústria, é válido realizar uma comparação de resultados e observar se sua pesquisa e
a deste trabalho convergem para um mesmo resultado. Esta comparação é efetuada no
decorrer do capítulo.
60
5.2 Objetivos do questionário
O questionário criado tem como finalidade adquirir informações acerca dos
entrevistados sobre seus conhecimentos e, principalmente, opiniões a respeito da MDA.
Através das respostas o questionário procura atingir dois objetivos distintos:
geral e específico. O objetivo geral do questionário é avaliar a aceitação da MDA como
metodologia de desenvolvimento e identificar as áreas que se encontram em maior
evidência, independente dos locais para onde o questionário foi submetido e que grupos
o responderam, relacionando este resultado com a pesquisa bibliográfica. A
sumarização de todas as respostas se encontra no Anexo II deste trabalho e as
conclusões são apresentadas no capítulo 6.
O objetivo específico do questionário é a caracterização das opiniões acerca da
MDA, identificando as diferenças de acordo com o ramo de atividade. Estas diferenças
de opiniões são apontadas ao longo do capítulo 5.
O questionário é composto, ao todo, por seis perguntas. A primeira e a segunda
pergunta são, respectivamente, “Qual é seu grau de formação?” e “Como você qualifica
sua atividade principal?”. Com estas duas perguntas procurou-se caracterizar a amostra
e possibilitar uma análise agrupada por ocupação e, com isto, identificar diferenças de
opinião entre membros de ocupações distintas.
A terceira pergunta, “Qual é sua experiência com MDA?” tem como objetivo
identificar qual é a relação do entrevistado com a MDA. Uma das alternativas de
resposta a essa pergunta, “Não sei o que MDA significa”, indica que o entrevistado não
sabe sequer o significado da sigla MDA, logo, as suas demais respostas da pesquisa não
são consideradas.
As perguntas quatro, cinco e seis são diretas sobre a opinião do entrevistado
acerca da MDA. A quarta pergunta, “O que você acha sobre a geração de código de
sistemas de informação a partir de modelos?” possui duas alternativas que são
consideradas positivas e duas consideradas negativas, no que diz respeito à adoção da
MDA para o desenvolvimento de sistemas. Dentre as duas alternativas consideradas
positivas uma delas afirma que a geração de códigos através de modelos tem capacidade
para, futuramente, conceber sistemas de informação inteiros, a outra alternativa apenas
parcialmente.
61
A quinta pergunta, “Baseado em sua experiência, que áreas da MDA precisam
de maior aperfeiçoamento/pesquisa?”, possui uma lista de alternativas com áreas de
pesquisa, onde mais de uma pode ser escolhida. O importante é identificar quais são as
áreas que podem receber mais pesquisa, na opinião do entrevistado, e relacionar as
diferentes opiniões de acordo com sua atividade principal.
Por fim, a última pergunta procura saber a opinião final através do
questionamento “Você acha que a metodologia MDA se tornará popular no
desenvolvimento de software?”, onde as únicas respostas possíveis são “Sim” ou “Não”,
aliadas a justificativa discursiva de sua escolha.
5.3 Pesquisa no contexto internacional
Para atingir um grupo que possua conhecimento em MDA e, ao mesmo tempo,
obter dados de diferentes realidades de atuação, o questionário foi postado no DBWorld
(DBWORLD, 2011) e enviado para lista da International Conference on Computer
Science and Applications (ICCSA, 2011) em 14/04/2011.
Esta pesquisa obteve um total de 34 respostas. Nas próximas subseções esses
dados são analisados de maneira geral e posteriormente condicionados pela atividade do
entrevistado.
5.3.1 Análise geral
Em relação ao nível de formação, apresentado no Gráfico 1 a maioria possui
Doutorado Completo (38%), sendo seguido por Doutorado Incompleto (23%) e
Mestrado Completo (21%), ficando distribuído igualmente entre Mestrado Incompleto,
Nível Superior Completo e Incompleto, com 6% em cada.
62
Gráfico 1 – Nível de formação, pela amostra internacional
A qualificação profissional é de suma importância, pois permite a divisão desta
pesquisa em três subgrupos: Pesquisadores, Profissionais de TI e Estudantes. Como
pode ser observado no Gráfico 2, destaca-se que mais da metade (59%) dos
entrevistados qualificam sua atividade principal como Pesquisadores.
Gráfico 2 - Atividade principal, pela amostra internacional
Quanto ao grau de experiência, o Gráfico 3 indica que 17 pessoas (50%)
trabalham ou já trabalharam com MDA, 11 (32%) já publicaram algum artigo
relacionado ao tema, 4 (12%) tanto trabalharam, quanto publicaram artigos nesta área.
2
2
2
7
8
13
Nível Superior Incompleto
Nível Superior Completo
Mestrado Incompleto
Mestrado Completo
Doutorado Incompleto
Doutorado Completo
0 2 4 6 8 10 12 14
12%
59%
29%
Estudante (4)
Pesquisador (20)
Profissional de TI (10)
63
Os que nunca trabalharam na área, mas conhecem a MDA aparecem com 24%, e
somente 2 dos entrevistados desconhecem a metodologia.
Gráfico 3 - Experiência com MDA, pela amostra internacional
A partir deste ponto do questionário, as perguntas que se seguem dizem respeito
aos entrevistados que afirmam conhecer a metodologia MDA. Desta maneira, as
respostas dos 2 entrevistados que afirmam desconhecer a área não são consideradas,
reduzindo a amostra a um universo de 32 entrevistados.
A pergunta seguinte se destina a coleta de opinião a respeito da geração de
código a partir de modelos. As respostas que afirmam ser este o caminho correto e ser
uma metodologia viável são consideradas respostas positivas. As respostas que afirmam
não ser um apreciador ou não acreditar na metodologia são consideradas respostas
negativas. O resultado, ilustrado no Gráfico 4, determina um número de respostas
positivas 7 vezes maior que negativas.
2
8
13
7
4
0
2
4
6
8
10
12
14
Não sei o que MDA significa
Sei o que significa, mas
nunca trabalhei com isso
Já trabalhei com isso
Já publiquei artigos
relacionados a MDA
Já trabalhei e publiquei
artigos na área
64
Gráfico 4 - Opinião sobre geração de código, pela amostra internacional
O Gráfico 5 corresponde à pergunta que pretende identificar quais áreas, na
opinião dos entrevistados, necessitam de mais aperfeiçoamento e pesquisas. Estão
dispostas à escolha áreas que constam na especificação (CIM, PIM, PSM, mapeamento
de modelo, transformação de modelo) e áreas de pesquisa fora da especificação
(engenharia reversa, geração automática de documento, métricas, reuso de
mapeamento). Os entrevistados podem selecionar mais de uma área.
A área de transformação de modelo é a mais apontada, tendo sido votada por
62% das pessoas. Reuso de mapeamento, métricas e geração automática de documento,
são os itens menos mencionados (aproximadamente 18%), talvez por estarem fora da
especificação.
10
18
3 1 0
2
4
6
8
10
12
14
16
18
20
É o caminho correto, um dia iremos
construir sistemas de informação através de apenas modelos
Viável até certo ponto do código do
sistema de informação, mas não
100% do mesmo
Não sou um apreciador desta
prática
Não acredito nisto
65
Gráfico 5 - Áreas a aperfeiçoar, pela amostra internacional
Por fim, quanto ao último questionamento: “Você acha que a metodologia MDA
se tornará popular no desenvolvimento de software?”, observa-se que a maioria dos
entrevistados (28 pessoas) acreditam que sim, conforme ilustrado no Gráfico 6.
Gráfico 6 – Opinião sobre a popularização da MDA, pela amostra internacional
Após a última pergunta há um espaço livre para que o entrevistado possa deixar
sua opinião, relatando o porquê de acreditar ou não na MDA.
Abaixo seguem algumas respostas traduzidas para a língua portuguesa.
9
13
9
12
20
10
6
6
6
0 5 10 15 20 25
CIM
PIM
PSM
Mapeamento de Modelo
Transformaçao de Modelo
Engenharia Reversa
Geração Automática de Documento
Métricas
Reuso de Mapeamento
Sim 87%
Não 13%
66
Responderam SIM
“Um software moderno, avançado e de qualidade deve ser baseado na
noção „o modelo é o código‟ no lugar de „o código é o modelo‟.”
“Reduz o esforço no desenvolvimento.”
“Para o desenvolvimento de tarefas repetitivas o uso das técnicas MDA
constituem um benefício real.”
“MDA leva a grandes melhorias na qualidade do software... E assim
permite concentrar os esforços nas necessidades do negócio.”
Responderam NÃO
“MDA é útil em sistemas simples. Em sistemas complexos, com muitas
regras específicas, essa abordagem não é muito útil.”
“Acredito ser bom para aplicações específicas, mas as ferramentas
precisam ser aperfeiçoadas.”
5.3.2 Análise por ramo de atividade
Nesta parte do trabalho as respostas são analisadas condicionadas pela atividade
principal do entrevistado.
A amostra analisada corresponde a 20 pesquisadores, 10 profissionais de TI e 4
estudantes. Dentre os estudantes estão os 2 entrevistados que afirmam desconhecer a
metodologia MDA. Por apresentar uma quantidade muito pequena, os estudantes não
estão relacionados na análise comparativa que é apresentada a seguir.
Quanto ao nível de formação, a partir do Gráfico 7 é visível que os
pesquisadores encontram-se com um nível acadêmico superior em relação aos
Profissionais de TI. Na análise dos dados observa-se que 80% dos Pesquisadores
possuem um grau acima do mestrado (55% com Doutorado Completo e 25%
Incompleto), enquanto entre os Profissionais de TI apenas 30% estão neste nível (20%
com Doutorado Completo e 10% Incompleto). A Maioria dos Profissionais de TI detém
apenas Mestrado Completo (60%).
67
Gráfico 7 - Comparativo da formação: Pesquisador X Profissional de TI
A Tabela 3 apresenta um comparativo quanto a experiência com MDA. Nota-se
que 20% dos Profissionais de TI nunca trabalharam com MDA. Dentre os
Pesquisadores este percentual fica em 25%, indicando uma diferença inexpressível.
Tabela 3 - Experiência com MDA: Pesquisador X Profissional de TI
Pesquisador Profissional de TI
Qual é sua experiência com MDA? qtde % qtde %
Não sei o que MDA significa 0 0% 0 0%
Sei o que significa, mas nunca trabalhei com isso 5 25% 2 20%
Já trabalhei com isso 7 35% 5 50%
Já publiquei artigos relacionados a MDA 6 30% 1 10%
Já trabalhei e publiquei artigos na área 2 10% 2 20%
Soma 20 100% 10 100%
Uma análise mais profunda nas respostas dos Pesquisadores permite observar
que 9 (45%) já trabalharam na área, enquanto que 8 (40%) já publicaram algum artigo.
0
2
4
6
8
10
12
14
Nível Superior Incompleto
Nível Superior Completo
Mestrado Incompleto
Mestrado Completo
Doutorado Incompleto
Doutorado Completo
Pesquisador Profissional de TI
68
Esta mesma análise quando feita entre os Profissionais de TI aponta uma diferença
maior: 7 (70%) já trabalharam na área e 3 (30%) já publicaram algum artigo.
Gráfico 8 - Comparativo experiência com MDA: Pesquisador x Profissional de TI
A diferença percentual mencionada indica que dentre os Pesquisadores
entrevistados, o número de pessoas que trabalham com MDA anda em paralelo ao
número de pessoas que publicam artigos. O mesmo não pode ser dito para os
profissionais de TI. O Gráfico 8 deixa clara essa diferença.
Com relação à pergunta: “O que você acha sobre a geração de código de
sistemas de informação a partir de modelos?” constata-se que todos os Pesquisadores
deram respostas favoráveis (100%), tendo 45% afirmado ser este o caminho correto.
Dentre os Profissionais de TI, 60% demonstraram respostas favoráveis, tendo somente
10% do total afirmado ser este o caminho correto. A Tabela 4 mostra essa configuração.
45% 40%
70%
30%
já trabalhou com MDA já publicou algum artigo relaciona a MDA
Pequisador Profissional de TI
69
Tabela 4 - Geração de código: Pesquisador X Profissional de TI
Pesquisador Profissional de TI
O que você acha sobre a geração de código de
sistemas de informação a partir de modelos? qtde % qtde %
É o caminho correto, um dia iremos construir
sistemas de informação através de apenas modelos 9 45% 1 10%
Viável até certo ponto do código do sistema de
informação, mas não 100% do mesmo 11 55% 5 50%
Não sou um apreciador desta prática 0 0% 3 30%
Não acredito nisto 0 0% 1 10%
Soma 20 100% 10 100%
As respostas quanto as áreas da MDA que precisam de mais aperfeiçoamento
seguem a mesma distribuição para ambos, destacando-se a transformação de modelos.
Esta área foi indicada por 11 (55%) Pesquisadores e 5 (50%) Profissionais de TI.
A última pergunta do questionário procura capturar a opinião dos entrevistados
sobre a possibilidade da metodologia MDA vir a se tornar popular no desenvolvimento
de software. Nesta questão os gráficos são idênticos, demonstrando que 90% dos
Pesquisadores e dos Profissionais de TI acreditam nesta possibilidade.
5.4 Pesquisa com desenvolvedores COPPETEC
Visando aumentar o escopo da pesquisa, em 04/08/2011 o mesmo questionário
de perguntas foi submetido a alunos e ex-alunos da UFRJ. O questionário foi enviado
por meio de correio eletrônico a 26 indivíduos que já trabalharam em algum projeto da
COPPETEC fazendo uso da MDA.
A pesquisa foi respondida por 18 pessoas, correspondendo a um total de 69% do
universo estabelecido. Como esta pesquisa é muito centrada em um contexto específico,
não seria válido somar estas respostas às analisadas de maneira geral em 5.2.1. Isso
poderia descaracterizar a amostra anterior.
Os parágrafos que seguem constituem análises comparativas das respostas dadas
pelo universo COPPETEC em relação às apresentadas na área internacional.
Analisando a formação acadêmica da COPPETEC, observa-se que seu gráfico se
apresenta em contraste em relação ao que está na área internacional. A COPPETEC tem
70
um percentual de 28% dos entrevistados detendo algum nível de pós-graduação
completo, enquanto na área internacional este índice sobe para 82%. Essa diferença se
mostra nítida no Gráfico 9.
Gráfico 9 - Comparativo da formação: COPPETEC x Internacional
Com relação à atividade principal, a pesquisa internacional leva em conta, em
sua maior parte, pesquisadores e profissionais de TI, enquanto que na COPPETEC o
perfil dos entrevistados, em sua maioria, são estudantes e ex-estudantes (hoje
profissionais de TI) que trabalharam em algum projeto de desenvolvimento de sistemas
com o uso prático da MDA. A Tabela 5 ilustra essa diferença.
Tabela 5 - Atividade principal: COPPETEC X Internacional
COPPETEC Internacional
Como você qualifica sua atividade principal? qtde % qtde %
Estudante 5 28% 4 12%
Pesquisador 2 11% 20 59%
Profissional de TI 11 61% 10 29%
Soma 18 100% 34 100%
Quanto a experiência com MDA, todos os entrevistados da COPPETEC já
trabalharam com esta tecnologia. Dentre eles, somente 2 (11%) dos entrevistados já
2
5
6
4
1
0
2
2
2
7
8
13
Nível Superior Incompleto
Nível Superior Completo
Mestrado Incompleto
Mestrado Completo
Doutorado Incompleto
Doutorado Completo
COPPETEC Internacional
71
publicaram algum artigo na área. Ao comparar esses dados com a outra pesquisa, nota-
se que este número sobe para 11 (34%), aproximadamente 3 vezes mais.
Com relação a opinião sobre a geração de código a partir de modelos, verifica-se
uma semelhança na aceitação da MDA, tanto entre os entrevistados da COPPETEC,
quanto na área internacional. Conforme apresentado na Tabela 6 houve um índice de
respostas positivas de 78% e 87% na COPPETEC e na pesquisa internacional,
respectivamente.
Tabela 6 - Geração de código: COPPETEC X Internacional
COPPETEC Internacional
O que vc acha sobre a geração de código de
sistemas de informação a partir de modelos?
qtde % qtde %
É o caminho correto, um dia iremos construir
sistemas de informação através de apenas
modelos
3 17% 10 31%
Viável até certo ponto do código do sistema de
informação, mas não 100% do mesmo
11 61% 18 56%
Não sou um apreciador desta prática 4 22% 3 10%
Não acredito nisto 0 0% 1 3%
Soma 18 100% 32 100%
A área de transformação de modelo foi indicada por 50% do universo
COPPETEC como área que necessita de mais pesquisa, sendo novamente a área mais
indicada.
Ao analisar os gráficos relacionados à última pergunta do questionário constata-
se que o número de entrevistados que acreditam na possibilidade da metodologia MDA
vir a se tornar popular no desenvolvimento de software é maior na área internacional.
Chama a atenção o fato que 28% dos entrevistados da COPPETEC não acreditam nesta
possibilidade, enquanto na área internacional esse índice é de 13% (menos que a
metade). O Gráfico 10 ilustra esse posicionamento.
72
Gráfico 10 - Comparativo da opinião sobre popularização da MDA: COPPETEC
X Internacional
Abaixo seguem algumas respostas da COPPETEC.
Responderam SIM
“Cada vez mais as empresas de desenvolvimento estão procurando uma
forma rápida, prática e objetiva de desenvolver sistemas de forma
eficiente. E com a MDA, essa proposta é bastante alcançada.”
“A ideia é muito boa e existem dados que comprovam aumento de
produtividade da equipe de desenvolvimento. Com mais algumas
necessidades atendidas e algumas ferramentas de referência, pode se
tornar popular!”
“Aprimora o desenvolvimento de software através da geração de código,
e o modelo é uma espécie de documentação atualizada.”
Responderam NÃO
“Falta muito na otimização de código, a consequência são sistemas de
baixa performance.”
“Já existem outros frameworks de geração automática de código, não
necessariamente baseados em modelos e que provêem os mesmos
benefícios.”
72%
28%
87%
13%
Sim Não
COPPETEC Internacional
73
5.5 Pesquisa na Engenharia de Software
O questionário de perguntas foi enviado ainda uma terceira vez, com o objetivo
de atingir a opinião de pessoas ligadas à área da Engenharia de Software. Visando
atingir um contexto abrangente, o questionário foi submetido em 04/10/2011 para a
SEWORLD (SEWORLD, 2011), para duas listas da Sociedade Brasileira de
Computação (SBC, 2011) ([email protected] e [email protected] – Comissão Especial
de Engenharia de Software) e para a Lista de Engenharia de Software da COPPE
([email protected]). Infelizmente, algumas semanas após o envio do questionário, a
SEWORLD não permitiu a sua publicação devido a sua política de não permitir surveys.
Os parágrafos a seguir contêm os resultados obtidos com esta nova pesquisa,
respondida por 37 pessoas. As respostas desta pesquisa são comparadas às respostas
obtidas pelo outros grupos. Além desta comparação, cujo objetivo é apontar as
diferenças e semelhanças entre os grupos, essas respostas também são somadas ao
resultado geral da pesquisa e fazem parte da sumarização final, contida no Anexo II.
A caracterização da amostra quanto à formação acadêmica e distribuição do
ramo de atividade principal se assemelha bastante a amostra internacional, com um
número alto de indivíduos com alguma pós-graduação (82% no contexto internacional e
76% em Engenharia de Software) e uma quantidade maior de pesquisadores em relação
as outras áreas de atuação (59% em ambos). A Tabela 7 e a Tabela 8 mostram essa
semelhança.
Tabela 7 - Nível de formação: Internacional X Engenharia de Software
Qual seu nível de formação? Internacional ES
Nível Superior Incompleto 2 2
Nível Superior Completo 2 1
Mestrado Incompleto 2 6
Mestrado Completo 7 10
Doutorado Incompleto 8 7
Doutorado Completo 13 11
74
Tabela 8 - Atividade principal: Internacional X Engenharia de Software
Internacional ES
Como você qualifica sua atividade principal? qtde % qtde %
Estudante 4 12% 4 11%
Pesquisador 20 59% 22 59%
Profissional de TI 10 29% 11 30%
Soma 34 100% 37 100%
Quanto a experiência com MDA, o gráfico se apresenta de maneira um pouco
diferente dos anteriores, tendo um número maior de respostas na alternativa que indica
o conhecimento sobre a MDA, mas sem a utilização prática. Essa alternativa foi
respondida por 16 (43%) dos entrevistados. No contexto internacional essa alternativa
contou com 24% das respostas. Dentre a pesquisa feita no ambiente COPPETEC,
ninguém respondeu essa alternativa, pois a pesquisa foi direcionada à pessoas com
experiência em MDA.
Mais uma vez, o indivíduo que respondeu não possuir conhecimento sobre MDA
não teve as suas respostas consideradas. O Gráfico 11 ilustra esse cenário.
Gráfico 11 - Experiência com MDA, pela Engenharia de Software
A opinião sobre a geração de código a partir de modelos, para o grupo da
Engenharia de Software, se mantém em relação às outras pesquisas. Para esta pergunta
há uma semelhança entre as respostas deste grupo, da COPPETEC e da área
internacional. A Tabela 9 realiza esta comparação.
1
16
9
7
4
0
2
4
6
8
10
12
14
16
18
Não sei o que MDA significa
Sei o que significa, mas
nunca trabalhei com isso
Já trabalhei com isso
Já publiquei artigos
relacionados a MDA
Já trabalhei e publiquei
artigos na área
75
Tabela 9 - Geração de código: COPPETEC X Internacional X ES
COPPETEC Internacional ES
O que vc acha sobre a geração de código de sistemas de informação a partir de modelos?
qtde % qtde % qtde %
É o caminho correto, um dia iremos construir sistemas de informação através de apenas modelos
3 17% 10 31% 8 22%
Viável até certo ponto do código do sistema de informação, mas não 100% do mesmo
11 61% 18 56% 23 64%
Não sou um apreciador desta prática 4 22% 3 10% 5 14%
Não acredito nisto 0 0% 1 3% 0 0%
Soma 18 100% 32 100% 36 100%
Como áreas que necessitam de mais pesquisa, se destacam CIM, PIM, PSM e
Transformação de Modelo, sendo este último o mais indicado. O Gráfico 12 abaixo
apresenta as áreas assinaladas pelos entrevistados.
Gráfico 12 - Áreas a aperfeiçoar, pela Engenharia de Software
A última pergunta do questionário mostra que o grupo de Engenharia de
Software não acredita na popularização da MDA da mesma forma que o grupo da
amostra internacional ou da COPPETEC. Ainda assim, observa-se um número maior de
pessoas que acreditam na popularização da MDA (61%) em relação aos que não
acreditam. O Gráfico 13 relaciona as respostas dos 3 grupos a essa pergunta.
12
14
7
13
20
9
10
11
8
0 5 10 15 20 25
CIM
PIM
PSM
Mapeamento de Modelo
Transformaçao de Modelo
Engenharia Reversa
Geração Automática de Documento
Métricas
Reuso de Mapeamento
76
Gráfico 13 - Comparativo da opinião sobre popularização da MDA: COPPETEC
X Internacional X Engenharia de Software
A seguir seguem algumas das respostas dos entrevistados de Engenharia de Software.
Responderam SIM
“Vai automatizar o desenvolvimento de tarefas cada vez mais, e
automatização significa economizar gastos.”
“Eu acredito que sim, porém ainda vai levar um tempo considerável.”
“Sim, devido às crescentes necessidades de desenvolvimento rápido de
software”
Responderam NÃO
“Eu não consigo acreditar que uma abordagem tão genérica pode ser
capaz de gerar códigos tão específicos.”
“Geração automática só é útil no mundo real da indústria se houver as
duas vias, de geração e de atualização do modelo a partir do código
modificado.”
72% 87%
61%
28% 13%
39%
COPPETEC Internacional ES
Sim Não
77
5.6 Considerações finais
A partir dos gráficos e das análises apresentadas, constata-se que a MDA é vista
de forma diferente com relação aos pesquisadores, profissionais de TI e estudantes.
A visão obtida pela COPPETEC, ao estabelecer um parâmetro com os dados da
pesquisa internacional, se aproxima mais da visão dos profissionais de TI. Isso
provavelmente ocorre pelo fato de que, dentro desse conjunto, há muito uso da MDA
em prática.
Dentre os três grupos entrevistados, o grupo de Engenharia de Software se
caracterizou como o que menos utilizou a MDA na prática. O grupo de Engenharia de
Software também foi o que apresentou a menor crença na popularização da MDA, com
61%. Mesmo que a pesquisa não tenha atingido um número muito alto de entrevistados,
é válido fazer a associação entre estas duas características, supondo que o fato deste
grupo não acompanhar de perto os benefícios práticos desta metodologia talvez esteja
relacionado a um índice menor de popularização da MDA em relação aos outros grupos.
Dentre todos os entrevistados, apesar da maioria enxergar um futuro promissor
para esta metodologia de desenvolvimento, pode-se dizer que a visão mais “otimista” é
por parte dos pesquisadores.
Fazendo um comparativo com o estudo (HUTCHINSON; ROUNCEFIELD;
WHITTLE; KRISTOFFERSEN, 2011b), previamente mencionado em 5.1, se percebe
uma convergência de resultado na opinião dos entrevistados sobre a geração de código.
Hutchinson et al. em sua pesquisa pergunta se o uso da geração de código é um
importante aspecto para os ganhos de produtividade com MDE. O resultado das
respostas se encontra na Figura 19.
Figura 19 - Ganho de produtividade com geração de código
(adaptada de HUTCHINSON et al., 2011b)
78
A área da Figura 19 composta por Definitivamente SIM, Provavelmente SIM e
Neutro correspondem a mais de 75% das respostas. A pesquisa internacional e a
pesquisa COPPETEC também apresentam uma alta aprovação, como foi mostrado na
Tabela 6.
O Anexo II do presente trabalho contém um resumo de todas as respostas do
questionário, incluindo as discursivas.
79
6. Conclusões
“Mais que simplesmente uma linguagem de design, MDA é sobre o uso de
linguagens de modelagem como linguagens de programação” (FRENKEL, 2002). Estas
são as palavras que Frenkel usa para definir a natureza da Arquitetura Orientada a
Modelo.
6.1 Contribuições
Para a realização do presente trabalho, foi necessária uma busca por artigos,
dissertações de mestrado, teses de doutorado e outros trabalhos na área MDA,
classificando-os conforme uma taxonomia proposta. As cinco categorias que compõem
a taxonomia foram definidas com base na especificação OMG. Em cada uma destas foi
identificado perspectivas futuras e o estado da arte.
O atual processo de desenvolvimento de sistema em MDA, de acordo com o que
foi observado nos trabalhos, pode ter o ciclo de vida dividido em cinco passos:
1. Criação manual do CIM para a captura de requisitos;
2. Desenvolvimento manual do PIM;
3. Mapeamento do PIM, adicionando regras específicas da plataforma desejada;
4. Transformação para o PSM;
5. Geração de código a partir do PSM.
Uma visão geral da MDA proporcionou a identificação de áreas onde não se faz
cumprimento da proposta contida na especificação OMG.
O passo 1 não é bem definido, não há atualmente uma padronização para o CIM.
Além disso, entre o passo 1 e 2 deveria existir um passo correspondente a transformação
automatizada objetivando a geração do PIM. Existem estudos em andamento para
atingir estes objetivos.
No passo 2, muitas abordagens carregam o PIM com informações específicas de
plataforma, descaracterizando a independência deste. Os demais passos cumprem o
estabelecido pelo OMG.
Ao todo 89 pessoas responderam ao questionário de perguntas que foi elaborado,
sendo 34 respostas no âmbito internacional, 18 por alunos e ex-alunos da COPPETEC e
37 por pessoas da área de Engenharia de Software.
80
O questionário possibilitou a identificação do perfil dos atuantes na área MDA
por meio de um condicionamento da atividade principal do entrevistado. Esses perfis
foram comparados e suas semelhanças e diferenças estabelecidas.
O questionário também apontou que mais de 70% do total dos entrevistados
acreditam na popularização da MDA como metodologia de desenvolvimento de
software, indicando um alto índice de aprovação.
A fim de relacionar os resultados do questionário de pergunta com os resultados
das análises dos trabalhos pesquisados, nota-se a importância da área de transformação
de modelo. Os 3 grupos que responderam ao questionário foram unânimes com relação
“Que áreas da MDA necessitam de maior aprimoramento/pesquisa?”. Os gráficos desta
resposta, para os 3 grupos, apontam a área de Transformação de Modelo. Isto mostra
como essa categoria está em evidência em relação as demais, tomando pra si o foco da
atenção dos entrevistados, em geral.
Por outro lado, o resultado obtido com os trabalhos pesquisados indicou que a
área de Transformação de Modelo, mas especificamente, a transformação PIM para
PSM, é a área onde se obteve uma maior facilidade em localizar os trabalhos. Há então,
uma certa controvérsia, no fato da área com maior abrangência de trabalhos ser ao
mesmo tempo a área indicada pelos entrevistados como a que necessita de mais
pesquisa.
Essa controvérsia pode ser atribuída ao fato da transformação ser a área onde se
obtém o produto final, o que pode acarretar num interesse por parte dos entrevistados
em obter um melhor produto final. Também é possível que parte dos entrevistados tenha
afirmado conhecer a MDA, mas na verdade o seu conhecimento a respeito da área está
restrito a modelagens e transformações com o uso de ferramentas prontas,
desconhecendo a maneira como a MDA foi especificada, onde prevê a construção de
um modelo CIM, por exemplo. Esses indivíduos poderiam não indicar o CIM por
simplesmente desconhecer do que essa se trata essa área.
Como contribuição final, a realização do presente trabalho exigiu uma imensa
pesquisa que se estendeu pela MDA e por técnicas de prospecção. Ao todo, foram mais
de 70 trabalhos analisados e organizados em uma biblioteca no Mendeley Desktop. Esta
biblioteca constitui uma valiosa fonte de pesquisa para trabalhos que estão porvir nesta
área e pode ser futuramente disponibilizada online.
81
6.2 Lições aprendidas e trabalho futuro
“As atividades de programação devem ser realizadas via modelagem conceitual.
Para aplicações passíveis de design através de modelos, os desenvolvedores de software
nunca deveriam escrever uma linha de código” (EMBLEY et al., 2007). Esta citação
resume bem a essência do desenvolvimento orientado a modelo. A realização deste
trabalho permitiu a observação de alguns aspectos da MDA que a impulsionam a se
tornar uma metodologia de desenvolvimento popular. Algumas vantagens observadas
são listadas a seguir:
A incorporação de modelos em diversos níveis de abstração permite ao
desenvolvedor uma visão do sistema a partir de diferentes pontos de vista;
O modelo, sempre atualizado em relação ao produto final, funciona como
uma espécie de documentação;
A geração de código reduz o custo do ciclo de vida de uma aplicação,
aumentando a produtividade;
A evolução das linguagens deixa um sistema de informação rapidamente
defasado. A existência do Modelo Independente de Plataforma agiliza a troca
evolutiva da plataforma e confere portabilidade ao software.
Os próximos desafios constituem o aumento do campo da pesquisa realizada.
Uma nova taxonomia poderia ser proposta, visando atingir outras áreas de
desenvolvimento que estão além do campo da especificação.
82
7.Referências Bibliográficas
ACM. Computing Surveys. Disponível em: <http://csur.acm.org/>. Acesso em: 24 jun.
2011.
AGRAWAL, A. Metamodel based model transformation language to facilitate
domain specific model driven architecture. Object-oriented programming, systems,
languages, and applications - OOPSLA ’03. Anais... New York, New York, USA:
ACM Press. Disponível em: <http://portal.acm.org/citation.cfm?doid=949344.949379>.
Acesso em: 25 nov. 2011. , 2003
ALMEIDA, J. P. A. SINDEREN, MARTEN VAN; PIRES, LUÍS FERREIRA. The
role of the RM-ODP Computational Viewpoint Concepts in the MDA approach.
(Marten van Sinderen & Luís Ferreira Pires, Eds.)1st European Workshop on Model-
Driven Architecture with Emphasis on Industrial Applications (MDA-IA 2004).
Anais... [S.l.]: Centre for Telematics and Information Technology, University of
Twente. Disponível em:
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.99.5503&rep=rep1&a
mp;type=pdf>. Acesso em: 3 ago. 2011. , 2004
ALMEIDA, J. P. DIJKMAN, R. SINDEREN, M VAN; PIRES, L F. Platform-
independent modelling in MDA: supporting abstract platforms. Model Driven
Architecture, p. 174–188, 2005.
ALMEIDA, P. DE. Improving Software Development Productivity in Large-Scale
Enterprise Applications. [S.l.]: Dissertação de M.Sc., Department of Informatics,
University of Fribourg, Switzerland, 2008.
AQUINO, N.; VANDERDONCKT, J. Usability evaluation of multi-device/platform
user interfaces generated by model-driven engineering. Empirical Software
Engineering and Measurement (ESEM), p. 10, 2010.
ASADI, M.; RAMSIN, R. MDA-Based Methodologies: An Analytical Survey. Model
Driven Architecture–Foundations and Applications. Anais... [S.l.]: Springer. Disponível
em: <http://www.springerlink.com/index/WK63R65217P693Q7.pdf>. Acesso em: 9
jun. 2011. , 2008
BETTIN, J.; BOAS, G. VAN E. Generative model transformer: an open source
MDA tool initiative. Object-oriented programming, systems, languages, and
applications (OOPSLA ’03). Anais... [S.l: s.n.]. Disponível em:
<http://dl.acm.org/citation.cfm?id=949419>. Acesso em: 25 nov. 2011. , 2003
BOWLES, J. B. Code from requirements: new productivity tools improve the
reliability and maintainability of software systems. Reliability and Maintainability,
2004 Annual Symposium-RAMS. Anais... [S.l.]: IEEE. Disponível em:
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1285425>. Acesso em: 3 ago.
2011. , 2004
83
BPMN. Business Process Model and Notation ( BPMN ). Business Process Modeling
Notation (BPMN), v. 50, n. January, p. 504-507, 2011.
BRITTON, J. P.; DEVOS, A. CIM-based standards and CIM evolution. Power Systems
IEEE Transactions on, v. 20, n. 2, p. 758-764, 2005.
BÉZIVIN, J. JOUAULT, F.; VALDURIEZ, P. On the need for megamodels.
Proceedings of the OOPSLA/GPCE: Best Practices for Model-Driven Software
Development workshop, 19th Annual ACM Conference on Object-Oriented
Programming, Systems, Languages, and Applications. Anais... [S.l: s.n.]. Disponível
em: <http://www.softmetaware.com/oopsla2004/bezivin-megamodel.pdf>. Acesso em:
29 ago. 2011. , 2004
CABOT, J.; TENIENTE, E. Constraint Support in MDA tools: a Survey. Model
Driven Architecture–Foundations and Applications. Anais... [S.l.]: Springer. Disponível
em: <http://www.springerlink.com/index/4902321654674181.pdf>. Acesso em: 9 jun.
2011. , 2006
CAO, X.-XIA; MIAO, H.-KOU; CHEN, Y.-HAI. Transformation from computation
independent model to platform independent model with pattern. Journal of Shanghai
University, v. 12, n. 6, p. 515-523, 13 jan 2009.
CARUSO, L. A.; TIGRE, P. B. Modelo SENAI de Prospecção: Documento
Metodológico. p. 17-35, 2004.
CHEHADE, W. E. H. RADERMACHER, A. CUCCURU, A. GÉRARD, S.; TERRIER,
F. Automating the Generation of Platform Specific Models. 14th IEEE International
Conference on Engineering of Complex Computer Systems. Anais... [S.l.]: IEEE.
Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5090552>. , 2009
CHEN, YING. Service Oriented Architecture. Business, v. 24, n. 2, p. 45-52, 2006.
COATES, V. On the Future of Technological Forecasting. Technological Forecasting
and Social Change, v. 67, n. 1, p. 1-17, maio 2001.
COCHRANE. Cochrane Handbook for Systematic Reviews of Interventions.
Disponível em: <http://www.cochrane.org/training/cochrane-handbook>. Acesso em:
17 nov. 2011.
COELHO, G. M. Prospecção tecnológica: metodologias e experiências nacionais e
internacionais. INT/Finep/ANP Projeto CT-Petro, 2003.
COPPE. Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de
Engenharia. Disponível em: <http://www.coppe.ufrj.br/>. Acesso em: 10 abr. 2011.
CUNHA, M. F. DA. Archimdas: Um arcabouço de Segurança Baseado em
Transformaçoes de Modelos em MDA. [S.l.]: Dissertação de M.Sc., NCE/UFRJ, Rio
de Janeiro, Brasil, 2007.
84
CZARNECKI, K.; HELSEN, D. Classification of model transformation approaches.
Techniques in the Context of the Model Driven, p. 1-17, 2003.
DBLP. The DBLP Computer Science Bibliography. Disponível em:
<http://www.informatik.uni-trier.de/~ley/db/>. Acesso em: 24 jun. 2011.
DBWORLD. DBWorld. Disponível em: <http://www.cs.wisc.edu/dbworld/>. Acesso
em: 14 abr. 2011.
DEBNATH, N. LEONARDI, M. MAUCO, M. MONTEJANO, G.; RIESCO, D.
Improving Model Driven Architecture with Requirements Models. Fifth
International Conference on Information Technology: New Generations (itng 2008).
Anais... [S.l.]: IEEE. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4492449>. Acesso
em: 19 ago. 2011. , abr 2008
DELANOTE, G.; STEEGMANS, E. Concepts for Abstracting away Object
Reification at the level of Platform Independent Models (PIMs). Fourth Workshop
on Model-Based Development of Computer-Based Systems and Third International
Workshop on Model-Based Methodologies for Pervasive and Embedded Software
(MBD-MOMPES’06). Anais... [S.l.]: IEEE. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1604769>. Acesso
em: 27 ago. 2011. , 2006
EMBLEY, D. W. LIDDLE, S. W.; PASTOR, O. Conceptual-Model Programming : A
Manifesto. Handbook of Conceptual Modeling. [S.l: s.n.], 2007. .
FALDA, G. HABELA, P. KACZMARSKI, K. STENCEL, K.; SUBIETA, K.
Executable Platform Independent Models for Data Intensive Applications.
Computational Science–ICCS 2008, p. 301–310, 2008.
FAVRE, L.; MARTINEZ, L. Formalizing MDA components. Lecture Notes in
Computer Science, v. 4039, p. 326–339, 2006.
FEILER, P. H. NIZ, D. DE; RAISTRICK, C.; LEWIS, B. A. From PIMs to PSMs.
12th IEEE International Conference on Engineering Complex Computer Systems.
Anais... [S.l.]: IEEE Computer Society. Disponível em:
<http://www.computer.org/portal/web/csdl/doi/10.1109/ICECCS.2007.25>. Acesso em:
5 set. 2011. , 2007
FOUAD, A. PHALP, K. KANYARU, J. M.; JEARY, S. Embedding requirements
within Model-Driven Architecture. Software Quality Journal, v. 19, n. 2, p. 411-430,
7 dez 2010.
FRENKEL, D. Model Driven Architecture: Applying MDA to Enterprise
Computing. New York, NY, USA: John Wiley & Sons, Inc., 2002. p. 224
GARRIDO, J. NOGUERA, M. GONZALEZ, M. HURTADO, M.; RODRIGUEZ, M.
Definition and use of Computation Independent Models in an MDA-based groupware
85
development process. Science of Computer Programming, v. 66, n. 1, p. 25-43, 15 abr
2007.
GIESE, H.; HENKLER, S. A survey of approaches for the visual model-driven
development of next generation software-intensive systems. Journal of Visual
Languages & Computing, v. 17, n. 6, p. 528-550, dez 2006.
GODET, M.; ROUBELAT, F. Creating the future: The use and misuse of scenarios.
Long Range Planning, v. 29, n. 2, p. 164-171, abr 1996.
GUNTER, C. A. GUNTER, E. L. JACKSON, M.; ZAVE, P. A Reference Model for
Requirements and Specifications. IEEE Software, v. 17, n. 3, p. 37-43, 2000.
HARRISON-BRONINSKI, K. Human Interaction Management and the future of
BPM. Process 2006. Anais... [S.l: s.n.]. , 2006
HEMME-UNGER, K. FLOR, T.; VOGLER, G. Model driven architecture
development approach for pervasive computing. Object-oriented programming,
systems, languages, and applications - OOPSLA ’03. Anais... New York, New York,
USA: ACM Press. Disponível em:
<http://portal.acm.org/citation.cfm?doid=949344.949429>. , 2003
HOU, J. Using Ontology Semantics to Support Model Mapping in Model-Driven
Software Development. 2010 Second International Workshop on Education
Technology and Computer Science, p. 248-251, 2010a.
HOU, J. Categorical Semantics of Architecture-Centric Model Mapping. 2010 Second
International Workshop on Education Technology and Computer Science, p. 240-
243, 2010b.
HOVSEPYAN, A. BAELEN, S. VAN; VANHOOFF, B. JOOSEN, W.; BERBERS, Y.
Key research challenges for successfully applying MDD within real-time embedded
software development. Technology. Anais... [S.l: s.n.]. Disponível em:
<http://dx.doi.org/10.1007/11796435_7>. Acesso em: 9 jun. 2011. , 2006
HUANG, G. CHEN, L.; HOU, J. A Semantic-Features-Calculation Based Model
Mapping Approach for Web Information Systems. 5th ACIS International
Conference on Software Engineering Research, Management & Applications (SERA
2007). Anais... [S.l.]: IEEE. Disponível em:
<http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=4296898>. Acesso em:
30 ago. 2011. , ago 2007
HUTCHINSON, J. ROUNCEFIELD, M. WHITTLE, J.; KRISTOFFERSEN, S. Model-
driven engineering practices in industry. Proceeding of the 33rd International
Conference on Software Engineering. Anais... [S.l.]: ACM. Disponível em:
<http://portal.acm.org/citation.cfm?id=1985882>. Acesso em: 9 set. 2011a. , 2011
HUTCHINSON, J. ROUNCEFIELD, M. WHITTLE, J.; KRISTOFFERSEN, S.
Empirical assessment of MDE in industry. Proceeding of the 33rd International
86
Conference on Software Engineering. Anais... [S.l.]: ACM. Disponível em:
<http://portal.acm.org/citation.cfm?id=1985858>. Acesso em: 9 set. 2011b. , 2011
ICCSA. International Conference on Computer Science and Applications.
Disponível em: <http://www.iccsa.org/>. Acesso em: 14 abr. 2011.
IEEE. IEEE Xplore Digital Library. Disponível em:
<http://ieeexplore.ieee.org/Xplore/guesthome.jsp>. Acesso em: 24 jun. 2011.
ISI. ISI Web of Knowledge. Disponível em: <http://wokinfo.com/>. Acesso em: 24
jun. 2011.
JOUAULT, FRÉDÉRIC; ALLILAIRE, F. BÉZIVIN, JEAN; KURTEV, I. ATL: A
model transformation tool. Science of Computer Programming, v. 72, n. 1-2, p. 31-
39, 1 jun 2008.
JSF. JavaServer Faces. Disponível em: <http://java.sun.com/j2ee/javaserverfaces/>.
Acesso em: 24 jun. 2011.
JUDSON, S. R. CARVER, D. L.; FRANCE, R. B. A metamodeling approach to model
transformation. Object-oriented programming, systems, languages, and applications
- OOPSLA ’03, n. 2, p. 326, 2003.
JÚNIOR, P. S. DOS S. Uma Abordagem de Desenvolvimento Baseada em Modelos
de Arquitetura Organizacional de TI: Da Semântica ao Desenvolvimento de
Sistemas. [S.l.]: Dissertação de M.Sc., PPGI/UFES, Espírito Santo, Brasil, 2009.
KDM. Architecture-Driven Modernization (ADM): Knowledge Discovery Meta-Model
(KDM), v1.0. Object Management Group, n. January, p. 310, 2008.
KELSEN, P. PULVERMUELLER, E.; GLODT, C. Specifying executable platform-
independent models using OCL. Electronic Communications of the EASST, v. 9,
2007.
KHERRAF, S. LEFEBVRE, É.; SURYN, W. Transformation from CIM to PIM
using patterns and archetypes. 19th Australian Conference on Software Engineering.
Anais... [S.l.]: IEEE. Disponível em:
<http://www.computer.org/portal/web/csdl/doi/10.1109/ASWEC.2008.63>. Acesso em:
5 set. 2011. , 2008
KLEPPE, A. WARMER, J.; BAST, W. MDA Explained: The Model Driven
Architecture: Practice and Promise. [S.l.]: Addison-Wesley, 2003. v. 83p. 192
KURTEV, I. BÉZIVIN, JEAN; JOUAULT, FRÉDÉRIC; VALDURIEZ, PATRICK.
Model-based DSL frameworks. Object-oriented programming systems, languages,
and applications - OOPSLA ’06, p. 602, 2006.
LANO, K. Constraint-driven development. Information and Software Technology, v.
50, n. 5, p. 406-423, abr 2008.
87
LEAL, L. PIRES, P. CAMPOS, M.; DELICATO, F. Natural MDA: Controlled Natural
Language for Action Specifications on Model Driven Development. On the Move to
Meaningful Internet Systems 2006: CoopIS, DOA, GADA, and ODBASE, p. 551–
568, 2006.
LEITE, J. C. S. DO P. HADAD, G. D. S. DOORN, J. H.; KAPLAN, G. N. A Scenario
Construction Process. Requirements Engineering, v. 5, n. 1, p. 38-61, 2000.
LEONARDI, M. C.; MAUCO, M. V. Integrating natural language oriented
requirements models into MDA. Integrating Natural Language Requirements
Models with MDA. Buenos Aires, Argentina: [s.n.], 2009. p. 2091-2102.
LEPPANEN, M. An Integrated Framework for Meta Modeling. Advances in
Databases and Information Systems. Anais... [S.l.]: Springer. Disponível em:
<http://www.springerlink.com/index/0036022644064775.pdf>. Acesso em: 30 ago.
2011. , 2006
LIU, YANG; MA, Y. An Approach for MDA Model Transformation Based on JEE
Platform. 4th International Conference on Wireless Communications, Networking
and Mobile Computing, p. 1-4, out 2008.
MARTE. The Official OMG MARTE Web Site. Disponível em:
<http://www.omg.org/omgmarte/>. Acesso em: 15 jun. 2011.
MATE, J. L.; SILVA, A. Requirements Engineering for Sociotechnical Systems.
[S.l.]: Information Science Publishing, 2005. p. 373
MDARTE. MDArte. Disponível em: <http://www.softwarepublico.gov.br/ver-
comunidade?community_id=9022831>. Acesso em: 14 jul. 2011.
MEADE, N.; ISLAM, T. Technological Forecasting--Model Selection, Model Stability,
and Combining Models. Management Science, v. 44, n. 8, p. 1115-1130, 1 ago 1998.
MENDELEY. Mendeley. Disponível em: <http://www.mendeley.com/download-
mendeley-desktop/>. Acesso em: 15 out. 2011.
MIRALVAND, M. R. Z. RAFE, V. RAFEH, R.; HAJIEE, M. Automatic Refinement of
Platform Independent Models. 2009 International Conference on Computer
Technology and Development, p. 191-195, 2009.
MOF. MetaObject Facility. Disponível em: <http://www.omg.org/mof/>. Acesso em:
12 ago. 2010.
MOREIRA, C. H. DE A. Transferência de Conhecimento entre Universidade e
Governo em Projetos de TI: o caso Siconv. [S.l.]: Dissertação de M.Sc.,
COPPE/UFRJ, Rio de Janeiro, Brasil, 2010.
NEKTARIOS GEORGALAS; AZMOODEH, M. CLARK, T. et al. MDA-Driven
Development of standard-compliant OSS components : the OSS / J Inventory Case-
88
Study. Technical Report - University of Kent at Canterbury Computing
Laboratory, v. 17, p. 44-60, 2004.
OCL. Object Constraint Language. International Business, v. 03, n. May, p. 852-852,
2010.
OMG. MDA Guide Version 1.0. 1. Object Management Group, v. 234, n. June, p. 51,
2003.
OMG. Object Management Group. Disponível em: <http://www.omg.org/>. Acesso
em: 10 ago. 2010.
OSIS, J. ASNINA, E.; GRAVE, A. Computation Independent Modeling within the
MDA. IEEE International Conference on Software – Science, Technology and
Engineering. Anais... [S.l.]: IEEE Computer Society. Disponível em:
<http://www.computer.org/portal/web/csdl/doi/10.1109/SwSTE.2007.20>. Acesso em:
19 ago. 2011. , 2007
PANACH, J. I. ESPAÑA, S. PEDERIVA, I.; PASTOR, O. Capturing interaction
requirements in a model transformation technology based on MDA. Journal of
Universal Computer Science, v. 14, n. 9, p. 1480-1495, 2008.
PARDILLO, J. MAZÓN, J.-N.; TRUJILLO, J. Bridging the semantic gap in OLAP
models. Proceeding of the ACM 11th international workshop on Data warehousing and
OLAP - DOLAP ’08. Anais... New York, New York, USA: ACM Press. Disponível
em: <http://portal.acm.org/citation.cfm?id=1458448>. Acesso em: 27 ago. 2011. , 2008
PARR, T. ANTLR - ANother Tool for Language Recognition. . [S.l: s.n.]. , 2009
PASTOR, O. MARÍN, B. GIACHETTI, G. VOS, T.; ABRAN, A. Evaluating the
usefulness of a functional size measurement procedure to detect defects in MDD
models. Proceedings of the 2010 ACM-IEEE International Symposium on Empirical
Software Engineering and Measurement (ESEM ’10). Anais... New York, New York,
USA: [s.n.]. Disponível em: <http://dl.acm.org/citation.cfm?id=1852849>. Acesso em:
25 nov. 2011. , 2010
PASTOR, O.; MOLINA, J. C. Model-Driven Architecture In Practice: A Software
Production Environment Based On Conceptual Modeling. [S.l: s.n.], 2007. p. 302
PINEL, R. E. A. CARMO, F. B. DO; MONTEIRO, R. S.; ZIMBRÃO, G. Improving
tests infrastructure through a model-based approach. ACM SIGSOFT Software
Engineering Notes, v. 36, n. 1, p. 1, 24 jan 2011.
POOLE, J. D. Model-driven architecture: Vision, standards and emerging technologies.
Workshop on Metamodeling and Adaptive Object Models ECOOP, n. April, p. 1-
15, 2001.
PORTER, A. L. Forecasting and management of technology. [S.l.]: John Wiley &
Sons, Inc., 1991. p. 448
89
PORTER, A. L. Technology futures analysis: Toward integration of the field and new
methods. Technological Forecasting and Social Change, v. 71, n. 3, p. 287-303, mar
2004.
QUERALT, A.; TENIENTE, E. A platform independent model for the electronic
marketplace domain. Software & Systems Modeling, v. 7, n. 2, p. 219-235, 11 abr
2007.
QVT. Query/View/Transformation. Disponível em:
<http://www.omg.org/spec/QVT/1.0/PDF/>. Acesso em: 12 abr. 2011.
RODRÍGUEZ, A. FERNÁNDEZ-MEDINA, E.; PIATTINI, M. A BPMN Extension for
the Modeling of Security Requirements in Business Processes. Ieice Transactions On
Information And Systems, v. 90, n. 4, p. 745-752, 2007a.
RODRÍGUEZ, A. FERNÁNDEZ-MEDINA, E.; PIATTINI, M. Towards CIM to PIM
Transformation : From Secure Business Processes Defined in BPMN to Use-Cases.
Lecture Notes in Computer Science, v. 4714, p. 408-415, 2007b.
SAE. Architecture Analysis and Design Language (AADL). SAE standards, v.
AS5506, n. 2, p. 578-593, 2009.
SAMPAIO, R. F.; MANCINI, M. C. Estudos de revisão sistemática: um guia para
síntese criteriosa da evidência científica. Rev. bras. fisioter, v. 11, n. 1, p. 83-89, fev
2007.
SANTOS, M. DE M. COELHO, GILDA MASSARI; SANTOS, D. M. DOS; FILHO,
L. F. Parcerias Estratégicas. Parcerias Estratégicas - n.19, p. 1-334, 2004.
SBC. Sociedade Brasileira de Computaçao. Disponível em:
<http://www.sbc.org.br/>. Acesso em: 4 out. 2011.
SBVR. Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. Object
Management Group, v. January, n. January, p. 422, 2008.
SCIENCEDIRECT. ScienceDirect. Disponível em: <http://www.sciencedirect.com/>.
Acesso em: 24 jun. 2011.
SEWORLD. SEWORLD. Disponível em: <http://www.sigsoft.org/seworld/>. Acesso
em: 4 out. 2011.
SILAGHI, R. Refining designs along middleware-specific concern-dimensions at
different MDA-levels of abstraction. Object-oriented programming systems,
languages, and applications - OOPSLA ’04, p. 60, 2004.
SINGH, Y.; SOOD, M. Model driven architecture: A perspective. Advance
Computing Conference, 2009. IACC 2009. IEEE International. Anais... [S.l.]: IEEE.
Disponível em: <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4809264>.
Acesso em: 31 ago. 2011. , 2008
90
SINGH, YASHWANT; SOOD, MANU. Models and Transformations in MDA. First
International Conference on Computational Intelligence, Communication Systems
and Networks, p. 253-258, jul 2009.
SINGH, YASHWANT; SOOD, MANU. The Impact of the Computational Independent
Model for Enterprise Information System Development. International Journal of
Computer Applications IJCA, v. 11, n. 8, p. 24–28, 2010.
SIQUEIRA, F. L.; SILVA, P. S. M. Mapping the WRSPM Model to Model-Driven
Architecture Models. 2011 Eighth International Conference on Information
Technology: New Generations, p. 750-753, abr 2011.
SKUMANICH, M.; SILBERNAGEL, M. Foresighting around the world: a review of
seven best-in-kind programs. USA: Battelle Seatle, 1997.
SMITH, M. K. WELTY, C.; MCGUINNESS, D. L. OWL Web Ontology Language
Guide. (Recommendation, Ed.)W3C Recommendation. [S.l.]: The World Wide Web
Consortium (W3C). Disponível em: <http://www.w3.org/TR/owl-guide/>. , 2004
SOFTWAREPUBLICO. Portal do Software Público Brasileiro. Disponível em:
<http://www.softwarepublico.gov.br/>. Acesso em: 14 jul. 2011.
SOLMS, F. Technology neutral business process design using URDAD. Proceeding
of the 2007 conference on New Trends in Software Methodologies Tools and
Techniques Proceedings of the sixth SoMeT. Anais... [S.l.]: IOS Press. Disponível em:
<http://portal.acm.org/citation.cfm?id=1566976>. , 2007
SOLMS, F.; LOUBSER, D. Generating MDA’s platform independent model using
URDAD. Knowledge-Based Systems, v. 22, n. 3, p. 174-185, abr 2009.
STRONG, O. CHIANG, C. C. KIM, H. K. KANG, B.; LEE, R. Layering MDA:
Applying Transparent Layers of Knowledge to Platform Independent Models. Software
Engineering, Artificial Intelligence, Networking and Parallel/Distributed
Computing, p. 191–199, 2009.
UML. OMG Unified Modeling Language Specification. Management, v. 2005, n.
March, p. 62-62, 2003.
UML. Unified Modeling Language. Disponível em: <http://www.uml.org/>. Acesso
em: 12 ago. 2010.
VALLECILLO, A. RM-ODP : The ISO Reference Model for Open Distributed
Processing. Management, v. 27, n. 8, p. 69–99, 1999.
VALVERDE, F. PANACH, I.; PASTOR, O. An abstract interaction model for a
MDA software production method. Tutorials, posters, panels and industrial
contributions at the 26th International Conference on Conceptual modeling. Anais...
Auckland, New Zealand: Australian Computer Society, Inc. Disponível em:
<http://portal.acm.org/citation.cfm?id=1386974>. Acesso em: 3 ago. 2011. , 2007
91
VIDALES, M. A. S. GARCIA, A. M. F.; AGUILAR, L. J. A new MDA approach based
on BPM and SOA to improve software development process. Review Literature And
Arts Of The Americas, v. VI, 2008.
XMI. MOF 2.0/XMI Mapping, Version 2.1.1. OMG Available Specification with
change bars, n. December, 2007.
XMI. XML Metadata Interchange. Disponível em:
<http://www.omg.org/spec/XMI/>. Acesso em: 12 ago. 2010.
XUML. Semantics of a Foundational Subset for Executable UML Models. Object
Management Group, n. March, 2008.
ZEPEDA, L. CECEÑA, E. QUINTERO, R. et al. A MDA Tool for Data Warehouse.
2010 International Conference on Computational Science and Its Applications, p.
261-265, 2010.
ZHANG, JIANFU; FENG, P. WU, Z. YU, D.; CHEN, K. E. N. Activity based CIM
modeling and transformation for business process systems. International Journal of
Software Engineering and Knowledge Engineering IJSEKE, v. 20, n. 3, p. 289-309,
2010.
ZHANG, JINGJUN; CHEN, YUEJUAN. Aspect-oriented modeling and mapping
driven by Model Driven Architecture. 2009 2nd IEEE International Conference on
Computer Science and Information Technology, p. 180-184, 2009.
ZHU, L. BUI, N. LIU, Y; GORTON, I. MDABench: Customized benchmark
generation using MDA. Object-oriented programming, systems, languages, and
applications - OOPSLA’ 05. Anais... New York, NY, USA: [s.n.]. Disponível em:
<http://linkinghub.elsevier.com/retrieve/pii/S0164121206003384>. , fev 2005
92
ANEXO I – QUESTIONÁRIO SOBRE PROSPECÇÃO
TECNOLÓGICA EM MDA
93
94
95
ANEXO II – RESUMO DAS RESPOSTAS AO
QUESTIONÁRIO
O resumo das respostas ao questionário foi gerado automaticamente pelo Google Docs
(http://docs.google.com) e contou com 89 respostas, no total.
96
97
Why?
“I think it is the right approach to deal with complex software development. Models can
be used to automate many tasks such as testing of the system.”
“It reduces the time to develop.”
“There are several basic applications (set and get applications) where part of the code
can be done automatically.”
“MDA is perhaps a hotter topic in Academia than in Industry, but I think that it will be
mainstream in 2 or 3 years.
There are lot of people making real progress in the area.
I can refer to people I know most, like Jordi Cabot (www.softmodeling.com) or Oscar
Pastor and Vicente Pelechano.”
“Because of the trend towards abstraction.”
“MDA is useful in simple systems, in complex systems, with many specific rules, this
approach not so useful.”
“The MDA may not become popular, but the entire concept of model-driven software
development will.
This is the next evolutionary step in software development. We've gone from
procedural to OOP to patterns/anti-patterns.
Model-driven approaches, especially those that provide comprehensive model
execution, expose the Best Of Breed development patterns to designers/developers,
allowing them to focus on the solution to the business problem they are trying to solve
and isolating them from the technical complexities of running that solution.”
“Considering the complexity of future's software systems, we need to develop
methodologies that provide higher abstraction layers for different viewpoints of the
system in question. MDA could be a very good candidate to support such a
development methodology.”
“We have developed a library of solution pattern and a mapping facility for generic
functions and schemata.”
98
“In terms of supporting domain sciences, connecting the dots in some technologies is
becoming increasingly more complex, commanding more understanding and
experience to write this code by hand and maintain it.
This is absolutely essential as scientific data is disseminated and scientific domains
disseminate and access each others information because IT can work with scientists to
design the model AND computer scientists can spend more time enabling the science
rather than maintaining and continually rewriting numerous software layers.”
“MDA in itself is a good idea. It is just being used badly and resulting in failures. Work
needs to be done to allow development teams adopt MDA in an Agile manner.”
“The set of questions is much too restrictive and does not cover all current aspects of
Model Driven Engineering. IMHO the results will not be broadly significant.”
“It will be one of the options for taming software complexity.”
“It will become popular, but not for all coding applications -- only those to which
conceptual modeling is amenable (i.e., those applications for which object-relationship
modeling, object behavior modeling, object interaction modeling, and interface
modeling nicely apply).”
“I believe in MDD, but MDA has a lot of baggage to carry along with it. I believe in the
long-term vision of MDD, but not the short-term approaches taken to it.
Perhaps we can succeed in more narrow domains initially. But trying to do MDA for all
software is premature with today's technology.”
“It's automated process for majority of routine code development.”
“The need for higher levels of abstraction is obvious, and so is the need of
independence of concrete implementation technologies as the market is very
fragmented and technologies become obsolete very rapidly.”
“I think it good for specific applications but tools have to be improved.”
“Tools are becoming mature.”
99
“In my opinion it will become popular (and is already popular) in the development of
big software product because adopting it the quality / maintainability of the final product
will be higher.
For small product the efforts that must be put in the designing using MDA do not
generate benefit.”
“Programming languages happened more and more user and model friendly with
possibilities to generate code from high level definition and models.
The same with architecture - methods are evolving, and it will be possible to generate
drafts and documentation from high level concepts and domain related definitions. It
would be very convenient for software developers.”
“Modern, advanced software of quality should be based on the notion that „the model is
the code‟, instead of "the code is the model‟.”
“It reduces the development effort.”
“For repetitive development tasks there is a real benefit by using MDA techniques.”
“MDA leads to huge software quality improvements... And so allows to focus efforts on
business needs.”
“It makes the development of big systems easier and faster.”
“The code stays a bit truncated.”
“It lacks a lot of code optimization and consequently leading to bad performance
systems.”
“It favors the creation of standards in the code at the same time you use part of the
documentation (model) to generate code. Using MDA, documentation and system
developed will always be aligned.”
“In the present time the developers cannot lose time anymore codifying parts that can
be automated.”
100
“MDA is still a young methodology, younger than 9 years old, and it has to first break
the paradigm related to code generation, which was introduced in the last 70's.”
“Apesar de poder se aplicar muito bem a qualquer tipo de projeto, principalmente os de
grande porte, acredito que muita gente não goste da ideia. Principalmente a equipe,
porque, a meu ver, o MDA pode „emburrecer‟ no sentido de não saber como os
frameworks utilizados funcionam por trás dos panos.”
“Muitas vezes, quem decide qual método deve ser utilizado não é quem conhece.
Assim, mesmo antes de MDA ficar 100% eficiente, estas pessoas de decisão verão
que é uma alternativa fácil e rápida e determinarão que as empresas devem utilizar.
Isso também impulsionará as pesquisas em MDA, fazendo chegar ao nível de 100%
eficiente (ou pelo menos algo suficientemente eficiente).”
“Cada vez mais as empresas de desenvolvimento estão procurando uma forma rápida,
prática e objetiva de desenvolver sistemas de forma eficiente. E com a MDA, essa
proposta é bastante alcançada.”
“MDA te transforma em um programador limitado.”
“A ideia é muito boa e existem dados que comprovam aumento de produtividade da
equipe de desenvolvimento. Com mais algumas necessidades atendidas e algumas
ferramentas de referência pode se tornar popular!”
“Acredito que é uma questão de evangelização, de quebrar „tabus‟ mentais dos
programadores. Acho que no dia em que alguma ferramenta tomar a frente do
desenvolvimento a tendência é que MDA se torne mais popular.”
“Já existem outros frameworks de geração automática de código, não
necessariamente baseados em modelos e que provêem os mesmos benefícios.”
“Novas tecnologias para desenvolvimento de software aparecem todos os dias, mas a
modelagem por trás dele, UML, sofre poucas modificações.
É muito mais inteligente usar a MDA, ao invés de perder tempo aprendendo
tecnologias que se tornarão obsoletas.”
101
“Aprimora o desenvolvimento de software através da geração de código e provê uma
documentação atualizada.”
“Se tornará popular porque gera automaticamente artefatos necessários às aplicações
e aderentes aos padrões de projeto e de arquitetura.”
“O MDA não olha só para o presente como para o futuro, preparando as aplicações
para se adaptarem melhor as mudanças tecnológicas cada vez mais constantes.
A necessidade de utilizar novas tecnologias ou se comunicar com aplicações que as
utilizam vai aumentar cada vez mais, fazendo do MDA um aliado no desenvolvimento
dos projetos.”
“Because it is cost effective when good tools are available.”
“O MDA é uma abordagem para desenvolvimento de software que possui muitos
desafios a serem superados para que esta seja amplamente popular no mercado de
TI. Dentre estes desafios pode-se notar a insuficiência de ferramentas que
empreguem o MDA, a falta de conhecimento desta abordagem por parte dos
profissionais e estudantes de graduação, a complexidade em lidar com esta
abordagem, entre outros.
Possíveis formas de tornar esta abordagem mais popular seria disponibilizar cursos e
treinamentos nas ferramentas já existentes para os profissionais e ainda incluir esta
abordagem na ementa de graduação dos cursos de computação. Isto irá trazer
motivação aos estudantes e profissionais para conhecerem a abordagem.”
“I think so. However it depends on the reliability that next solution will bring.”
“Eu acredito que sim, porém ainda vai levar um tempo considerável.”
“As the software development is in constant evolution, it's evident the fact that the
paradigm shift in the development will happen, and as is the trend, increasing
abstraction from the former models (case like structural to object paradigms). It may
happen tomorrow or in 10 years, but I definitely think we'll get there.”
“Yes, because it will automate development tasks more and more, and automation
means saving money.”
102
“Because I can‟t beleive that a very generic approuch can develop a so deep source
code.”
“Devido às crescentes necessidades de desenvolvimento rápido de software.”
“MDA can improve a lot of software development concerning agility, documentation,
guarantee of patterns use, because models have a high level of abstractions. They are
easier to explain and change related to code.”
“Because the MDA standard is obsolete and seems that the OMG consortium does not
intend to update the standard. Actually, there are other ways for doing MD* (model-
driven stuffs in general) regardless the MDA standard by OMG. I believe on MDD in
general and DSLs, but not on MDA.”
“Needs more (serious) formalization and many levels of abstraction upon it to become
useful; it may work for specific domains, though.”
“I think MDA is already popular in software development, but not so much used.”
“Generating code from high-level models has been in use for more than 30 years and
improvements over the last 10 or 20 ones has been limited. I believe that we have
achieved a lot and, therefore, MD software development is an important issue. On the
other hand, I also believe that if we are to achieve more, details have to be added to
the models and they will become closer to code. It may be that, at some point, people
will be more comfortable writing code than such detailed models.”
“Maybe some kinds of software can be modeled before the construction phase,
however I think there are others that need a prototyped based development.”
“Trabalho a 3 anos com MDA e pode até ser de certa ajuda no desenvolvimento inicial
de uma funcionalidade, mas manutenções que deveriam ser simples ficam muito
demoradas pela necessidade de alteração de modelos e nova geração.
Além disso, para atender às necessidades do sistema a modelagem se torna muito
complexa e cheia de „tagged values‟ que deixa de ser visual (não tem a devida
abstração). Passa a ser uma programação em um emaranhado de „caixas, linhas e
comentários‟.”
103
“Engineers are mainly interested in developing code, not models. Agile methods made
such wrong idea increase in the earlier years.”
“Yes, but still exists preconceptions by developers to use such methodology to build
application systems.”
“Novas tecnologias estão surgindo rapidamente e os desenvolvedores de sistemas
não estão conseguindo acompanhar esta evolução. Novos paradigmas surgem e
muitas vezes o sistema tem que ser refeito do zero. Por que não descrever em alto
nível um sistema e depois gerar o código-fonte?!”
“Geração automática só é útil no mundo real da indústria se houver as duas vias, de
geração e de atualização do modelo a partir do código modificado.”
“No, because only very specific domains such as real time embedded systems (in car
or airplane industry) can make good use of it and profit.”
“Yes, because I do believe that it is the best approach to general software
development.”
104
ANEXO III – TABELA DE CLASSIFICAÇÃO DOS
TRABALHOS
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
AG
RA
WA
L, A
. M
etam
od
el b
ase
d m
od
el t
ran
sform
ati
on
lan
gu
age
to f
aci
lita
te
dom
ain
sp
ecif
ic m
od
el d
riv
en a
rch
itec
ture
. 2003
AL
ME
IDA
, J.
P. A
. S
IND
ER
EN
, M
AR
TE
N V
AN
; P
IRE
S,
LU
ÍS F
ER
RE
IRA
.
Th
e ro
le o
f th
e R
M-O
DP
Co
mp
uta
tion
al
Vie
wp
oin
t C
on
cep
ts i
n t
he
MD
A
ap
pro
ach
. 20
04
AL
ME
IDA
, J.
P. D
IJK
MA
N, R
. S
IND
ER
EN
, M
VA
N;
PIR
ES
, L
F.
Pla
tform
-
ind
epen
den
t m
od
elli
ng
in
MD
A:
sup
port
ing a
bst
ract
pla
tform
s. 2
005
AQ
UIN
O, N
.; V
AN
DE
RD
ON
CK
T, J.
Usa
bil
ity e
valu
ati
on
of
mu
lti-
dev
ice/
pla
tfo
rm u
ser
inte
rfa
ces
gen
erate
d b
y m
od
el-d
riven
en
gin
eeri
ng.
2010
BE
TT
IN, J.
; B
OA
S, G
. V
AN
E.
Gen
erati
ve
mod
el t
ran
sform
er:
an
op
en s
ou
rce
MD
A t
oo
l in
itia
tiv
e. 2
00
3
BR
ITT
ON
, J.
P.;
DE
VO
S, A
. C
IM-b
ase
d s
tan
dard
s an
d C
IM e
volu
tion
. 2005
BÉ
ZIV
IN, J.
JO
UA
UL
T, F
.; V
AL
DU
RIE
Z,
P.
On
th
e n
eed
for
meg
am
od
els.
2004
CA
O,
X.-
XIA
; M
IAO
, H
.-K
OU
; C
HE
N,
Y.-
HA
I. T
ran
sform
ati
on
fro
m
com
pu
tati
on
in
dep
end
ent
mo
del
to p
latf
orm
in
dep
end
ent
mod
el w
ith
patt
ern
.
2009
105
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
CH
EH
AD
E, W
. E
. H
. R
AD
ER
MA
CH
ER
, A
. C
UC
CU
RU
, A
. G
ÉR
AR
D,
S.;
TE
RR
IER
, F
.
Au
tom
ati
ng t
he
Gen
erati
on
of
Pla
tfo
rm S
pec
ific
Mod
els.
2009
CH
EN
, Y
ING
. S
erv
ice
Ori
ente
d A
rch
itec
ture
. 2006
CZ
AR
NE
CK
I, K
.; H
EL
SE
N, D
. C
lass
ific
ati
on
of
mod
el t
ran
sform
ati
on
ap
pro
ach
es.
2003
DE
BN
AT
H, N
. L
EO
NA
RD
I, M
AR
IA C
AR
ME
N;
MA
UC
O,
MA
RIA
VIR
GIN
IA;
MO
NT
EJA
NO
,
G.;
RIE
SC
O, D
. Im
pro
vin
g M
od
el D
riven
Arc
hit
ectu
re w
ith
Req
uir
emen
ts M
od
els.
2008
DE
LA
NO
TE
, G
.; S
TE
EG
MA
NS
, E
. C
on
cep
ts f
or
Ab
stra
ctin
g a
way O
bje
ct R
eifi
cati
on
at
the
level
of
Pla
tform
In
dep
end
ent
Mo
del
s (P
IMs)
. 2006
FA
LD
A,
G. H
AB
EL
A, P
. K
AC
ZM
AR
SK
I, K
. S
TE
NC
EL
, K
.; S
UB
IET
A,
K.
Exec
uta
ble
Pla
tform
Ind
epen
den
t M
od
els
for
Da
ta I
nte
nsi
ve
Ap
pli
cati
on
s. 2
008
FA
VR
E,
L.;
MA
RT
INE
Z, L
. F
orm
ali
zin
g M
DA
com
pon
ents
. 2006
FE
ILE
R,
P. H
. N
IZ, D
. D
E;
RA
IST
RIC
K,
C.;
LE
WIS
, B
. A
. F
rom
PIM
s to
PS
Ms.
2007
106
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
FO
UA
D,
A. P
HA
LP
, K
. K
AN
YA
RU
, J.
M.;
JE
AR
Y, S
. E
mb
edd
ing r
equ
irem
ents
wit
hin
Mod
el-
Dri
ven
Arc
hit
ectu
re. 2
01
0
GA
RR
IDO
, J.
NO
GU
ER
A,
M. G
ON
ZA
LE
Z,
M.
HU
RT
AD
O,
M.;
RO
DR
IGU
EZ
, M
. D
efin
itio
n
an
d u
se o
f C
om
pu
tati
on
In
dep
end
ent
Mod
els
in a
n M
DA
-base
d g
rou
pw
are
dev
elop
men
t
pro
cess
. 20
07
GU
NT
ER
, C
. A
. G
UN
TE
R, E
. L
. JA
CK
SO
N,
M.;
ZA
VE
, P
. A
Ref
eren
ce M
od
el f
or
Req
uir
emen
ts
an
d S
pec
ific
ati
on
s. 2
00
0
HA
RR
ISO
N-B
RO
NIN
SK
I, K
. H
um
an
In
tera
ctio
n M
an
agem
ent
an
d t
he
futu
re o
f B
PM
. 2006
HE
MM
E-U
NG
ER
, K
. F
LO
R, T
.; V
OG
LE
R,
G.
Mod
el d
riven
arc
hit
ectu
re d
evel
op
men
t ap
pro
ach
for
per
vasi
ve
com
pu
tin
g. 2
00
3
HO
U,
J. U
sin
g O
nto
log
y S
ema
nti
cs t
o S
up
port
Mod
el M
ap
pin
g i
n M
od
el-D
riven
Soft
ware
Dev
elop
men
t. 2
010
HO
U,
J. C
ate
go
rica
l S
eman
tics
of
Arc
hit
ectu
re-C
entr
ic M
od
el M
ap
pin
g. 2010
HU
AN
G,
G. C
HE
N, L
.; H
OU
, J.
A S
eman
tic-F
eatu
res-
Calc
ula
tion
Base
d M
od
el M
ap
pin
g
Ap
pro
ach
fo
r W
eb I
nfo
rma
tio
n S
yst
ems.
2007
107
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
JOU
AU
LT
, F
RÉ
DÉ
RIC
; A
LL
ILA
IRE
, F
. B
ÉZ
IVIN
, JE
AN
; K
UR
TE
V,
I. A
TL
: A
mod
el
tran
sform
ati
on
to
ol.
20
08
JUD
SO
N, S
. R
. C
AR
VE
R,
D. L
.; F
RA
NC
E,
R.
B.
A m
etam
od
elin
g a
pp
roach
to m
od
el
tran
sform
ati
on
. 2
00
3
JÚN
IOR
, P
. S
. D
OS
S.
Um
a A
bo
rda
gem
de
Des
en
volv
imen
to B
ase
ad
a e
m M
od
elos
de
Arq
uit
etu
ra O
rga
niz
aci
on
al
de
TI:
Da S
emân
tica
ao D
esen
volv
imen
to d
e S
iste
mas.
2009
KE
LS
EN
, P
. P
UL
VE
RM
UE
LL
ER
, E
.; G
LO
DT
, C
. S
pec
ifyin
g e
xec
uta
ble
pla
tform
-in
dep
end
ent
mod
els
usi
ng
OC
L.
20
07
KH
ER
RA
F, S
. L
EF
EB
VR
E, É
.; S
UR
YN
, W
. T
ran
sform
ati
on
fro
m C
IM t
o P
IM u
sin
g p
att
ern
s
an
d a
rch
ety
pes
. 2
00
8
KU
RT
EV
, I.
BÉ
ZIV
IN, JE
AN
; JO
UA
UL
T,
FR
ÉD
ÉR
IC;
VA
LD
UR
IEZ
, P
AT
RIC
K.
Mod
el-b
ase
d
DS
L f
ram
ewo
rks.
20
06
LA
NO
, K
. C
on
stra
int-
dri
ven
dev
elo
pm
ent.
2008
LE
AL
, L
. P
IRE
S, P
. C
AM
PO
S, M
.; D
EL
ICA
TO
, F
. N
atu
ral
MD
A:
Con
troll
ed N
atu
ral
Lan
gu
ag
e
for
Act
ion
Sp
ecif
icati
on
s o
n M
od
el D
riven
Dev
elop
men
t. 2
006
108
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
LE
ITE
, J.
C. S
. D
O P
. H
AD
AD
, G
. D
. S
. D
OO
RN
, J.
H.;
KA
PL
AN
, G
. N
. A
Sce
nari
o
Con
stru
ctio
n P
roce
ss. 2
000
LE
ON
AR
DI,
M C
; M
AU
CO
, M
V.
Inte
gra
tin
g n
atu
ral
lan
gu
age
ori
ente
d r
equ
irem
ents
mod
els
into
MD
A.
20
09
LE
PP
AN
EN
, M
. A
n I
nte
gra
ted
Fra
mew
ork
for
Met
a M
od
elin
g.
2006
LIU
, Y
AN
G;
MA
, Y
. A
n A
pp
roa
ch f
or
MD
A M
od
el T
ran
sform
ati
on
Base
d o
n J
EE
Pla
tform
.
2008
MA
TE
, J.
L.;
SIL
VA
, A
. R
equ
irem
ents
En
gin
eeri
ng f
or
Soci
ote
chn
ical
Syst
ems.
2005
MIR
AL
VA
ND
, M
. R
. Z
. R
AF
E, V
. R
AF
EH
, R
.; H
AJI
EE
, M
. A
uto
mati
c R
efin
emen
t o
f P
latf
orm
Ind
epen
den
t M
od
els.
20
09
NE
KT
AR
IOS
GE
OR
GA
LA
S;
AZ
MO
OD
EH
, M
. C
LA
RK
, T
. et
al.
MD
A-D
riven
Dev
elop
men
t of
stan
dard
-com
pli
an
t O
SS
co
mp
on
ents
: t
he
OS
S /
J I
nven
tory
Case
-Stu
dy.
2004
OS
IS,
J. A
SN
INA
, E
.; G
RA
VE
, A
. C
om
pu
tati
on
In
dep
end
ent
Mod
elin
g w
ith
in t
he
MD
A.
2007
109
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
PA
NA
CH
, J.
I. E
SP
AÑ
A, S
. P
ED
ER
IVA
, I.
; P
AS
TO
R,
O.
Cap
turi
ng i
nte
ract
ion
req
uir
emen
ts i
n
a m
od
el t
ran
sfo
rma
tio
n t
ech
no
logy
base
d o
n M
DA
. 2008
PA
RD
ILL
O, J.
MA
ZÓ
N, J.
-N.;
TR
UJI
LL
O, J.
Bri
dgin
g t
he
sem
an
tic
gap
in
OL
AP
mod
els.
20
08
PA
RR
, T
. A
NT
LR
- A
No
ther
To
ol
for
Lan
gu
age
Rec
ogn
itio
n. 2009
PA
ST
OR
, O
. M
AR
ÍN, B
. G
IAC
HE
TT
I, G
. V
OS
, T
.; A
BR
AN
, A
. E
valu
ati
ng t
he
use
fuln
ess
of
a
fun
ctio
nal
size
mea
surem
ent
pro
ced
ure
to d
etec
t d
efec
ts i
n M
DD
mod
els.
2010
PA
ST
OR
, O
.; M
OL
INA
, J.
C.
Mo
del
-Dri
ven
Arc
hit
ectu
re I
n P
ract
ice:
A S
oft
ware
Pro
du
ctio
n
En
vir
on
men
t B
ase
d O
n C
on
cep
tual
Mod
elin
g. 2007
PIN
EL
, R
. E
. A
.; C
AR
MO
, F
. B
. D
O;
MO
NT
EIR
O,
R. S
.; Z
IMB
RÃ
O,
G.
Imp
rovin
g t
ests
infr
ast
ruct
ure
th
rou
gh
a m
od
el-b
ase
d a
pp
roach
. 2011
QU
ER
AL
T, A
.; T
EN
IEN
TE
, E
. A
pla
tform
in
dep
end
ent
mod
el f
or
the
elec
tron
ic m
ark
etp
lace
dom
ain
. 20
07
RO
DR
ÍGU
EZ
, A
. F
ER
NÁ
ND
EZ
-ME
DIN
A,
E.;
PIA
TT
INI,
M. A
BP
MN
Exte
nsi
on
for
the
Mod
elin
g o
f S
ecu
rity
Req
uir
emen
ts i
n B
usi
nes
s P
roce
sses
. 2007
110
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
RO
DR
ÍGU
EZ
, A
. F
ER
NÁ
ND
EZ
-ME
DIN
A,
E.;
PIA
TT
INI,
M. T
ow
ard
s C
IM t
o P
IM
Tra
nsf
orm
ati
on
: F
rom
Sec
ure
Bu
sin
ess
Pro
cess
es D
efin
ed i
n B
PM
N t
o U
se-C
ase
s. 2
007
SB
VR
. S
ema
nti
cs o
f B
usi
nes
s V
oca
bu
lary
an
d B
usi
nes
s R
ule
s (S
BV
R),
v1.0
. 2008
SIL
AG
HI,
R.
Ref
inin
g d
esig
ns
alo
ng
mid
dle
ware
-sp
ecif
ic c
on
cern
-dim
ensi
on
s at
dif
fere
nt
MD
A-l
evel
s o
f a
bst
ract
ion
. 2
00
4
SIN
GH
, Y
AS
HW
AN
T;
SO
OD
, M
AN
U.
Mod
els
an
d T
ran
sform
ati
on
s in
MD
A.
2009
SIN
GH
, Y
AS
HW
AN
T;
SO
OD
, M
AN
U.
Th
e Im
pact
of
the
Com
pu
tati
on
al
Ind
epen
den
t M
od
el
for
En
terp
rise
In
form
ati
on
Sy
stem
Dev
elop
men
t. 2
010
SIQ
UE
IRA
, F
. L
.; S
ILV
A, P
. S
. M
. M
ap
pin
g t
he
WR
SP
M M
od
el t
o M
od
el-D
riven
Arc
hit
ectu
re
Mod
els.
20
11
SM
ITH
, M
. K
. W
EL
TY
, C
.; M
CG
UIN
NE
SS
, D
. L
. O
WL
Web
On
tolo
gy L
an
gu
age
Gu
ide. 200
4
SO
LM
S,
F. T
ech
nolo
gy
neu
tra
l b
usi
nes
s p
roce
ss d
esig
n u
sin
g U
RD
AD
. 2007
111
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
SO
LM
S,
F.;
LO
UB
SE
R, D
. G
ener
ati
ng M
DA
’s p
latf
orm
in
dep
end
ent
mod
el u
sin
g U
RD
AD
.
2009
ST
RO
NG
, O
. C
HIA
NG
, C
. C
. K
IM, H
. K
. K
AN
G,
B.;
LE
E,
R.
Layer
ing M
DA
: A
pp
lyin
g
Tra
nsp
are
nt
La
yer
s of
Kn
ow
led
ge
to P
latf
orm
In
dep
end
ent
Mod
els.
2009
VA
LL
EC
ILL
O, A
. R
M-O
DP
: T
he
ISO
Ref
eren
ce M
od
el f
or
Op
en D
istr
ibu
ted
Pro
cess
ing.
199
9
VA
LV
ER
DE
, F
. P
AN
AC
H, I.
; P
AS
TO
R,
O.
An
ab
stra
ct i
nte
ract
ion
mod
el f
or
a M
DA
soft
ware
pro
du
ctio
n m
eth
od
. 2
007
VID
AL
ES
, M
. A
. S
. G
AR
CIA
, A
. M
. F
.; A
GU
ILA
R,
L.
J. A
new
MD
A a
pp
roach
base
d o
n B
PM
an
d S
OA
to i
mp
rove
soft
wa
re d
evel
op
men
t p
roce
ss.
2008
ZE
PE
DA
, L
. C
EC
EÑ
A, E
. Q
UIN
TE
RO
, R
. et
al.
A M
DA
Tool
for
Data
Ware
hou
se.
2010
ZH
AN
G,
JIA
NF
U;
FE
NG
, P
. W
U, Z
. Y
U,
D.;
CH
EN
, K
. E
. N
. A
ctiv
ity b
ase
d C
IM m
od
elin
g a
nd
tran
sform
ati
on
fo
r b
usi
nes
s p
roce
ss s
yst
ems.
2010
ZH
AN
G,
JIN
GJU
N;
CH
EN
, Y
UE
JUA
N.
Asp
ect-
ori
ente
d m
od
elin
g a
nd
map
pin
g d
riven
by
Mod
el D
riven
Arc
hit
ectu
re.
20
09
112
PIM
PS
M
MA
P
DE
MO
DE
LO
PIM
CIM
PIM
CIM
NO
ME
ZH
U,
L.
BU
I, N
. L
IU, Y
; G
OR
TO
N, I.
MD
AB
ench
: C
ust
om
ized
ben
chm
ark
gen
erati
on
usi
ng
MD
A.
200
5
113