mda - resumo (omg - model driven architecture) prof...

Rossano Pablo Pinto - março/2013 1

MDA - resumo(OMG - Model Driven Architecture)

Prof. Rossano Pablo PintoMarço/2012 – v0.1Março/2013 – v0.2


PARTE 1O processo de desenvolvimento MDA


Desenvolvimento tradicional de software

● Progresso em desenvolvimento de software– Percebido em termos da complexidade dos sistemas

construídos hoje (evoluímos bastante!):

● Sistemas ENORMES e COMPLEXOS

● Imagine o tempo gasto para construir sistemas simples HOJE (seria muito mais rápido do que antigamente)



● O modelo tradicional é suficiente?– Escrever software é altamente trabalhoso (mesmo sem

levar em consideração o modelo)– Cada nova tecnologia exige o retrabalho da reescrita de

muito código (repetidas vezes... apenas para ser redundante:) )

– Os sistemas são construídos com diversas tecnologias diferentes

– Todos estes sistemas devem ser capazes de comunicar-se

– Os requisitos estão sempre sendo alterados



● O problema da PRODUTIVIDADE – Fases:

1. Conceituação e levantamento de requisitos2. Análise e descrição funcional3. Projeto (design)4. Codificação (coding)5. Teste (testing)6. Implantação (deployment)



● O problema da PRODUTIVIDADE

– Diagramas e documentos são produzidos nas fases 1, 2 e 3

– O que aconteceria se na fase de testes (5) e implantação (6) novos requisitos ou “erros” fossem detectados ?


Requisitos

Análise

Projeto de baixo nível

Codificação

Teste

Implantação

ProcessoIterativo nateoria

Atalho doprogramador

PredominanteTexto

Diagramas eTexto

Código

Código

Diagramas eTexto

Ciclo de vida tradicional de desenv. software



● O problema da PRODUTIVIDADE – Documentos produzidos nas fases 1, 2 e 3 perdem seu

valor tão logo as fases de codificação começam– Ligação entre os documentos (1,2,3) e código perde-se

conforme processo de codificação avança– Diagramas: especificação real do código x figuras sem

relação com o código– Distância entre código e diagramas tende a aumentar

com tempo– Alterações são feitas apenas no código (custo x lucro x

produtividade x utilidade)



● O problema da PRODUTIVIDADE – Se as alterações ocorrem sempre no código, porque

preocupar-se com a atualização dos diagramas?– Metodologias ágeis de desenvolvimento ajudam alguma

coisa neste cenário?● XP● Agile Software Development● ...

Geralmente não! Foco em código funciona bem em equipes permanentes e no início do desenvolvimento (está tudo bem “fresco” na memória).

● O que fazer com pessoas que não estavam na equipe original?



● O problema da PRODUTIVIDADE – O desenvolvedor sente-se produtivo apenas nas fases

de codificação– As fases 1, 2 e 3 são geralmente vistas como “overhead”



● O problema da PORTABILIDADE – A indústria de software possui uma característica

especial: uma nova invenção torna-se popular a cada ano:

● Java● Linux● XML● HTML● SOAP● UML● J2EE

● CORBA● RMI● .NET● JSP● ASP● Flash● WebServices

● Spring● Hibernate● Ruby● XSLT● JESS● DROOLS● RESTful

● Ruby on rails● SuperWABA● Android● iOS● JSON● Etc..● ...



● O problema da PORTABILIDADE – Porque a indústria de software deve acompanhar estes

lançamentos?● Solicitação de clientes (Ex.: Interfaces web)● Resolve problemas reais e atuais (Ex.: XML, “portabilidade

Java” - está mais para PORCABILIDADE!)● Provedores de ferramentas interrompem o suporte a

tecnologias “antigas”● Ficar em dia ou à frente da concorrência● Outros ? ….



● O problema da INTEROPERABILIDADE – Sistemas de software RARAMENTE vivem isolados– Sistemas precisam se comunicar

● Sistemas baseados em Web precisam obter informações em sistemas back-end (geralmente desenvolvidos com tecnologias mais antigas...)

● Mesmo sistemas completos construídos do zero utilizam diversas tecnologias diferentes (que precisam se comunicar)– EJB + SGBDs diversos + Servidor de aplicação …



● O problema da INTEROPERABILIDADE – .....Sistemas precisam se comunicar

● Grandes sistemas monolíticos não são mais construídos: componentes menores que são interconectados– facilidade de manutenção e troca– Cada componente pode utilizar uma tecnologia

diferente



● Os problemas de MANUTENÇÃO e DOCUMENTAÇÃO

– Documentação tem sempre sido feita após a implementação do software

– Escrever documentação durante a codificação é vista como uma tarefa que DESACELERA a produtividade!

– Documentação: vista como algo a ser utilizado pela prosperidade e não pelo desenvolvedor corrente

– Com cada alteração no código a documentação tem que ser alterada (manualmente!!!!)



● Os problemas de MANUTENÇÃO e DOCUMENTAÇÃO

– Uma solução seria a geração de documentos a partir do próprio código. Linguagens que suportam anotação:

● Java● Eiffel

– Resolvem apenas o problema da documentação de baixo nível

– O que fazer????


Model Driven Architecture

● MDA: framework para o desenvolvimento de software

● MDA: definido pelo OMG (Object Management Group)

● Chave no MDA: Uso de modelos no processo de desenvolvimento de software

● Processo de desenvolvimento de software no MDA: Orientado pela atividade de modelagem do sistema de software



● O Ciclo de desenvolvimento MDA● Semelhante ao tradicional● Possui as mesmas fases, mas...● Uma das GRANDES DIFERENÇAS:

– Natureza dos artefatos desenvolvidos em cada fase:

OS ARTEFATOS SÃO MODELOS FORMAIS (MODELOS QUE PODEM SER ENTENDIDOS PELOS COMPUTADORES)



● Principais modelos do MDA● PIM – Platform Independent Model

– é independente de qualquer tecnologia de implementação (i.e.: pode ser desenvolvido para mainframe, Android, PC, JAVA, C++, etc...)

● PSM – Platform Specific Model– DEPENDENTE de tecnologia (Ex.: EJB PSM - possui

entidades como: home interface, entity bean, session bean, etc..) - Um PIM pode ser transformado em 1+ PSM

● CÓDIGO - Transformação do PSM em código



● MDA define: – PIM– PSM– CÓDIGO– Relação entre PIM, PSM e CÓDIGO

● Etapa mais complexa no processo MDA– Transformação do PIM em 1+ PSMs


Requisitos

Análise


Codificação

Teste

Implantação

ProcessoIterativo nateoria

Atalho doprogramador

PredominanteTexto

Diagramas eTexto

Código

Código

Diagramas eTexto

RESGATANDO: Ciclo de vida tradicional de desenv. software


Requisitos

Análise


Codificação

Teste

Implantação

ProcessoMDA

PredominanteTexto

PIM

Código

Código

PSM

Ciclo de vida MDA de desenv. software


Requisitos

Análise


Codificação

Teste

Implantação

ProcessoMDA

PredominanteTexto

PIM

Código

Código

PSM

Ciclo de vida MDA de desenv. software

FerramentaDe

Transformaçãoo

FerramentaDe

Transformaçãoo



● Transformar um PIM (alto nível) em 1+ PSM ● aumenta o nível de abstração em que o

desenvolvedor consegue trabalhar.● Benefício:

– Permite que o desenvolvedor lide com sistemas mais complexos com menos esforço


● modelo tradicional x MDA– Muitas ferramentas podem gerar código, mas geralmente

geram apenas templates (esqueletos). O restante do código é “preenchido à mão”.

– As transformações no MDA são feitas totalmente por ferramentas e de forma automática!!

– Transformar PSM em código é fácil (devido às semelhanças da plataforma alvo)

– O grande benefício do MDA é transformar PIM em PSM de maneira AUTOMÁTICA!

MDA: Automação dos passos de transformação


MDA: Automação dos passos de transformação

FerramentaDe

TransformaçãooPIM PSM Cod.

Os 3 passos principais no processo de desenvolvimento MDA.

FerramentaDe

Transformaçãoo


● Produtividade ● Portabilidade● Interoperabilidade● Manutenção e documentação

MDA: Benefícios (resumo)


● Produtividade (modelo de alto nível deixa de ser “apenas papel”)

– menos trabalho: PIM não leva em consideração detalhes específicos de plataforma

– atenção focada na lógica do negócio

● Portabilidade– foco no desenvolvimento do PIM



Interoperabilidade MDA com o uso de pontes (bridges)

PIM

PSM PSMPontePSM

Código CódigoPonte

Código

Primeiratransformação

Primeiratransformação

Segundatransformação

Segundatransformação


● Manutenção e documentação– o modelo é uma representação exata do código e vice-

versa– PIM não é mais abandonado após a escrita– Mudanças no sistema são feitas no PIM (nunca

diretamente no código, como no modelo tradicional)– No entanto, boas ferramentas poderão fazer a geração

nas duas vias:● modelo para código● código para modelo



● OK, mas o que é necessário para implementar o MDA?

– modelos de alto-nível (precisos, bem-definidos, etc..)– linguagem para escrever modelos de alto nível (MOF -

segundo um dos autores da bibliografia utilizada, perfis UML não serviriam, EU particularmente creio que sirvam)

– definição das transformações entre PIM e 1+ PSMs– linguagem para escrever as transformações (XSLT + XSL

ou outra)– ferramentas que consigam executar as regras de

transformação PIM 2 PSM + PSM 2 code (xsltproc no Linux)

MDA: Building blocks


PARTE 2

O framework MDA


O que é um modelo?

● Definições gerais– Um exemplo utilizado por um artista– Uma pessoa fazendo pose para um artista– Uma réplica (em menor escala) de um objeto real: ex.:

carro– Um exemplo de um método de execução de trabalho– Um molde utilizado para produzir algum artefato de

roupa


O que é um modelo?

● O que as definições anteriores possuem em comum?

– Um modelo é sempre uma abstração de alguma coisa que existe na realidade

– Um modelo é diferente da coisa que ele modela● detalhes são deixados de lado, o tamanho pode ser diferente

– Um modelo pode ser utilizado para produzir algo que existe na realidade


O que é um modelo?

● Definições que utilizaremos– Um modelo é a descrição de (parte de) um sistema

escrito em uma linguagem bem-definida.– Uma linguagem bem-definida é uma linguagem com

sintaxe (formato) e semântica (significado) bem-definidas, a qual é apropriada para interpretação automática por computadores.


O que é um modelo?

● ...Definições que utilizaremos● Observe que, apesar da linguagem UML ser

amplamente utilizada, ela não é a única linguagem apropriada para MDA.

● Apesar das pessoas terem uma imagem mental de modelo como um conjunto de diagramas (Ex.: UML), não existe nenhuma restrição quanto ao uso de outros tipos de modelo.


Framework MDA: Modelos e linguagens

Modelo

Linguagem

Sistemadescreve

éescrito

em

Relação entre MODELO, SISTEMA e LINGUAGEM utilizada para escrever o modelo


Tipos de modelo

● Modelo de negócios e de software– Negócios - não descreve o sistema de software. Ele é

CIM (Computational Independent Model)– Software - descreve o sistema de software.


Tipos de modelo

Modelo de negócios

Modelo de software

departamento

software desuporte

descreve

descreve

derivado de

Sistema deNegócio


Tipos de modelo

● Modelos Dinâmico e Estrutural– Diagrama Classe UML - estrutural– Diagrama Estado UML - dinâmico– Mas são tão interrelacionados que deveriam ser

considerados um modelo só– Então, seria melhor considerar os diagramas como views

de um mesmo modelo.


Tipos de modelo

Modelo

UML

Sistemadescreve

éescrito

em

use case view interaction view

class diagram view state diagram view


Tipos de modelo

ModeloPetrinet

Petrinet

Sistema descreve

éescrito

em

ER

éescrito

em

ModeloERdescreve

Se uma mesma linguagem não é capaz de descrever osistema, então 2+ linguagenssão utilizadas. Com isso o sistemaé descrito em 2+ modelos.


Tipos de modelo

● Modelos Independente e Dependente de plataforma

– PIM pode ser descrito usando MOF– PSM pode ser descrito usando Perfis UML– É possível traçar a linha entre os dois modelos? (O que é

específico e o que não é?)● Dificilmente. Um modelo é mais ou menos específico que outro

– Em MDA, um modelo menos específico é transformado em um mais específico.


O que é uma transformação?

FerramentaDe

Transformaçãoo

FerramentaDe

Transformaçãoo

PIM PSM CÓDIGO

definição da transformação




transformaçãoUML p/ Java

UML Java



transformaçãoUML p/ UML

UML UML



transformaçãoJAVA p/ JAVA

JAVA JAVA



transformaçãoC# p/ JAVA

C# JAVA


O que é uma transformação

● Transformação entre linguagens idênticas– UML p/ UML– Java p/ Java– .... p/ ....– PIM (UML) p/ PSM (UML). CUIDADO: PSM subset UML

(apenas construções que podem ser mapaeadas diretamente na linguagem alvo - Ex.: Java) - UML4Java

– Motivação:● refactoring● normalização de um modelo ER● etc..


PSMPSM

LinguagemLinguagem

Framework básico do MDA

FerramentaDe

TransformaçãooPIM PSM


Linguagem

éescrito

em

Linguagem

sãoescritos

emé usadopor


MDA Hoje

● Linguagens OMG– Linguagens p/ PIM ou PSM– UML, OCL (Linguagem p/ queries)– QVT– Action Semantics - define semântica em modelos de

comportamento (behavioral)– Perfis: CORBA, EDOC, EAI, QFTP, TelcoML, VOICP,

UTP, ...

http://www.omg.org/mda

http://www.omg.org/spec/index.htm


MDA Hoje

● UML como linguagem para PIM– UML puro

● Ponto forte: modelagem estrutural● Ponto fraco: modelagem de comportamento

– Executable UML: UML + ActionSemantics (AS)● Principais diagramas: state machine● Ponto fraco: não é tão adequado para todos os domínio:

– OK p/ Sistemas embarcados– NOK p/ Sistemas “Administrativos”– AS é baixo nível (escrever tanto código quanto PSM)– AS não possui sintaxe concreta padronizada

– UML + OCL -> o mais apropriado, mas não é perfeito.


MDA Hoje

● Ferramentas (pesquisar o estado da arte)

– Transformações:● PIM p/ PSM● PSM p/ código● PIM p/ código● Ferramentas ajustáveis● Ferramentas para criação

de regras de transformação

– Outras● Editor de código (IDE)● Repositório de modelos

● Editor de modelos (CASE)● Validador de modelos● Editor de definição de

transformações● Repositório de regras de

transformação

– Geralmente, é necessário o uso de várias ferramentas!!


PARTE 3Exemplo


Exemplo de aplicação MDA

● Serviço de entrega de café da manhã– Descrição textual pág. 43

● O sistema de software– Descrição textual pág. 44



● Aplicando o framework MDA– Desenvolver PIM– A partir do PIM serão gerados 3 novos PSMs

● PSM que modela a base de dados (modelo relacional)● PSM que modela a camada do meio - (modelo EJB escrito em

uma variante UML)● PSM que modela a interface WEB - (modelo escrito em uma

variante UML)

– As variantes são compostas de estereótipos (não associados a perfis)



● Aplicando o framework MDA– Criar regras de transformação

● PIM p/ PSM1 PSM2 PSM3● PSM1 p/ SQL● PSM2 p/ Java● PSM3 p/ HTML, CSS, JSP



● Regras de transformação PIM -> PSM ER– UML string -> VARCHAR(40) - tamanho arbitrário!– UML integer -> INTEGER– UML date -> DATE– Atributo Address não é classe, é uma “struct”, então:

● tabela separada p/ cada tipo de dado OU● inserir “inline” os dados na mesma tabela que detém os dados

da classe que possui o atributo● REGRA: tipo de dado que não possui operação será mapeado

em colunas, cada uma representando um campo do tipo de dado (lembram do struct em C?)



● Regras de transformação PIM -> PSM ER– Cada classe será mapeada em um tabela

● Cada atributo torna-se um campo do registro● Quando o tipo do atributo for uma classe, o campo da tabela

deve armazenar um chave estrangeira para a tabela que representa a classe

– Cada associação será transformada em uma chave estrangeira no modelo da base de dados, provavelmente gerando uma nova tabela

– etc.., etc.., etc..– RESULTADO -> próximo slide



● Regras de transformação PIM -> PSM EJB– Cada classe no PIM gera um EJBEntityComponent– Cada classe no PIM que não faz parte de outra classe no

PIM é transformada em COMPONENTE EJB + esquema de dados EJB (EJBDataClass)

– etc.., etc.., etc.. (págs. 56 e 57)



● Regras de transformação PIM -> PSM WEB– etc.., etc.., etc.. (pág. 59)



● Regras de transformação PSM1 -> código1.Para cada tabela, gere o texto “CREATE TABLE”,

seguido do nome da tabela e um “{“, então execute regra 2, seguida pela regra 3, e termine com “}”

2.Para cada coluna na tabela, gere o nome da coluna, seguida do tipo e (opcionalmente) o tamanho da coluna, então gere o texto “NOT” se a coluna não pode ter o valor NULL e termine com “NULL,”.

3.Gere o texto “PRIMARY KEY (”, seguido por uma lista separada por vírgula dos nomes das colunas que são chave primária e termine com “)”.



● Regras de transformação PSM1 -> código– PARTE DO CÓDIGO GERADO:

CREATE TABLE Comestible ( comestibleID INTEGER NOT NULL, name VARCHAR (40) NULL,

price REAL NULL,

minimalQuantity INTEGER NULL,

transportForm VARCHAR (40) NULL,

PRIMARY KEY (comestibleID)

);

mda - resumo (omg - model driven architecture) prof...

Documents