Model-Driven Engineering - MDE

Uma Breve Explanacao

Emerson Mendes Portela Costa1 , Francisco Jose Rego Lopes1 , Nadia Rafaela Costa1
1
Universidade Estadual do Ceara (UECE)

{pos.nrafaela,lopespaz,emersonportela}@gmail.com

1. Introducao
Model-Driven Engineering (Engenharia Dirigida por Modelos - MDE) esta concentrada
na utilizacao sistematica de modelos como o artefato primario da Engenharia. Esta abor-
dagem considera os modelos nao apenas como artefatos de documentacao mas, sendo seu
principal elemento, podem ser usados atraves de todas as disciplinas da Engenharia, em
qualquer domnio de aplicacao.
Os principais objetivos de MDE estao calcados na melhoria da qualidade do
software, reducao da complexidade e melhoria no reuso, atraves da concentracao do
trabalho dos desenvolvedores em um nvel mais alto de abstracao, ignorando detalhes
desnecessarios. Alem disso tambem sao apontadas melhorias na produtividade, com
menor tempo sendo despedindo para desenvolvimento do software.
MDE e melhor classificada como um paradigma de engenharia de software nao
tendo, portanto, qualquer suporte de ferramentas concretas. Silva [Silva 2015] propoe
uma classificacao hierarquica das abordagens dirigidas a modelo, iniciando no nvel mais
abstrato com MDE e descendo aos nveis concretos, como Model-Driven Test (Testes
Dirigidos por Modelos - MDT), Model-Driven Development (Desenvolvimento Dirigido
por Modelos - MDD), e assim por diante, conforme a Figura 1.
MDD tem seu foco principal nas disciplinas de requisitos, analise e
implementacao. MDT centra sua atencao na disciplina de automacao de testes, com mod-
elos de teste sendo utilizados para representar o comportamento esperado de um sistema,
estrategias e ambientes de teste.
Model-Driven Architecture (Arquitetura Dirigida por Modelos - MDA) e a abor-
dagem proposta pelo Object Management Group (OMG). Seu foco principal esta con-
centrado na definicao de modelos e suas transformacoes, dando suporte a modelagem em
diferentes nveis de abstracao. Embora nao seja uma abordagem concreta, ja que nao es-
pecifica linguagens concretas de modelagem e ferramentas associadas, MDA defende o
uso de varias especificacoes concretas, definidas pelo proprio OMG.

1.1. Principais Conceitos

MDE utiliza uma terminologia peculiar e, sendo assim, seguem algumas definicoes dos
principais conceitos utilizados.
Modelo: um modelo e uma abstracao que e muitas vezes utilizada para substituir
um sistema sob estudo. Em geral, um modelo representa uma visao parcial e
simplificada de um sistema. Normalmente e necessaria a criacao de multiplos
Figure 1. Hierarquia MDE. Fonte: [Silva 2015]
 modelos que abstraem um domnio, para que este possa ser bem representado
e compreendido. Modelos permitem o compartilhamento de conhecimento e
visao comum entre interessados de perfil tecnico e nao tecnico, facilitando e
promovendo e facilitando a comunicacao entre eles.

Metamodelo: e um modelo que define a estrutura de uma linguagem de mode-

lagem.

Linguagem de modelagem: e o conjunto de todos os possveis modelos que

estao em conformidade com a sintaxe abstrata das linguagens de modelagem,
representadas por uma ou mais sintaxes concretas e que satisfazem a uma dada
semantica.

Meta-metamodelo: Se um metamodelo e o modelo de uma linguagem de

modelagem, entao deve existir um metamodelo descrevendo sua linguagem de
modelagem. Pensando de forma recursiva, essa sequencia se repete atingindo
nveis mais elevados de abstracao. A solucao comum para este problema e usar
uma linguagem que, em um nvel particular de abstracao, e descrita em si propria.

Domain Specific Languages (Linguagens Especficas de Domnio - DSL): Sao

linguagens cujas notacoes e conceitos estao diretamente atreladas ao domnio
de negocio do problema que esta sendo resolvido. Modelos e DSLs sao com-
plementares. Geralmente modelos fazem representacoes graficas, com foco em
estrutura, enquanto as DSLs representacoes textuais, permitindo focar em logica
de negocio.

Transformacao (de Modelos): a representacao de um domnio de problema re-

sultara em varios modelos, de modo a capturar suas informacoes nos nveis de
abstracao adequada. Esses modelos precisam estar sincronizados e, muitas vezes,
esse processo de sincronizacao e automatizado, tomando um ou mais modelos
como entrada e produzindo um ou mais modelos como sada. A esse processo
da-se o nome transformacao.

2. Aplicacoes
O uso de cada tipo de modelo requer habilidades especficas para produzir e evoluir MDD
de forma eficaz. Aumentar o nvel de abstracao para modelos permite aos especialistas
trabalharem com abstracoes que atendem melhor as suas tarefas e competencias.
E importante observar que a inter-relacao entre varios tipos de modelos, e, es-
pecialmente, diferentes formalismos de modelagem, pode ser dificultoso para qualquer
das partes interessadas (por exemplo, casos de uso desenvolvedor, arquiteto, implemen-
tador, tester) no sentido de entender o impacto de uma proposta de mudanca em todos os
artefatos relacionados.
O desenvolvimento MDD nao pode confiar em equipes pequenas e unidas como,
por exemplo, offshore outsourcing e desenvolvimento de codigo aberto. O desenvolvi-
mento distribudo de equipes e criado de modo que diferentes nveis de especializacao
pode ser explorada com base em conjuntos de habilidades em diferentes locais de de-
senvolvimento, tais como os designers de exigencia que consultam diretamente com
um cliente, arquitetos que criam projetos comuns a serem utilizados ao longo uma
organizacao, programadores em um back-office e testadores que pode estar em uma
quarta localizacao. Dessa forma acontece a ausencia de interacoes imprescindveis, tal
qual comunicacoes face-a-face,
Diferentes modelos MDD podem auxiliar na comunicacao entre estas diferentes
subequipes, mas tambem implica que diferentes subequipes podem nao ser especialista
em apenas seu proprio desenvolvimento. Dessa forma, artefatos resultante a partir de
qualquer fase do ciclo de vida pode impactar aqueles produzido em qualquer outra fase.
O conhecimento das diferentes tecnologias e terminologias deve existir no modelo para
cada ambiente.

3. Desafios
Embora MDE venha crescendo e se tornando mais conhecida, e uma abordagem que ainda
tem desafios a serem enfrentados:

Nvel de abstracao: Sendo um de seus objetivos primarios a busca por desenvolver

um sistema com base em modelos, apresenta-se o desafio de fazer o balancea-
mento entre o aumento do nvel de abstracao e o excesso de simplificacao. O
nvel de abstracao da modelagem nao pode ser tao elevado que impeca que os
modelos tenham os detalhes necessarios para que sejam uteis e cumpram o seu
proposito.

Redundancia: Em MDE, um sistema e definido utilizando varios tipos de

modelos, cada um provendo uma visao ou nvel de abstracao diferente. Isso pode
levar a situacao de existir um conceito que esta definido em mais de um modelo,
ocasionando redundancia e gerando a necessidade de manutencao dos modelos
atualizados.

Ida e volta (round-trip problem): Alteracoes feitas em partes dos modelos podem
impactar em outras partes do proprio modelo ou ainda no codigo gerado, por
exemplo. O contrario tambem pode ocorrer, com alteracoes no codigo fonte
gerado precisando ser refletidas nos modelos. Alem do custo embutido, falhas na
identificacao e tratamento desses impactos podem trazer problemas ao software.

Modularidade: As linguagens de modelagem ainda possuem a necessidade de

melhoria em termos de modularidade. Normalmente essas linguagens tem esse
aspecto realizado de forma limitada. Por exemplo, todo o modelo desenhado em
um unico diagrama. O desafio e que as linguagens possibilitem o desenvolvi-
mento de modelos como componentes independentes que possam ser integrados
em diferentes composicoes.

Expertise da equipe: Como o sistema sera fatiado em varias representacoes

atraves de modelos diferentes, e possvel ter uma compartimentalizacao da
equipe, com especialistas em determinados tipos de modelos. Isso pode trazer
 problemas, pois e possvel que aconteca de, por exemplo, um analista de requi-
sitos realizar uma alteracao no modelo que e do seu domnio e nao saber avaliar
qual impacto isso trara em outros modelos envolvidos.

Padronizacao e interoperabilidade entre ferramentas: Embora ja existam padroes

que possam ser seguidos pelas diversas ferramentas que implementam MDE, isso
nao significa que elas podem interoperar entre si. Para o sucesso de MDE, nao
apenas deve ser possvel que as ferramentas possam trocar informacoes entre si e
ser compatveis, como suportar rastreabilidade e gestao das inconsistencias entre
os diversos modelos.

4. Surgimento e Crescimento das Ferramentas

A variedade de ferramentas que incorporam a prinipal ideia do MDE tem sido desen-
volvida e provida desde a ultima decada. Alguns deles correspondem ao desenvolvi-
mento de ferramentas em ambiente academico, como e o caso de experiencias como
GME, ProjectIT, VMTS, MetaSketch ou AtomPM. Outras ferramentas sao comerciais
como Microsoft Visual Studio visualization and Modeling SDK, Sparx Enterprise Archi-
tect, Metacase MetaEdit ou Obeo Designer.
As tecnologias que apoiam as ferramentas complexas para atender MDD sao
chamadas MD MetaToolse comumente conhecidas como Language WorkBenches. A
maioria dessas ferramentas proveem um conjunto de caractersticas que ajudam usuarios
a definir DS(M)Ls, com editores especficos, validacao de modelos e transformacao, etc.
As seguintes ferramentas sao mencionadas: Eclipse EMF, Microsoft Software
Factories, and JetBrains MPS, porem, muitas outras podem ser consideradas tao boas
quanto, como MetaEdit+, SDF/Stratego/Spoofax, xText, Obeo Designer/Sirius ou al-
gumas com propositos academicos como MIC (Model Integrated Computing) com tool
GME (Generic Modeling Environment, VMTS, MetaSketch ou AtomPM.

5. Analise Crtica
MDE apresenta-se com um novo paradigma de desenvolvimento de software que e
promissor. A despeito de ja ter quase duas decadas de existencia, ainda nao se tornou
um padrao de facto na industria. Muitos desafios ainda existem e, ate aqui, a grande
massa de desenvolvimento de software ainda esta embasada na forma de desenvolvimento
tradicional, com codificacao de codigo textual e sua compilacao/execucao.
Uma reflexao importante e levantada por [Hailpern and Tarr 2006]: MDE esta
realmente reduzindo a complexidade do desenvolvimento de software ou simplesmente
mudando-a de lugar? Fases iniciais de desenvolvimento sao mais simples mas as fases
subsequentes podem ser muito mais complexas, tornando impossveis (ou proibitivamente
caras) a manutencao, debug ou alteracao dos artefatos no futuro.
A despeito dessa argumentacao, o campo de pesquisa para MDE ainda e vasto e
apresenta varias possibilidades e caminhos para aqueles que desejam enveredar por esse
(nao tao) novo paradigma.
References
Hailpern, B. and Tarr, P. (2006). Model-driven development: The good, the bad, and the
ugly. IBM systems journal, 45(3):451.
Silva, A. R. d. (2015). Model-driven engineering: A survey supported by the unified
conceptual model. Computer Languages, Systems & Structures, 43:139155.
Van Deursen, A., Visser, E., and Warmer, J. (2007). Model-driven software evolution:
A research agenda. Technical report, Delft University of Technology, Software Engi-
neering Research Group.