Você está na página 1de 27

1

Captulo

4
Desenvolvimento de Software Dirigido a Modelos
Almir Buarque1
O objetivo deste captulo apresentar o processo de desenvolvimento de software
dirigido a modelos (MDD2), padronizado pela Arquitetura Dirigida a Modelos (MDA3)
proposta pela OMG4, sua relevncia para a melhoria da qualidade do processo de
engenharia de software e, consequentemente, do produto. Duas abordagens MDD sero
descritas: OO-Method e AndroMDA. O captulo mencionar ainda os problemas e
desafios atuais do processo de desenvolvimento dirigido a modelos. Ser apresentada
mais detalhadamente, a abordagem OO-Method por ser uma referncia na literatura
MDD, ter preciso e definio semntica baseada na linguagem formal orientada a
objetos chamada OASIS, e por ser totalmente suportada pela ferramenta OlivaNova da
Care Technologies [OlivaNova 2009].

4.1. Introduo
Dentro do contexto de que modelar uma atividade essencial da engenharia de
software, o MDD representa atualmente um papel central no processo de engenharia de
software. Convm lembrar que essa idia no nova. Desde a dcada de 1970, que os
mtodos formais difundiram o desenvolvimento de software a partir de modelos formais
matemticos que eram transformados at se gerar o cdigo fonte final do sistema. A
partir de um desenvolvimento formal possvel elevar a qualidade do software com
tcnicas formais de validao e verificao.
Com o amadurecimento das linguagens de modelagem de software e a
complexidade da conjuntura atual da indstria de software, cada vez mais, essa idia
tem se consolidado atravs de abordagens que adotam MDD como um padro de
desenvolvimento. Em 2001, ao especificar a MDA, o grupo OMG, na verdade, definiu
apenas uma nova instncia de processo de desenvolvimento de software dirigido a
modelos que j existia h anos.
Os principais argumentos para a utilizao de um processo de desenvolvimento
de software dirigido a modelos so os seguintes: maior produtividade, portabilidade,
1
2
3
4

almirbuarque@gmail.com
Do ingls Model Driven Software Development
Do ingls Model Driven Architecture
Do ingls Object Management Group site: www.omg.org

interoperabilidade, menor custo, mais facilidade na evoluo do software, enfim, maior


qualidade do produto. Esses benefcios so evidenciados, por exemplo, num estudo
[MDA 2003] que comparou uma produo de software usando-se a tecnologia MDD
com o mesmo software desenvolvido com tecnologia Orientada a Objetos (OO)
tradicional. Isso ocorre principalmente pelas seguintes razes:

A principal ideia em MDD a transformao de modelos de maiores nveis de


abstrao (domnio do problema) em modelos mais concretos (domnio da
soluo) at se obter, por fim, o cdigo do sistema.

O paradigma MDD preconiza que o desenvolvimento inicial e modificaes


futuras da aplicao sejam efetuados apenas no modelo mais abstrato.

Em processos MDD automatizados, o modelo abstrato do sistema deve


representar com preciso o cdigo, ou seja, ele deve ser executvel e ter uma
equivalncia funcional com todos os outros modelos mais concretos. Dessa forma, as
modificaes no modelo de mais alto nvel de abstrao so refletidas automaticamente
nos modelos de mais baixo nvel, tornando a atividade de modelar no nvel mais
abstrato o centro de todo processo de desenvolvimento do software e dispensando
completamente, nos melhores ambientes MDD, a execuo de atividades manuais nos
modelos de mais baixos nveis de abstrao (projeto e implementao).
Entretanto, a indstria de software e empresas de ferramentas CASE5 tm
exagerado nesses benefcios, transmitindo a falsa ideia aos desenvolvedores de que, em
MDD, apenas com um click ou passo de mgica, obtm-se todas as transformaes de
modelos at se chegar ao produto final de software. Alm disso, passa-se a ideia de que
gerar cdigo o principal objetivo do MDD quando, de fato, o principal objetivo
transformar modelos Assim, muitos desenvolvedores tm sido iludidos com vrias
ferramentas/ambientes CASE que geram cdigos fontes a partir de tcnicas diversas e
que, na verdade, no transformam modelos conforme o que prega a arquitetura MDA.
Ademais, existem ainda problemas semnticos, complexidades e imprecises
(ambiguidades) inerentes aos modelos atuais que tornam esse processo de
transformao e mapeamentos de modelos uma tarefa rdua e propensa a falhas.
Por outro lado, no h um consenso na comunidade acadmica sobre qual
modelo de maior nvel de abstrao mais adequado (necessrio e suficiente) para se
modelar um sistema, dificultando-se padronizaes, interoperabilidade e produzindo-se
ambientes MDD que no so integrados com modelos em nvel de requisitos, os quais
so essenciais para todo o processo de Engenharia de Software. Este captulo abordar
todos esses tpicos referentes ao processo de desenvolvimento de software dirigido a
modelos, mas precisamente sobre a arquitetura MDA.

4.2. Arquitetura Dirigida a Modelos


Nesta seo, ser apresentada uma viso geral dos padres OMG, arquitetura MDA e
seus conceitos bsicos, com o objetivo de explorar a teoria bsica sobre o processo de
desenvolvimento de software orientado a modelos. Ser dado um foco maior sobre a
transformao de modelos a partir de metamodelos, pois, segundo a arquitetura MDA
essa tcnica facilita a automao do processo ao se utilizar tecnologias de

Engenharia de Software Auxiliada por Computador. Do ingls Computer Aided Software Engineering

transformaes modelo-modelo tais como ATL [Eclipse ATL documentation 2009] ou


QVT [OMG: QVT specification 2009].
4.2.1. Conceitos Bsicos
Para um melhor entendimento da arquitetura dirigida a modelos, o padro MDA [OMG
2003] define os seguintes conceitos:

Modelo
Um modelo de um sistema a sua representao (especificao) funcional,
estrutural e comportamental. Uma especificao dita como formal quando
baseada em uma linguagem que tem uma sintaxe e semntica bem definida e,
possivelmente, regras de anlise, inferncia ou prova de seus elementos. Essa
sintaxe pode ser grfica (visual) ou textual. A semntica pode ter um formalismo
(lgica formal) maior ou menor.

Dirigido a Modelos
MDA uma abordagem de desenvolvimento de sistema que usa o poder dos
modelos. dirigida a modelos porque prov meios de usar modelos para
direcionar o curso de entendimento, projeto, construo, distribuio, operao,
manuteno e modificao.

Arquitetura
Arquitetura de um sistema a especificao de suas partes e conectores, alm
das regras de interao dessas partes usando os conectores.

Ponto de vista
Um ponto de vista (viewpoint) de um sistema uma tcnica de abstrao, usando
um conjunto selecionado de conceitos arquiteturais e regras de estruturao que
visa focar ou representar um aspecto (caracterstica) dentro desse sistema. O
termo abstrao usado para significar o processo de suprimir (esconder) um
detalhe selecionado para estabelecer um modelo simplificado.

Plataforma
Uma plataforma um conjunto de subsistemas e tecnologias que prov um
conjunto coerente de funcionalidades atravs de interfaces e padres de uso
especificados, que qualquer aplicao (sistema) suportada por essa plataforma
pode usar, sem ter que conhecer os detalhes de como essa funcionalidade
provida pela plataforma implementada.

Modelos MDA
Visando separar os diferentes nveis de abstrao de um sistema de software e
promover as facilidades e benefcios preconizados pelo processo de
desenvolvimento dirigido a modelos (produtividade, interoperabilidade,
portabilidade, etc.), a arquitetura MDA especifica basicamente os trs modelos a
seguir:
3

Excludo:

Modelo Independente de Computao (CIM6)


O modelo independente de computao ou CIM uma viso do sistema a
partir de um ponto de vista independente de computao. O CIM no mostra
detalhes da estrutura dos sistemas, sendo usualmente chamado de modelo de
domnio ou modelo de negcio e utiliza, em sua especificao, um
vocabulrio familiar aos usurios do domnio (problema) em questo. Os
usurios do CIM geralmente no tm conhecimento sobre modelos ou
artefatos usados para realizar as funcionalidades definidas atravs dos
requisitos. Esse modelo foca no ambiente do sistema e nos seus requisitos,
deixando os detalhes da estrutura e processamento (computao) do sistema
escondidos aos usurios ou, at mesmo, indeterminados.
Dessa forma o CIM tem um papel importante de fazer a ponte
(reduzir a lacuna) entre aqueles que so especialistas no domnio do
problema e seus requisitos, e aqueles que so especialistas em projeto
(arquitetura) e construo dos artefatos que juntos vo satisfazer aos
requisitos do domnio, elicitados pelos usurios.
O CIM obtido no processo de documentao e especificao dos
requisitos, ou seja, ao se especificar um modelo de requisitos para o sistema.
Outra forma tambm de definio do CIM atravs do modelo de negcios
do sistema.

Modelo Independente de Plataforma (PIM7)


O modelo independente de plataforma ou PIM foca na operao do sistema
(modelo computacional), escondendo os detalhes necessrios para implantar
esse modelo numa plataforma especfica. O PIM nico para o sistema e
no muda quando se varia de uma plataforma para outra, permitindo assim,
portabilidade. Esse ponto de vista independente de plataforma pode ser
especificado usando-se uma linguagem de modelagem de propsito geral
(UML - Unified Modeling Language) ou uma linguagem especfica (OOMethod) como ser visto na seo 4.3.1. O PIM um modelo conceitual do
sistema.

Modelo Especfico de Plataforma (PSM8)


O modelo especfico de plataforma ou PSM uma viso do sistema que
agrega caractersticas e elementos constituintes de uma plataforma
especfica, contendo informaes da tecnologia utilizada na aplicao, bem
como a linguagem de programao, os componentes de middleware, e a
arquitetura de hardware e de software. Para que isso seja possvel,
necessrio o suporte de ferramentas que faam o mapeamento adequado de
uma especificao abstrata (PIM) para uma determinada plataforma. O
PSM, por sua vez, passa por processo(s) de refinamento(s) para obteno do

6
7
8

Do ingls Computation Independent Model


Do ingls Platform Independent Model
Do ingls Platform Specific Model

nvel de especificao desejado. A obteno desse nvel torna possvel a


transformao do mesmo no cdigo (implementao) da aplicao. O
modelo PSM o responsvel por lidar com toda heterogeneidade e
complexidade dos diversos tipos de plataformas existentes.

Transformaes (Mapeamentos)
A fora motriz do padro MDA a transformao de modelos, que pode ser
realizada entre modelos de um mesmo ponto de vista ou entre modelos de pontos
de vistas diferentes, tanto num sentido direto (de maior nvel de abstrao para
menor nvel de abstrao) quanto no sentido inverso. Em qualquer caso, sempre
um modelo usado como parmetro de entrada para ser transformado em outro
modelo.
A Figura 4.1 mostra o ciclo (sentido) mais natural do MDA, partindo do
CIM (modelo de requisitos) at o nvel mais baixo de cdigo (implementao).

Figura 4.1. Transformaes em MDA [Adaptada de Hitachi 2002]

Entretanto, so possveis tambm as seguintes transformaes (mapeamentos):


o
o
o
o

PSM => PIM (Engenharia Reversa)


PIM => PIM, PSM => PSM (Modelos de mesmo nvel)
Implementao => PSM (Engenharia Reversa)
PIM => Implementao
5

Transformaes e Mapeamentos em MDA


Existe uma quantidade enorme de ferramentas para suportar transformao de
modelos. Transformaes podem utilizar diferentes tcnicas que vo desde uma
transformao manual at as automatizadas, passando pelas semi-automticas.
Por exemplo, transformaes de PIM para PSM podem ser realizadas atravs do
uso de UML Profiles (extenses de UML), uso de padres (patterns), marcas
(markings), metamodelos (metamodels - modelos que descrevem e especificam
os modelos originais) e transformaes automticas (via algoritmos) [MDA
Guide Version 2003]. A seguir, ser descrito como as tcnicas de
metamodelagem e UML Profile so usadas. As outras tcnicas mencionadas
esto detalhadas na referncia bibliogrfica citada Os elementos centrais dessas
transformaes so os mapeamentos dos modelos. Segundo a arquitetura MDA,
um mapeamento um conjunto de regras e tcnicas utilizadas para modificar,
refinar ou transformar um modelo e obter outro modelo.
A Figura 4.2 descreve o Metamodelo MDA [MDA 2001]. Basicamente
os modelos PIM e PSM so descritos atravs de seus metamodelos expressos
preferencialmente com as tecnologias ncleo do OMG: UML, MOF (Meta
Object Facility) ou CWM (Common Warehouse Metamodel). Depois, a partir
das vrias regras de transformaes entre os elementos desses metamodelos,
tcnicas de mapeamento so utilizadas para implementar a transformao.

Figura 4.2 Metamodelo MDA [Adaptada de MDA 2001]

Para ilustrar o esquema geral de transformaes atravs de metamodelos,


considere a Figura 4.3, onde se tem como entrada um modelo 1, instncia do
metamodelo A, que transformado num modelo 2, instncia do metamodelo B.
importante destacar que para realizar essa transformao necessrio ter
primeiramente os metamodelos especificados em algum padro, por exemplo,
MOF e implementao das regras de mapeamento entre esses metamodelos
atravs de alguma linguagem de transformao modelo-modelo (ATL ou QVT).
6

Figura 4.3. Transformaes de mapeamentos por metamodelos


[Adaptada de MDA Guide Version 2003]

A Linguagem de Modelagem Unificada (UML) um marco na histria de modelagem


visual de software, pois antes dela havia vrias notaes, at mesmo incompatveis entre
si. Desde a sua primeira verso (UML 1.0) lanada em 1997, a linguagem de
modelagem unificada recebeu diversas crticas e propostas de extenso. Em 2001, o
OMG publicou a UML 2.0. Alguns dos novos aperfeioamentos da UML 2.0 foram:

Melhor suporte de extenso para outros modelos (linguagens) atravs do uso de


UML Profiles;
Aperfeioamento da expressividade de modelar, incluindo modelagem de
processos de negcios, suporte modelagem de classificadores reusveis
(metaclasses que representam elementos UML que podem ter suas propriedades
ou mtodos compartilhados por outros elementos UML ou generalizados) e
tambm suporte modelagem de arquiteturas distribudas e sistemas
heterogneos;
Integrao com Semntica de Aes (Actions Semantics) que o desenvolvedor
pode usar para definir a semntica de tempo de execuo do modelo (aspecto
funcional) e prover preciso semntica exigida para analisar modelos e
transform-los em implementaes.

Robert B. France em Desenvolvimento orientado a Modelos usando UML 2.0:


Promessas e Armadilhas (Model-Driven Development Using UML 2.0: Promises and
Pitfalls) [France & Ghosh 2006] cita que o padro UML 2.0 contm um largo conjunto
de conceitos de modelagem que so relacionados de um modo complexo em termos
estruturais. Para cobrir essa complexidade seus projetistas organizaram o padro UML
2.0 em quatro partes:

Infraestrutura: elementos ou construtores bsicos da linguagem.


Super-estrutura: o prprio metamodelo UML.
Linguagem de Restrio de Objeto (OCL): especificao de consultas,
invariantes (de estado), pr-condies, ps-condies, restries e operaes em
modelos UML.
Intercmbio de Diagramas: extenso do metamodelo (Super-estrutura) para dar
suporte ao armazenamento e intercmbio de informao de modelos UML.

No entanto, UML carece de preciso semntica, pois muitos dos seus elementos
(primitivas) tm diferentes interpretaes que variam conforme entendimento do
projetista, causando muitas ambigidades [France & Ghosh 2006]. Oscar Pastor [Pastor
& Molina 2007] afirma que a maioria das ferramentas CASE baseadas em UML no
realizam o processo de transformao de modelos de modo completo e correto. Isso
porque UML tem conceitos to ambguos como generalizao, associao, agregao e
composio; e dependentes da interpretao subjetiva do projetista que o resultado em
termos do produto de software imprevisvel. Assim, por exemplo, diferentes
projetistas podem especificar que um relacionamento entre classes em UML seja uma
associao, uma agregao ou uma herana e, para cada um desses tipos de
relacionamento, pode-se ter implementaes do sistema completamente diferentes. Isso
ocorre porque os conceitos de relacionamentos de classes em UML no so precisos e
claramente definidos, dando margem a mltiplas interpretaes.
Essa impreciso, aliada ausncia de formalismo do metamodelo UML, faz com
que sua validao fique comprometida, e como consequncia, erros e inconsistncias
sejam propagados, durante o refinamento desses elementos, para os nveis de menor
abstrao da UML [Pastor & Molina 2007]. Para dar um melhor suporte MDD, UML
2.0 lanou o conceito de UML Profile. Esse mecanismo de extenso auxilia a
transformao de modelos PIM para PSM especficos, conforme esquema ilustrado na
Figura 4.4. Como se observa a partir do projeto do sistema (modelo PIM), uma
determinada ferramenta CASE MDD pode permitir que seja selecionado o UML Profile
que estenda e transforme esse modelo de projeto num modelo de plataforma especfica
(PSM) desejado, por exemplo, EJB ou .NET . Obtendo-se esse modelo PSM especfico,
h finalmente uma nova transformao para gerar o cdigo do sistema numa linguagem
de programao suportada pela plataforma. Dessa forma, os modelos PIM (ou CIM se
exitir) ficam independentes e isolados dos detalhes e mudanas que venham a ocorrer
nos modelos de mais baixos nveis (PSM e Implementao). A portabilidade
alcanada, pois se pode gerar modelos PSM qualquer que seja a plataforma suportada
pelo ambiente CASE MDD.

Requisitos

Perfil UML XX
--------------------------------Padres do modelo
Regras de mapeamento

Anlise

Perfis UML
Dependente de
Plataforma

Perfil UML YY
--------------------------------Padres do modelo
Regras de mapeamento

Seleciona Perfis

Projeto de
Sistema

Regras de Gerao
de Cdigo, etc.

Modelo
PIM
PSM
Mapeamento

Ferramentas

Gerao de cdigo

Cdigo de
Implementao
Do Sistema
Frameworks

Figura 4.4. Transformaes com UML Profile [Adaptada de Hitachi 2002]

Atualmente muitas extenses j esto padronizadas pela OMG, algumas esto em


processo de padronizao e outras ainda esto em discusso [MDA profile catalog
2010] como mostrado na Figura 4.5.

10

Figura 4.5. Perfis UML da OMG [Adaptada de Hitachi 2002]

Assim, devido sua impreciso semntica e complexidade, UML 2.0 torna-se um


problema no somente para desenvolvedores de ferramentas MDD, mas tambm para os
prprios projetistas (grupos de trabalho) da OMG na evoluo do padro UML [France
& Ghosh 2006]. Isso no significa subestimar o valor inegvel da UML no contexto da
Engenharia de Software, entretanto, afirmar que UML vai ser mesmo o futuro do
desenvolvimento de software dirigido a modelos s o tempo dir.
4.2.2. Padres OMG e a Arquitetura MDA
O surgimento da arquitetura MDA em 2001 foi resultado da necessidade cada vez mais
emergente de realizar manutenes em aplicaes, integr-las com outros sistemas,
mudar suas infraestruturas, alterar seus requisitos e lidar com a frequente evoluo e
criao de novas tecnologias. MDA visa tambm proporcionar os seguintes benefcios:
aumentar a produtividade no desenvolvimento de sistemas, bem como melhorar a
portabilidade e a interoperabilidade dos sistemas.
Para atingir esses objetivos e separar os nveis de abstraes, MDA [OMG 2003]
foi definida pela OMG em trs camadas conforme Figura 4.6.
A primeira camada de especificao (ncleo da arquitetura) representa o modelo
PIM e possui os seguintes padres que ditam um conjunto de regras para estruturao
da especificao expressa nos modelos, e que no abordam caractersticas de
plataformas especficas:

Linguagem de Modelagem Unificada (UML): padro que define uma linguagem


de modelagem geral orientada a objetos para especificao, construo e
documentao de artefatos de sistemas de software complexos;

Metamodelo Comum de Armazenamento (CWM): padro para armazenamento


de dados que permite fcil manipulao dos mesmos entre ferramentas e
plataformas de armazenamento em ambientes heterogneos distribudos;

Servio/Facilidade de Meta-Objeto (MOF): padro que define uma linguagem


abstrata para definio de linguagens de modelagem (metamodelos). Esta
linguagem utilizada para descrever modelos da UML, CWM e o prprio MOF,
alm de definir o formato de intercmbio para modelos, base do padro XMI
(XML Metadata Interchange);
10

11

Na segunda camada, encontram-se os modelos PSM que possuem caractersticas


inerentes a determinadas tecnologias e plataformas. Essas plataformas e tecnologias
seguem padronizao da OMG, elevando a resoluo dos problemas de integrao
atravs da definio de especificaes voltadas para interoperabilidade que sejam
abertas e independentes de fornecedores ou fabricantes especficos:

Intercmbio de Metadados em XML (XMI): padro para o intercmbio de


modelos atravs do mapeamento da linguagem definida pelo padro MOF para o
padro XML do World Wide Web Consortium (W3C);

Arquitetura CORBA: arquitetura que padroniza e simplifica a troca de dados


entre sistemas distribudos.

Na camada PSM, pode-se ter tambm outros padres de arquitetura como JAVA
EJB/JEE, Microsoft.NET, etc.
Na camada mais externa, segundo a Figura 4.6, so exibidos os servios que a
maioria dos domnios de aplicaes necessita, para ento, serem apresentados os
mltiplos domnios que fazem uso desses servios. Esses servios podem ser de
segurana, persistncia, controle de transaes, tratamentos de eventos, etc.

Figura 4.6. Padres MDA [Adaptada de OMG 2003]

4.3 Abordagens MDD


Esta seo tem como principal objetivo descrever as seguintes abordagens MDD: OOMethod, que apresenta caractersticas de um real ambiente MDD atravs de uma

11

12

completa transformao de modelos; e AndroMDA que est se tornando bastante


popular.
4.3.1. OO-Method
O OO-Method inova com o conceito de compilador de modelos que, de fato, uma
mquina virtual de transformao de modelos. Alm disso, o modelo de alto nvel,
chamado modelo conceitual, tem todos seus elementos (primitivas) descritos numa
notao visual (grfica) e so especificados numa linguagem formal orientada a objeto
(OASIS). Essas caractersticas fazem com que o OO-Method tenha preciso sinttica e
semntica suficientes para prover um ambiente capaz, inclusive, de fazer validao de
modelos e consequentemente gerar um produto de software final de qualidade.
A primeira verso do OO-Method foi introduzida em 1992, atravs da tese de
doutorado de Oscar Pastor juntamente com a linguagem formal de especificao de
sistemas de informao OASIS [Pastor & Molina 2007]. Deste ento, o mtodo
incorporou vrios componentes at chegar verso apresentada neste captulo.
Segundo o seu criador, o mtodo cobre todas as fases do processo de desenvolvimento
de software, desde as fases iniciais de obteno de requisitos e representao, passando
pelo desenvolvimento do esquema conceitual OO correspondente, at a gerao do
produto final de software numa plataforma especfica. O centro do desenvolvimento do
software dirigido a modelos do OO-Method o Esquema (Modelo) Conceitual
fundamentado a partir da seguinte afirmao do Prof. Antoni Oliv [Pastor & Molina
2007]:
Para desenvolver um sistema de informao necessrio e suficiente definir seu
esquema conceitual
Esta ideia tambm aparece em trabalhos e propostas de outros pesquisadores de
prestgio. Toni Morgan defende a ideia de usar Programao no Extrema (Extreme
Non-Programing) [Morgan 2002] em oposio metodologia gil XP, argumentando
que a principal atividade no desenvolvimento de software modelagem, e no
programao, pois modelagem est no espao do problema enquanto programar est no
espao da soluo. O objetivo final tornar verdadeira a sentena O Modelo o
Cdigo, em vez de O Cdigo o Modelo. Tudo isso possvel de se obter quando se
tem um Modelo Conceitual Executvel que abstrai de modo completo e consistente
todos os aspectos estticos, dinmicos e de interao (interface usurio) de um sistema,
tal como o modelo conceitual do OO-Mtodo, passvel de transformao atravs de um
compilador de Esquema Conceitual.
O processo bsico de transformao
OO-Method estabelece uma distino clara entre o espao do problema, onde est
definido o esquema conceitual e o espao da soluo, onde obtido o produto de
software representado pelo esquema conceitual. Na figura 4.7, o processo inicia com
uma entrada que representa os requisitos do sistema, no importando por quais
processos de engenharia de requisitos eles foram obtidos, nem o modelo de requisitos
utilizado. De forma que esses requisitos so insumos para se criar (projetar) o esquema
conceitual. Especificados os quatro modelos que compem o esquema conceitual:
modelo objeto, funcional, dinmico e de apresentao, gerado um repositrio para
12

13

conter todos os elementos (primitivas) especificados nos modelos desse esquema


conceitual, utilizando-se a linguagem formal orientada objetos OASIS, conforme figura
4.7.
Regras de mapeamentos das primitivas desse esquema conceitual para um
modelo de aplicao especfico de cada plataforma so definidas e, por fim, realizada
uma transformao automtica desse modelo de aplicao para o cdigo da aplicao
correspondente plataforma (modelo de aplicao) escolhida.
O processo garante que h uma equivalncia funcional entre toda primitiva
definida no esquema conceitual com sua(s) respectiva(s) primitiva(s) no modelo de
aplicao. No exemplo da figura 4.7, foi escolhido um modelo de aplicao
(plataforma) constitudo por uma arquitetura de trs camadas: lgica da aplicao,
persistncia e interface com usurio.

Figura 4.7. Abordagem OO-Method [Adaptada de Pastor & Molina 2007]

Comparao com MDA


Os modelos do OO-Method, seus mapeamentos e transformaes podem ser
comparados com o padro MDA, como ilustrado atravs da tabela 4.1.
Tabela 4.1. Comparao do OO-Method com MDA [Adaptada de Pastor & Molina 2007]

MDA
Modelo Independente de Plataforma (PIM)
Modelo Especfico de Plataforma (PSM)
Modelo de Implementao (IM)
Transformao PIM para PSM
Transformao PSM para IM

OO-Method
Modelo Conceitual
Modelo de Aplicao
Cdigo de Aplicao
Mapeamentos
Transformaes
13

14

Entretanto, algumas propriedades do OO-Method esto ausentes no padro MDA


(OMG), tais como:

O processo de compilao de modelos que, de fato, compila um modelo fonte


(entrada) em outro modelo destino (sada) a partir de regras de mapeamentos
precisas, o qual implementado atravs de uma mquina virtual de compilao
de modelos onde se realiza uma verdadeira transformao desses modelos.
Em termos de PIM, OO-Method prov uma soluo semanticamente precisa,
porque est especificado usando uma linguagem formal OASIS que
computacionalmente completa. Em outras palavras, os modelos do esquema
conceitual do OO-Method so tambm computacionalmente completos e contm
toda a informao que necessria para gerar automaticamente cdigo-fonte.

O Modelo Conceitual
O modelo ou esquema conceitual composto por quatro vises ou modelos: modelo
objeto, modelo dinmico, modelo funcional e modelo de apresentao.
O Modelo Conceitual do OO-Method utiliza uma notao visual (grfica)
similar a UML, formada apenas por conceitos (diagramas) necessrios e suficientes para
representar um sistema de informao. Alm disso, a grande diferena, quando
comparado com UML, que o modelo conceitual do OO-Method tem uma semntica e
sintaxe bem precisas e baseadas na linguagem formal OASIS. Isso propicia a validao
automtica do modelo conceitual a fim de no deixar passar falhas (erros) para os
modelos posteriores de mais baixos nveis.
A seguir sero apresentadas, de modo geral, as principais caractersticas desses
modelos. Maiores detalhes podem ser encontrados em [Pastor & Molina 2007].

Modelo Objeto

Este modelo especifica as propriedades estticas do sistema, definido pelo diagrama de


configurao de Classe que composto por:
o Classes
 Atributos
 Precondies e Servios
 Restries de Integridade
o Relacionamento entre as Classes
 Associao, Agregao e Composio
 Herana
o Agentes
O OO-Method representa precisamente os relacionamentos dos seguintes tipos:
associao, agregao e composio. A associao considera aspectos de cardinalidade,
papis e tambm de temporalidade. A temporalidade de uma associao se define como
esttica ou dinmica. esttica quando os objetos associados no mudam durante o
tempo. dinmica quando as instncias associadas mudam com o tempo durante o ciclo
de vida dos objetos que participam do relacionamento.

14

15

A agregao um tipo de associao mais restrita onde uma das classes o todo
e a outra representa a parte do todo (objetos agregados ao todo), significando que uma
das classes constituda ou formada por um conjunto de outros objetos agregados.
Como exemplo de relacionamento de agregao, pode-se definir as classes Caixa e
Bombons.
A composio um tipo mais forte de agregao onde a parte e o todo esto
vitalmente associados, ou seja, para um objeto-todo existir os demais objetos-parte
tambm devem existir. Como exemplo de composio pode-se definir as classes Corpo
Humano e Orgo. Obviamente, a classificao de um relacionamento em associao,
agregao ou composio depende de como o analista interpreta as classes de acordo
com um determinado contexto.
Alm da preciso que o OO-Method trata os conceitos de associao, agregao
e composio, ele tambm considera quais so os impactos que eventos de insero,
deleo e mudana de objetos tm sobre esses relacionamentos entre as classes.
O OO-Method suporta tambm os conceitos de Herana (generalizao e
especializao) e herana mltipla; e para gerenciar a complexidade do modelo, pode-se
representar um subsistema atravs de uma notao visual igual de um pacote
(package) em UML.

Modelo Dinmico

Este modelo representa o comportamento do sistema, especificando suas propriedades


dinmicas atravs de dois diagramas:
o Diagrama de Transio de Estado: especifica o ciclo de vida vlido dos objetos
de uma classe e seus servios disponveis em cada estado.
o Diagrama de Interao de Objeto: especifica as interaes vlidas entre os
objetos atravs das transaes, operaes e gatilhos.
Um gatilho uma condio sobre um estado do objeto que, tornando-se
verdadeira, faz com que este objeto dispare eventos ou transaes sobre si mesmo (self)
ou sobre outros objetos (object) do sistema. A sintaxe de gatilhos na linguagem formal
OASIS :
<destination>::<condition>:<service>
Onde, <destination> := self | object | class | for all
E self significa para a si mesmo, object para uma instncia de outra classe, class
para todas as instncias da classe e for all para um subconjunto de objetos de uma
classe.

Modelo Funcional

Este modelo especifica o relacionamento entre os modelos objeto (que esttico) e


dinmico visto no tpico anterior. O modelo funcional consiste em:
o Definio da semntica relacionada s transies de estado

15

16

o Descrio de como a execuo dos eventos muda o valor dos atributos das
classes
O modelo funcional trata tambm eventos de criao e destruio de objetos,
alm de transaes e operaes que afetam os estados (valores dos atributos) dos
objetos. O modelo funcional do OO-Method, combinado com sua linguagem formal
prov de modo completo e preciso uma soluo para especificar os aspectos funcionais
de um sistema via modelo conceitual.
O recurso de Semntica de Aes (UML 2.0), criado para modelagem de
aspectos funcionais, no possui uma semntica definida de forma clara e precisa. O
modelo funcional do OO-Method e sua linguagem formal proveem uma soluo
adequada, permitindo:
o
o
o
o
o

Acesso a dados de acordo com o Modelo Objeto


Definio de lgica sequencial
Manipulao de classes e objetos
Manipulao de relacionamentos
Uso de operadores lgicos, aritmticos e relacionais

Modelo de Apresentao

Este modelo especifica os requisitos de Interface de Usurio, modelando uma interface


abstrata que independente de plataforma ou dispositivo. O modelo de apresentao em
nvel de anlise (conceitual) considerado uma inovao do OO-Method em relao a
outras abordagens que, na maioria das vezes, descrevem interface-usurio apenas em
nvel de implementao. No OO-Method, o modelo de apresentao organizado em
trs nveis:
o Nvel 3: Elementos Bsicos
Nvel mais baixo, constitudo pelos elementos bsicos de entrada de dados,
selees, grupos de dados, filtros, critrios de classificao, conjunto de
visualizao, aes e navegao.
o Nvel 2: Unidades de Interao
Nvel intermedirio que descreve um cenrio particular de interao entre o
usurio e o sistema. Geralmente, a interface de usurio de um sistema definida
como uma coleo de unidades de interao relevantes e pelo modo como essas
unidades esto estruturadas. O OO-Method prov quatro tipos de unidades de
interao, descritas a seguir:
 Unidade de Interao de Servio: representa um cenrio no qual o usurio
interage com o sistema para executar um servio, definindo propriedades
como: argumentos, grupos de argumentos, valores padro, ajuda e retorno
(feedback) em caso de erro de execuo do servio. Por exemplo, Para a
classe Veculo, pode ser definida uma unidade de interao de servio
chamada Comprar_Veculo, contendo todos os argumentos necessrios,
valores padro, informaes de ajuda, excees em caso de erro, etc.
 Unidade de Interao de Instncia: define um cenrio no qual apenas
informaes sobre um nico objeto so mostradas, incluindo lista de
servios, bem como cenrios de informaes relacionadas a esse objeto que
16

17

o usurio pode navegar. Um exemplo tpico quando o usurio quer


gerenciar um veculo especfico. Isso inclui exibio dos atributos do
veculo, possibilidade de navegar por informaes relacionadas como
relatrios de manuteno e os servios executados sobre o veculo (aluguel,
enviar para manuteno, etc.).
 Unidade de Interao de Populao: descreve um cenrio de interao onde
o usurio pode manipular uma coleo de objetos de uma mesma classe,
podendo definir filtros, critrios de ordem, conjunto de exibio, aes e
navegao.
 Unidade de Interao Mestre/Detalhe: descreve um cenrio para interao
com mltiplas colees de objetos pertencentes a classes diferentes, mas
relacionadas. O mestre representa o cenrio de interao principal e o
detalhe, o secundrio.
o Nvel 1: rvore de Hierarquia de Ao
Uma vez definidos os cenrios de interao do nvel 2 do modelo de
apresentao, faz-se necessrio determinar como essas unidades de interao
sero estruturadas e apresentadas ao usurio. Essa estrutura caracteriza o nvel
mais alto da interface com o usurio, o que poderia ser descrito como o Menu
principal da aplicao. A rvore de hierarquia de ao serve para esse propsito.
Ela estruturada hierarquicamente, tendo um n raiz e respectivas ramificaes
at chegar s folhas. Por exemplo, um sistema de aluguel de carros (n raiz)
pode ser organizado como tendo as seguintes ramificaes: Veculos, Clientes,
Aluguis e Usurios.
A construo do modelo de apresentao pode ser realizada de modo topdown, ou seja, partindo-se do nvel 1 at chegar aos elementos do nvel 3; ou
bottom-up, partindo-se do nvel 3 at a definio do nvel 1.
Alm dessas quatro vises do modelo conceitual, o OO-Method d suporte
interoperabilidade e interface do sistema modelado com outros sistemas externos
existentes, chamados de sistemas legados, atravs do conceito de viso de
legado.
Enfim, ao se definir os quatro modelos bsicos (objeto, dinmico, funcional e
apresentao) do esquema conceitual do OO-Method, tem-se toda infraestrutura
necessria e suficiente para representar um sistema de informao no contexto do
espao do problema.
O Compilador de Modelos
Para ser aderente ao padro de desenvolvimento MDD, OO-Method precisa de alguma
forma de transformar o modelo conceitual, que contm todas as propriedades estticas,
dinmicas e de interao com usurio (apresentao), em um modelo de implementao
(cdigo). Essa transformao automatizada atravs do Compilador de Esquema
Conceitual que pode ser visto como uma mquina virtual de programao. OO-Method
inova com essa ideia de compilador de modelos, tornando-o diferente de outras
abordagens que apenas focam na gerao de cdigo a partir de modelos utilizando
tcnicas diversas como integrao, sincronizao de cdigo, refatorao etc.
17

18

Em comparao com outras abordagens existentes, o OO-Method se destaca por


tratar de modo completo e preciso todos os aspectos da compilao de modelo. Um
exemplo tpico de problemas com outras abordagens so as transformaes insuficientes
para se obter o produto final de software. Mais grave ainda, a maioria das ferramentas
que geram cdigo a partir de modelos, considera nica e exclusivamente como seu
modelo inicial de entrada o diagrama de classes em UML, negligenciando todos os
demais diagramas que capturam os demais aspectos dinmicos e de interao de uma
aplicao.
OLIVANOVA: Uma Ferramenta de apoio ao OO-Method
A implementao do OO-Method suportada atravs da ferramenta OlivaNova da Care
Technologies [OlivaNova 2009]. O principal objetivo da OlivaNova separar o que
deve ser feito (espao do problema), de como deve ser feito (espao da soluo). Ela
composta por duas principais ferramentas: o modelador e a mquina de transformao.
O modelador permite:

Modelar objetos e negcios;


Modelar dados;
Modelar integrao;
Modelar sistemas legados;
Modelar regras e limitaes;
Definir conceitualmente interfaces do usurio;
Suporte a UML;
Suporte a XML.

A mquina de transformao que implementa todo o processo de compilao de


modelos do OO-Method, gerando cdigo fonte na plataforma destino.
4.3.2. AndroMDA
AndroMDA [AndroMDA 2009] uma abordagem MDD que utiliza UML Profiles para
transformao de modelos PIM em PSM. Essa abordagem MDD implementada por
uma ferramenta open source tambm denominada de AndroMDA.
AndroMDA utiliza como entrada modelos PIM desenhados por qualquer
ferramenta que modele em UML (nvel projeto) e que exporte esse modelo UML no
formato OMG de intercmbio (XMI). Depois disso, seleciona-se o Perfil UML
especfico para transformar esse modelo de projeto para a plataforma especfica
desejada (JAVA, .NET, etc).
Em AndroMDA possvel gerar componentes para as linguagens: Java, .Net,
HTML, PHP. Caso seja necessrio utilizar alguma tecnologia que ainda no esteja
contemplada, preciso somente desenvolver plugins, chamados pela comunidade de
cartuchos, ou alterar algum plugin j existente. AndroMDA mais comumente utilizado
por programadores da tecnologia J2EE, inclusive podendo gerar um projeto J2EE e seu
cdigo partindo de um modelo de classe. Alm disso, pode-se gerar automaticamente
cdigo para Hibernate (framework de persistncia em banco de dados de objetos Java e
.NET), Enterprise JavaBeans-EJB (principal componente da plataforma Java Enterprise
Edition), Spring (framework open source para desenvolvimento em J2EE),
WebServices (protocolo e padro para integrao de aplicaes via web) e Apache
18

19

Structs (framework open source para desenvolvimento de aplicaes web em Java


compatvel com a arquitetura MVC).
A abordagem de AndroMDA permite fazer com que o trabalho de arquitetura e
desenvolvimento seja mais curto e de melhor qualidade, trabalhando com modelos
independentes de plataforma que posteriormente sero refletidos em modelos UML
(PSM). Isto permite,entre outras vantagens, ter foco no modelo e necessidades
organizacionais (Modelo PIM) e a possibilidade de reutilizar o modelo PIM em outros
projetos.
A partir do PIM efetua-se a transformao at o cdigo fonte da aplicao, tendo
como etapas intermedirias a gerao de um ou mais modelos PSM. Neste ponto,
onde AndroMDA mais se destaca, por possuir uma grande variedade de plugins
(cartuchos) j desenvolvidos e que realizam a transformao PIM  PSM para vrios
tipos de linguagens, tecnologias e plataformas diferentes.
Alm das vantagens citadas anteriormente, destacam-se os seguintes pontos
positivos de AndroMDA:

No desenvolvimento de cdigo redundante, o cdigo reflete exatamente


o que definem os modelos e existe a possibilidade de alterar de o
respectivo plugin para gerar o mesmo sistema em outras linguagens.

Para se desenvolver novos plugins para qualquer plataforma especfica


deve-se basicamente identificar as regras de transformao e criar um
perfil UML.

Como mencionado, AndroMDA trabalha com modelos de entrada, no seu


processo de transformao, no nvel PIM (projeto). A ferramenta de melhor aceitao
para modelar em UML e fazer exportao do metamodelo UML(formato XMI) para
AndroMDA a Magicdraw. Entretanto em [AndroMDA 2009] h uma lista extensa de
ferramentas modeladoras UML que podem ser utilizadas para exportar modelos PIM
para AndroMDA.
Apenas como uma breve comparao, AndroMDA no prov recursos para
definio de interface do usurio abstrata tal como existe em OO-Method. A abordagem
usa conceito de sincronizao de modelos (PIM e PSM), diferindo da abordagem OOMethod que utiliza compilao de modelos. Alm disso, trata questes de
rastreabilidade e validao de modelos de forma bem mais limitada que o OO-Method.
A verso atual estvel de AndroMDA 3.3 que suporta UML 2.2. J a verso
4.0 que est sendo desenvolvida visar aperfeioar o processo de transformao de
modelos e, principalmente, receber como entrada "input", metamodelos de qualquer
linguagem de domnio especfico. Isso, tornar o ambiente MDD de AndroMDA mais
extensvel, flexvel e eficiente, capaz de importar qualquer outro modelo de sistema, e
no apenas, UML.

19

20

Excludo:

4.4.Problemas e Desafios dos Processos MDD


4.4.1. Viso Geral
Pode-se considerar que o desenvolvimento de software dirigido a modelos ainda no
est num nvel de maturidade suficiente para realizar o sonho de todo desenvolvedor: ter
um produto final de software com qualidade e 100% gerado automaticamente a partir
dos seus requisitos. O paradigma dirigido a modelos traz uma promessa de tornar
realidade esse sonho. Entretanto, muitos desafios havero de ser superados. Nos
melhores ambientes, o desenvolvedor ainda consegue modelar em nvel de anlise e
projeto, mas no em nvel de requisitos. Com isso, o desenvolvedor ainda realiza
esforo manual considervel. E isso, tem impactos negativos nos custos, prazos e
qualidade dos softwares produzidos.
A abordagem MDD ainda est na sua infncia. Nem as linguagens de
modelagem e nem as ferramentas se desenvolveram o suficiente para concretizar suas
promessas feitas. O processo MDA, padronizado pela OMG, apenas uma referncia e
pode ser usado por qualquer outro processo especfico de desenvolvimento de software
existente (RUP, XP, OPEN, etc.) desde que se adapte e seja dado um foco especial em
modelos e suas transformaes. Decerto que processos como RUP e OPEN, por suas
prprias caractersticas, so mais fceis de serem adaptveis a um processo dirigido a
modelos do que XP cujo foco predominante a implementao de cdigo.
Como trabalhos futuros e desafios para o processo desenvolvimento de software
dirigido a modelos, destacam-se os seguintes:

Integrao com a etapa de requisitos para elevao do nvel de abstrao inicial


a ser modelado (modelo CIM da MDA); [Martinez A 2008]
Suporte a modelos orientados a metas (goals), agentes e aspectos; [Van
Lamsweerde A 2008]
Melhoria da preciso semntica dos modelos em relao s caractersticas
estticas, dinmicas; [Alencar, F. 2003]
Melhores mapeamentos entre os modelos; [Alencar, F. 2009]
Melhor transformao automtica de modelos (automao); [Nurcan S., 2010]
Melhor suporte Validao de Modelos;
Melhor integrao com as plataformas especficas (PSM);
Melhor e maior percentagem de cdigo fonte gerado;
Maior suporte rastreabilidade entre elementos dos modelo CIM->PIM->PSM;
[Spanoudakis G, 2005]
Melhor suporte engenharia reversa;
Suporte computao autonmica, ou seja, gerao de sistemas que tm as
propriedades de autoconfigurao, auto-recuperao, auto-otimizao e
autoproteo; [ STERRIT, R 2005]

4.4.2.Lies Aprendidas na adoo de solues MDA


Muitas organizaes que, nos ltimos anos, vm utilizando com sucesso solues
MDA, perceberam que um conjunto de prticas e passos consistentes devem ser
considerados ao se adotar um processo MDD automatizado. Um resumo com os passos
necessrios para se desenvolver uma soluo MDA adequada apresentado a seguir:
20

21

Examinar os modelos atualmente usados no processo de desenvolvimento da


empresa e a conexo/correlao semntica entre os elementos desses modelos;
Identificar as transformaes (fases do processo ou modelos) candidatas para
automao;
Especificar (documentar) os requisitos (regras, restries) dessas
transformaes;
Criar os UML Profiles necessrios;
Desenvolver o cdigo da(s) transformao(es);
Esboar documentos de uso, empacotar e distribuir.

4.4.3. O programa FastStart da OMG


Recentemente, o grupo OMG lanou o programa FastStart para ajudar as
organizaes a aprenderem sobre MDA e aplicar MDA nas arquiteturas de seus
sistemas, na integrao dos sistemas e nos seus processos de desenvolvimento de
software. Durante programa FastStart, a organizao recebe consultores do grupo OMG
para realizarem as seguintes atividades:

Anlise inicial MDA;


Reviso da Arquitetura Empresarial MDA;
Plano de Transio MDA;
Seminrios Executivos MDA;
Prtica MDA.

Essas atividades duram em mdia cinco semanas e ajudam a equipe executiva e


tcnica da empresa a:

Analisar e planejar como MDA pode ser introduzido e aplicado para beneficiar a
organizao e seus processos-chave de negcios;
Capacitar a empresa em MDA para que ela prpria, sem ajuda de provedores
externos, desenvolva seu processo MDA/MDD.

4.5. Consideraes finais


O processo de desenvolvimento de software dirigido a modelos (MDD) tem recebido
grande ateno e importncia no meio acadmico e empresarial, sendo considerado por
muitos pesquisadores como uma tendncia irreversvel no futuro da Engenharia de
Software. MDD, conforme arquitetura MDA, foi concebido para alcanar os seguintes
benefcios: produtividade, qualidade, interoperabilidade, portabilidade e reduo de
custos.
Apesar de outros processos de desenvolvimento de software tambm terem essas
metas, nenhum deles consegue alcan-las com mais efetividade do que o processo
dirigido a modelos. Isso, porque em MDD est explcita a ideia de automatizao, ou
seja, de se ter uma sistemtica de transformao de modelos at se obter o produto de
software final. Essa automatizao e foco em modelos geram impactos profundos no
modo como as organizaes produzem, gerenciam e fazem manutenes em softwares.

21

22

Assim, para se obter os benefcios de um processo MDD, a empresa ou


desenvolvedor deve, primeiramente, entender bem o processo e, depois, promover
mudanas de atitude, cultura e tecnologia que, de fato, so o maior desafio para adoo
de um processo MDD.

4.6.Tpicos de Pesquisa
O Processo de desenvolvimento de software dirigido a modelos (MDD) ainda um
tema recente. Os benefcios do padro MDA ainda no foram bem entendidos pelas
organizaes. Existem vrias linhas e tpicos de pesquisa relacionados com
MDD/MDA, entre eles se destacam:

Desenvolvimento de modelos precisos semanticamente e completos para


facilitar transformaes e validaes: Linguagens para modelar sistemas
(Modelos) necessitam de mais preciso semntica, mais formalidade e
descrever, de modo mais completo possvel, as propriedades estticas e
dinmicas de uma aplicao. No apenas UML, mais outras linguagens de
modelagens, necessitam evoluir para cobrir essas necessidades.
Desenvolvimento ou aperfeioamento de ferramentas de apoio ao processo
MDD: Um processo completo de desenvolvimento dirigido a modelos tem
que dar suporte aos modelos que vo dos nveis de abstraes mais elevados
(CIM, PIM) at nveis de plataforma (PSM) e implementao. Raras so as
ferramentas que do suporte com qualidade a todo o espectro de
desenvolvimento de software. Sendo assim, muita pesquisa est sendo
realizada no sentido de preencher essas lacunas.
Adaptaes dos processos especficos de desenvolvimento de software ao
padro dirigido a modelos: MDD no determina qual o processo de
desenvolvimento especfico de software a ser utilizado. Processos existentes
tais como RUP, OPEN ou XP podem ser adaptados para incorporar
automao e transformao de modelos conforme a abordagem MDA.
Extenses MDA para vrias plataformas: Um grande desafio atual que
MDA resolva problemas de interoperabilidade entre plataformas. A grande
heterogeneidade de plataformas existentes aumenta bastante a complexidade
de solues MDA que tm que transformar modelos para vrias plataformas
(sistemas operacionais, arquitetura de hardware, linguagens de programao,
middlewares diversos JAVA/CORBA, COM+/.NET, Web Services), etc.
MDA em Linhas de Produtos de Software (LPS): A necessidade de produzir
aplicativos distintos a partir de pontos comuns e variveis, utilizando
tecnologia de LPS, tem MDD como um forte aliado na automatizao do
desenvolvimento de software.
Rastreabilidade em processos MDD: Saber a correlao entre os diversos
elementos de um sistema, desde requisitos at implementao, uma
poderosa forma de gesto de mudanas que permite, entre outros benefcios,
anlise de impactos em manutenes de software. Como MDD preconiza
mapeamento e transformaes entre esses diversos elementos de um sistema,
a rastreabilidade extremamente facilitada, dispensando inclusive o uso de
ferramentas especficas para esse fim. Entretanto, poucas ferramentas MDD
fazem uso eficaz de rastreabilidade. Medio/Estimativas de projetos de
software em ambientes MDD: Medir tamanho, estimar esforo, prazo e custo
22

Excludo:

23

de software so temas que esto sendo reavaliados com a atual tendncia de


desenvolvimento dirigido a modelos. Isso porque um ambiente MDD
automatizado reduz, tempo, esforo e custo de desenvolvimento dos
projetos.
Anlise da aderncia do MDD a modelos de qualidade de software: Modelos
de qualidade como CMM ou ISO atualmente so empregados para saber se
um determinado processo/produto est aderente ou atende a um
determinado nvel de qualidade. H uma tendncia e necessidade de
aplicao desses modelos de qualidade aos processos de engenharia de
software MDD.

4.7.Sugestes de Leitura
Este captulo props-se a dar uma viso geral sobre Desenvolvimento de Software
Dirigido a modelos. Para complementar o material apresentado neste captulo, sugere-se
que o leitor realize leituras relacionadas aos seguintes temas:

UML executvel (OMG): Usando apenas os diagramas de classes, de estado


e a extenso UML Action Semantics torna um modelo UML capaz de ser
executvel e o transforma, atravs de compiladores de modelos especficos,
em plataformas como C++, Java, etc.
Para mais detalhes sobre esse tpico, ver livro: Executable UML, A
Foundation for Model Driven Architecture, Mellor-Balcer, AddisonWesley, 2002 e o site http://en.wikipedia.org/wiki/Executable_UML.

Grupo de pesquisa Precise UML (pUML): Como visto nas sees 4.2.1 e
4.3.1, UML carece de preciso semntica. Assim, dependendo da
interpretao do projetista pode-se modelar um determinado relacionamento
como agregao, composio, associao ou herana. Visando aperfeioar a
preciso semntica e formalidade da linguagem UML, existe um grupo de
trabalho desenvolvendo Precise UML (pUML). Detalhes podem ser
encontrados em http://www.cs.york.ac.uk/puml/maindetails.html.

Ambiente MDD Moskitt da Universidade Politcnica de Valencia: O Kit


de Modelagem de Software (Modeling Software KIT-MOSKitt) um
ambiente case MDD de cdigo aberto (livre) construdo sobre o Eclipse IDE,
desenvolvido pelo Ministrio Regional de infra-estrutura e transportes de
Valencia
Espanha.
Para
maiores
informaes
ver
http://www.moskitt.org/eng/moskitt0/.

Ambiente MDD Open source OPENMDX: Ferramenta concorrente do


AndroMDA, que roda no Eclipse IDE, sendo considerado tambm o estado
da arte em desenvolvimento dirigido a modelos. Possui boa documentao
adicional e a ferramenta est disponvel para download em
http://www.openmdx.org/.

Livros especficos sobre o tema:


23

Excludo:

24

o MDA Explained: The Model Driven Architecture: Pracice and


Promise by Anneke Kleppe, Jos Warmer, Wim Bast (Editora
Addison Wesley 2003).
o Model-Driven Software Development by Sami Beydeda, Matthias
Book , Volker Gruhn (Editora Springer 2005).
o Real-Life MDA: Solving Business Problems with Model Driven
Architecture (Interactive Technologies) (Editora Morgan
Kaufmann, 2006).

4.8. Exerccios
Para melhor sedimentar os conhecimentos abordados nesse captulo, os seguintes
exerccios foram elaborados:
1. Quais os benefcios em se adotar um processo de desenvolvimento de
software dirigido a modelos?
2. MDA usa modelos distintos para separar os sistemas/aplicaes em os nveis
de abstraes/vises distintos. Quais so estes modelos? Descreva o
propsito de cada um.
3. Descreva a tcnica de transformao de modelos atravs de metamodelos.
4. Quais os padres que esto no ncleo da arquitetura MDA do grupo OMG?
5. Discuta: MDA determina o uso ou recomenda algum processo especfico de
desenvolvimento de software, tal como RUP, XP ou outro qualquer? Como
se poderia adaptar o RUP ou XP para utilizar um processo dirigido a
Modelos (MDD/MDA)?
6. Caracterize o modelo conceitual do OO-Mtodo.
7. O que o Compilador de Modelos do OO-Mtodo?
8. Compare as ferramentas CASE de desenvolvimento de software dirigido a
modelos: OLIVANOVA e AndroMDA.
9. Suponha uma ferramenta MDD que d suporte completo aos modelos CIM,
PIM e PSM. Durante as manutenes dos aplicativos desenvolvidos com
essa ferramenta qual o nico desses modelos que, segundo o padro MDA,
deve ser alterado?
10. Usando uma ferramenta de modelagem UML (MagicDraw, ArgoUML,etc.)
modele a seguinte aplicao simplificada para administrao de alunos,
utilizando o diagrama de classe da figura 4.8. As funcionalidades
(operaes) bsicas da classe Aluno so inserir, excluir, listar e alterar,
conforme diagrama de atividades da figura 4.9. Depois, instale uma das
ferramentas free MDD (AndroMDA ou OPENMDX), configure-as
adequadamente e importe/utilize o modelo UML. Por fim, tente usar
ferramenta MDD para gerar seu aplicativo na plataforma JAVA JEE, com
recursos de persistncia num banco de dados escolhido (Mysql, Postgresql,
etc.) e de distribuio (deployment) num servidor JSP Tomcat Apache. Que
comentrios voc pode dar sobre o processo de transformar seu modelo PIM
em PSM automaticamente? O que achou de obter o cdigo do aplicativo
automaticamente? Tente fazer uma alterao (evoluo) do aplicativo para
adicionar disciplinas, professores e seus respectivos relacionamentos com
24

25

alunos, lembrando
lembrando-se
se de que a alterao dever ser realizada apenas no
modelo PIM (mais
mais alto nvel de abst
abstrao).

Figura 4.8 Diagrama de Classes

Figura 4.9 Diagrama de Atividades

25

26

4.9. Referncias
MDA productivivity case study. The Middleware Company
<http://www.omg.org/mda/presentations>. Acesso em julho 2009.

(2003).

OMG: padro MDA (2003).< http://www.omg.org/mda >. Acesso em julho 2009.


OMG: QVT specification (2009).< http://www.omg.org/spec/QVT/ > Acesso em julho
2010.
Pastor O.; Molina J.C.: Model-Driven Architecture in Practice: A Software Production
Environment Based on Conceptual Modeling. Springer Publisher 2007.
OlivaNova Care Technologies, Denia, Spain (<http://www.care-t.com> Acesso em
julho 2009.
Kontonya, G. e Sommerville, I. (1998) Requirement Engineering: Processes and
Techniques, John Wiley & Sons.
MDA Guide Version 1.0.1, Document Number: omg/2003-06-01 Date: 12th June 2003.
<http://www.omg.org/mda/>. Acesso em julho 2009.
Hitachi M. O.; MDA and System Design. Presentation at MDA Information Day, OMG
Technical Meeting, April 2002.
Model Driven Architecture (MDA). Document number ormsc/2001-07-01, Architecture
Board ORMSC1, July 9, 2001. <http://www.omg.org/mda/presentations>. Acesso
em julho 2009.
MDA profile catalog.<http://www.omg.org/technology/documents/profile_catalog.htm.
Acesso em julho 2010.
France R. B.; Ghosh S.; Dinh-Trong T. : Model-Driven Development Using UML 2.0:
Promises and Pitfalls. In IEEE Computer, vol. 39, no. 2, pp. 59-66, Feb. 2006.
Morgan T (2002) Business rules and information systems aligning IT with business
goals.Addison-Wesley, Reading,MS.
Pastor, O.: Model-Driven Development: The OO-Method Aproach. Presentation at
UFPE, Recife, Brasil August 2008.
AndroMDA. <http://www.andromda.org>. Acesso em julho 2009.
Projetos Eclipse <http://www.eclipse.org/projects/> Acesso em julho 2009.
Eclipse ATL documentation 2009.<http://www.eclipse.org/m2m/atl/doc/>. Acessado
em julho 2009.
Martinez A (2008) Conceptual schemas generation from organizational models in na
automatic software production process. Phd Thesis
Van Lamsweerde A (2008) Systematic requirements engineering- from system goals to
UML models to software specifications. Wiley Publisher 2008
Alencar, F., Marn, B., Giachetti, G., Pastor, O., Castro, J., Pimentel, J.H.: From i*
Requirements Models to Conceptual Models of a Model Driven Development
Process. In: PoEM 2009. Springer LNIBP (2009)
26

Excludo:

27

Alencar F.M.R., Pedroza F., Castro J., Amorim RCO (2003). New mechanisms
integration of organizational requirements and object oriented modeling. In
Proceedings of the VI workshop on requirements engineering (WER'03), Piracicaba SP, Brasil, p.109-123.
Nurcan S., Salinesi C., Souveyet C., Ralyt J. Intentional Perspectives on Information
Systems Engineering. pp. 257-275. Springer Publisher 2010
Spanoudakis G, Zisman A (2005) Software Traceability: A Roadmap. Handbook of
Software Engineering and Knowledge Engineering, Vol. III: Recent Advancements.
World Scientific Publishing Co., 395428
STERRIT, R. Autonomic computing. Innovations in Systems and Software
Engineering, 2005.

27

Você também pode gostar