Apresentação semi-final

Mda Apresentacao

View SlideShare presentation or Upload your own. (tags: architecture model-driven)

A sopa de letrinhas do MDA

Em qualquer artigo que trata sobre MDA, é comum encontrar um grande conjunto de siglas (até a própria metodologia é uma sigla). Para facilitar o entendimento, apresento aqui algumas das mais comuns, com uma breve descrição sobre seu significado:

MDA (Model-Driven Architecture) -> Um dos primeiros posts desse blog apresenta de forma bem simplificada o que isso significa.

OMG (Object Management Group) -> Um consórcio de companias da área da computação e software que visa desenvolver padrões na área de sistemas distribuídos orientados a objeto e na área de modelagem. Foi esse consórcio que desenvolveu a MDA, bem como outros padrões como UML, XMI e MOF.

UML (Unified Modeling Language) -> Uma linguagem de propósito geral para modelagem de sistemas, especialmente na área de engenharia de software. Através de notações gráficas, é capaz de criar um modelo abstrato de sistemas específicos.

XMI (XML Metadata Interchange) -> Um padrão para troca de metadata baseado em XML. Pode ser usado para qualquer metadata cujo metamodelo pode ser expressado em MOF. É usado principalmente como um formato para troca de modelos UML.

MOF (Meta-Object Facility) -> É um padrão para a engenharia dirigida a modelos. É utilizado para a especificação de meta-metamodelos. Por exemplo, uma especificação UML (modelo) de um determinado sistema é baseada na especificação genérica da UML (metamodelo), que por sua vez é baseada na MOF (meta-metamodelo).

DSL (Domain Specific Language) -> Uma linguagem específica para um determinado domínio. Por exemplo, MOF é uma linguagem específica para o domínio de metamodelos.

MDSD (Model-Driven Software Design) ou MDE (Model-Driven Engineering) -> É uma metodologia de desenvolvimento de software cujo foco é a criação de modelos que descrevem os componentes de um sistema. A principal iniciativa nessa área é a MDA.

CWM (Common Warehouse Metamodel) -> Uma especificação para modelar metadata de objetos encontrados em um ambiente de datawarehouse. Baseado em MOF, XMI e UML, é um dos pilares da MDA.

QVT (Query/View/Transformation) -> Um padrão para transformação de modelos. É um conceito-chave em MDA, usado nas transformações de CIM para PIM, PIM para PSM, e PSM para código-fonte.

CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model) -> Esse mesmo post apresenta esses conceitos de forma simples.

Ufa! Sabendo o que significam essas siglas, torna-se mais fácil compreender os vários artigos encontrados sobre MDA! Para maiores informações sobre vários desses conceitos, o site oficial da OMG pode ser consultado (e lá vamos nós ao vício das siglas...)

Blog sobre MDA, MDSD, Eclipse e Spring

Acabei esbarrando nesse blog(form follows function) hoje, que trata, entre outras coisas, sobre MDA. Um post interessante, apesar de longo, aborda os méritos do desenvolvimento de software dirigido por modelos, por exemplo:

• A geração automática de código não deixa, necessariamente, o processo mais rápido, pois o tempo ganho será usado no refinamento dos modelos.
• Níveis mais altos de abstração deixam as coisas mais simples, em vez de complicadas.
• Geração automática de código não significa que o cliente fará seu próprio software.
  

Accelo

Outra ferramenta que encontrei nas pesquisas sobre MDA foi o Accelo.
O Accelo é uma ferramenta completamente integrada ao Eclipse para transformação de modelos em código. Desenvolvida pela companhia francesa Obeo, é uma ferramenta Open Source, tal qual o AndroMDA.
Para efetuar as transformações, o Accelo usa o conceito de Módulos, que são coleções de templates que descrevem a informação necessária para gerar código-fonte a partir de um meta-modelo. Cabe frisar que cada módulo é específico para uma tecnologia (Java, C# etc). Em cada template, scripts permitem que o usuário customize o gerador de forma precisa.
Essa ferramenta é compatível com XMI 1.x e XMI 2, o que garante a compatibilidade com outras ferramentas para a modelagem UML, como RSM, Together e Poseidon.
Outras características importantes:

• Segue as especificações e recomendações da OMG na implementação de QVT (Query/View/Transformation) e MOF (Meta-Object Facility)
• Suporte à UML 1.x e 2
• Módulos disponíveis para C#, JEE Hibernate/Strufs, Python e PHP, entre outros
  
• Possibilidade de desenvolver módulos para outras linguagens

Para maiores informações, visite o site oficial.

Em um próximo capítulo, darei uma visão geral sobre a sopa de letrinhas existente no MDA. Aguardem!

Papéis em MDA

"MDA irá tornar os desenvolvedores mais produtivos, não redundantes."

Mostramos aqui quais papéis os desenvolvedores irão ocupar na MDA:

Analista de requisitos

- A análise de requisitos não muda. A captura dos requisitos em modelos UML que possam ser lidos pelo computador diminui as chances dessa análise ser mal-interpretada. Modelos UML como diagramas de atividade e diagramas de casos de uso ajudam na comunicação e visualização dos requisitos mas sua construção não pode ser automatizada.

Analista/Designer

- Os requisitos precisam ser expressados formalmente em outros tipos de diagramas como diagramas de classe e diagramas de transição de estado. A precisão desses diagramas é crucial, pois eles serão tranformados em outros modelos ou código, evitando modificações posteriores. No entanto apenas a lógica do negócio precisa ser embutida nesses modelos, não é necessário se preocupar com estruturas de dados, distribuição, concorrência, etc. O analista pode ainda utilizar uma ferramenta que gere UML executável, podendo obter assim, um feedback mais rápido com o cliente.

Arquiteto

- O arquiteto, como o próprio nome diz, cuidará da arquitetura do sistema, ou seja, sua estrutura geral. Ele utilizará sua experiência para selecionar os modelos e mapeamentos específicos para melhorar a performance do sistema, podendo inclusive reutilizar modelos e mapeamentos já  pelo mercado.

Analista/Prorogramador

- O programador tem um papel semelhante, mas com duas diferenças essenciais. A primeira é que ele começará a se expressar no formato QVT (Query, Views & Transaction), não em uma linguagem convencional como Java ou C#. A segunda diferença é que ele criará regras mais genéricas: em vez de criar uma "lista para um conjunto de contas", ele criará uma regra para uma "lista de qualquer classe que tenha o mesmo padrão de acesso de uma conta". Assim a experiência do programador na plataforma é melhor usada, aumentando a influência do arquiteto de um design pontual para um design com visão de sistema.

Testador

- A criação de testes passa a ser mais eficiente com o auxílio de ferramentas que criam scripts de teste a partir dos modelos. O testador passa a ser mais produtivo, e a tarefa, menos tediosa.

Mantenedor

- A manutenção também torna-se mais produtiva por causa dos modelos, pois não é mais necessário entender a lógica lendo o código. O mantenedor pode realizar alterações diretamente no modelo. Uma alteração na lógica gera alterações no PIM, enquanto a mudança de tecnologia muda os mapeamentos utilizados.

Cliente

- O resultado é um produto melhor para o cliente.

Do artigo "Roles in the MDA Process" de Stephen J. Mellor e Andrew Watsono

Disponível aqui.

AndroMDA

   Bom pessoal, pesquisando sobre MDA, encontrei o AndroMDA (pronuncia-se Andrômeda).

   O AndroMDA é um framework open source baseado em MDA (Model Driven Architecture). Ele utiliza os modelos UML e uma série de plugins, chamados de cartuchos para realizar a geração de artefatos tais como código fonte, configurações, scripts, DLLs e outros.

   A arqiutetura do AndroMDA permite o desenvolvimento rápido de cartuchos assim como sua customização em nível de sistema.

   A atual versão apresenta as seguintes características:

• Modular design: todos os módulos do AndroMDA são "plugáveis" e podem ser modificados para atender suas necessidades
  
• Suporte para várias ferramentas UML: como MagicDraw, Poseidon, Enterprise Architect e outras
• Vem com o metamodelo completo da UML 1.4 (atualmente em fase de desenvolvimento para suportar UML 2.0): alternativamente, você pode incluir seu próprio metamodelo em MOF XMI e gerar código baseado nele
• Transformações Model-to-Model
• Validação de modelos de entrada
• Cartuchos Ready-to-use: para a maioria das arquiteturas (EJB, Spring, Hibernate, Struts, JSF, Axis, jBPM)

      Cartuchos

Assim como o Eclipse, o AndroMDA aceita plug-ins para novos pacotes de transformação. Estes pacotes são chamados de cartuchos.

Nativamente, AndroMDA vem com cartuchos de transformação:

• Spring
  
• EJB 2 / 3
• webservices
• Hibernate
• Struts
• JSF
• Java
• XSD

Fontes: AndroMDA.org   

      AndroMDA.com.br

   

Visão a curto e longo prazo da MDA

Tendo uma idéia do que se trata o MDA, é interessante agora conhecer as intensões da arquitetura. Escolhi o position paper "Model-Driven Architecture: Vision, Standards And Emerging Technologies" de John D. Poole por descrever separadamente o que a MDA busca para o presente, e o que se pretende alcançar a longo prazo.

Então, como foi dito, descreverei bem brevemente a visão a curto prazo (near term vision), com o que é necessário para se desenvolver um sistema que atenda a MDA; e a visão a longo prazo (long term vision), e as possibilidades que os sistemas oferecerão para facilitar a proposta da MDA.

----

1 - Visão da MDA a Curto Prazo

O que se espera alcançar da MDA em um futuro imediato é um ambiente interoperabilidade eficiente e quase sem suturas (remendos) entre diversas aplicações, ferramentas e databases é alcançado através da troca de modelos compartilhados (os metamodelos).

Para realizar essa visão, são considerados os seguintes quesitos:

Importância da Metadata

"In fact, metadata is the primary means by which interoperability is achieved"

Metadata é o meio primário para se conseguir interoperabilidade, o que quer dizer que, duas aplicações desenvolvidas apartir de modelos, que por sua vez são definidos por um metamodelo compartilhado, conseguem interagir sem preocupação com as diferenças entre seus modelos.

Troca de dados, transformações e mapeamentos entre fontes de dados dissimilares podem ser orientados através de descrições em metadata, formal e independente de produto, das transformações, dos tipos de dados e do sistema de mapeamento.

Em um sistema MDA, não é necessário que modifique a representação interna da metadata nas aplicações, ferramentas e databases. Metadata compartilhada consiste na externalização das definições compartilhadas entre os componentes. Em outras palavras, o que interliga os componentes é o que deve seguir o metamodelo definido, e não os componentes em si, que se mantém como estão.

Para garantir que a metadata será compreendida por todos os participantes, os sistemas baseados em MDA deve padronizar o seguinte:

• Uma linguagem formal (sintaxe e semântica) para representar a metadata
• Um formato para troca e publicação de metadata
• Um modelo de programação para acesso e descoberta de metadata
• Mecanismo para extender cada um dos itens mencionados
• Um serviço de metadata opcional, onde estarão as metadatas publicadas

Serviços Comuns e Modelos de Programação

Mais um bloco de construção importante dos sistemas interoperáveis. Se trata da padronização dos sistemas comuns e serviços a nível de aplicação, assim como as APIs usadas para acessar os serviços.

Especificação de Plataforma

Cada instância de um sistema baseado em MDA inclui um descritor que especifica quais os recursos suportados pela mesma.

2 - Visão da MDA a Longo Prazo

Abordando agora uma visão do que se pretende alcançar com a MDA em um futuro mais distante. Um exemplo do que seria possível é um software capaz de identificar automaticamente as propriedades do ambiente e se adaptar de várias maneiras, incluindo mudar seu próprio comportamento.

Temos então alguns recursos que se tornarão realidade:

Orientação Baseada em Conhecimento

A funcionalidade do sistema se torna cada vez mais baseada em conhecimento (knowledge-based) e capaz de descobrir propriedades em comum de domínios dissimilares, tomando decisões inteligentes, e criando e armazenando as inferências produzidas.

Arquitetura Dinâmica

Experiências obtidas no desenvolvimento de sistemas MDA baseados em objetos extendíveis resultarão na criação de sistemas que podem interpretar modelos e modificar seu comportamento de acordo com o necessário ao invés de mapear explicitamente visões externas de metadata para modelo de implementação.

Sistemas Adaptativos

Com classes altamente dinâmicas e sistemas auto-organizáveis, será possível então que o sistema possa se acomodar a mudanças imprevistas e reagir apropriadamente sem a necessidade da intervenção do programador.

----

Bem, é isso. Enquanto agora está se criando padrões para que seja mais fácil reaproveitar e interligar aplicações em um sistema, mira-se que o sistema se adapte automaticamente e faça inferências para dar menos trabalho ainda para o programador, de forma que todo o aplicativo acabe por se desenvolver com simples "clicar de botão".

...Sorte dos futuros programadores.

Model-Driven Architecture??

É! Ou MDA para os mais íntimos. Acho que ainda não tenho esse grau de intimidade, mas tenho que espero ter daqui para o fim da disciplina =)

De início, é necessário (ou inevitável) falar sobre do que se trata a Model-Driven Architecture. Traduzindo obtemos uma 'Arquitetura Dirigida a Modelos'. Essa arquitetura foi definida pela Object Management Group (OMG) e lançada em 2001.

Como o próprio nome sugere, essa arquitetura ressalta a importância dos modelos no processo de desenvolvimento de software. Ela define que o processo deve se focar na modelagem do software, em um nível conceitual, sem se prender a alguma plataforma/implementação específica. Os modelos conceituais resultantes podem passar por transformações, gerando novos modelos com um nível de abstração cada vez mais específico e ligado a uma determinada forma de implementação, tornando possível a geração automática do sistema final. Vale ressaltar que os modelos construídos devem seguir uma formalidade, sem ambiguidades, para que sejam entendidos pelos softwares.

Resumidamente, a MDA determina que o processo de desenvolvimento passe pelos seguintes passos:

1. Primeiramente é gerado o Computation Independent Model (CIM). Este modelo deve ser construído a partir de um ponto de vista independente de computação, mostrando apenas requisitos do sistema, sem detalhes de sua estrutura;
   
2. A partir do CIM, é gerado o Plataform Independent Model (PIM). Este modelo possui um elevado grau de abstração e é feito sem levar em conta qualquer tipo de tecnologia;
   
3. Do PIM, é gerado o Plataform Specific Model (PSM). Ao contrário do PIM, o PSM é construído levando em conta uma tecnologia específica. De um PIM podem ser gerados vários PSM's, cada um para uma tecnologia específica;
   
4. Por fim, a partir do PSM, deve ser gerado o código do sistema. Esse código deve ser o mais próximo possível da solução final, incluindo regras de negócio.

A figura abaixo mostra os passos ditados pela MDA


As transformações de um modelo para outro devem ser automáticas, conforme um conjunto de regras que ditam como um modelo deve ser transformado em outro.

Por enquanto é só. Futuramente, deveremos trazer mais detalhes da MDA.
Aguardem as cenas dos próximos capítulos =P

Fonte principal da postagem:
http://www.linhadecodigo.com.br/Artigo.aspx?id=1953

Blogs interessantes!

  Bom pessoal, conforme sugerido pelo professor Rogério, aqui estão alguns blogs que julgo interessantes. Vale a pena dar uma fuçada por lá, quem sabe não encontram algo de interesse?

  Pensar enlouquece pense nisso : http://www.interney.net/blogs/inagaki/

  Interney: http://www.interney.net/

  Usabilidoido: http://usabilidoido.com.br/   -> este é bem legal, sobre usabilidade

  Blog do Noblat: http://oglobo.globo.com/pais/noblat/  -> Ótimo blog do renomado jornalista

  Brainstorm #9: http://www.brainstorm9.com.br/

  Marketing de busca: http://www.marketingdebusca.com.br/

  Reflexões Digitais: http://www.reflexoesdigitais.com.br/blog/

  Arquitetura de Informação: http://arquiteturadeinformacao.com/

Hello World!

Bem-vindos ao blog TEES - Model-Driven Architecture, criado para discutir novas metodologias de software, em especial MDA, como parte da disciplina Tópicos Especiais em Engenharia de Software (TEES). Esse blog será administrado por João Marco, Marcel, Paulo, Thiago Feitoza e Thiago Fraga, alunos de Ciências da Computação da UFS, e supervisionado pelo professor Rogério P C do Nascimento, PhD.