Interação entre MDA e PMBOK para Suporte ao Desenvolvimento de Aplicações Complexas

View SlideShare document or Upload your own. (tags: artigo mda)

Vá em paz, OptimalJ

No último post que fiz neste exato blog, eu botei uma animação relacionada com a ferramenta OptimalJ. Não sei se alguém chegou a vê-la, pois um tempo depois percebi que a animação nao estava carregando, mas acabei deixando de lado, pensando que podia ser algum motivo temporário. Porém, este fato se tornou uma constante. Toda vez que eu entrava, a animação não se encontrava mais lá. Encuquei-me.

Quando fui procurar algumas referências da ferramenta para trabalhar no manuscrito, deparei-me com um fato que não considerei agradável. Na Wikipedia, na página sobre OptimalJ, encontrei a seguinte declaração:

"Due to internal restructurings, Compuware decided in 2008 to discontinue OptimalJ"

Se alguém está fraco no inglês, isso quer dizer que o OptimalJ foi descontinuado, ou seja, bateu as botas.

Voltando ao momento do encontro, eu parei, pensei, li de novo, parei de novo. O fato estava ali. Ainda tinha a referência para tal declaração. Aqui é possível ler a citada referência.

Dessa triste forma, quero deixar aqui o "Adeus" ao OptimalJ, que, na minha opinião, tinha sido uma das ferramentas mais interessantes encontradas durante a pesquisa. Afinal, ela permitia transformar o modelo PIM em PSM, coisa que o AndroMDA e o Acceleo não faz. Felizmente as outras duas ferramentas continuam sendo atualizadas e, provavelmente, um dia poderão realizar mais transformações, inclusive entre o PIM e o PSM.

Inté

Agile MDA

Como foi comentado na apresentação final, existe uma abordagem que mescla os princípios das metodologias ágeis com os da MDA. Essa abordagem chama-se Agile MDA, e nessa postagem vou falar um pouco melhor sobre ela.

Algumas pessoas acreditam que não faz sentido colocar "modelagem" e "ágil" na mesma frase [1]. Isso se deve, entre outras razões, na existência de documentação que não possa ser executada. Como os próprios princípios ágeis afirmam, a medida de progresso de um projeto é o código funcionando. Para superar esse buraco, é necessário a criação de modelos executáveis.

Modelos executáveis, como o próprio nome diz, são modelos capazes de serem executados através de ferramentas especializadas. Esses modelos são desenvolvidos em um perfil (um subconjunto) da UML, o Executable UML. Dessa forma, modelos executáveis se comportam como código, mas em um nível de abstração maior e de forma independente de plataforma.

Entretanto, essa não é a única abordagem possível. [2] apresenta outra possível abordagem, que é exemplificada pela figura abaixo:

Nessa abordagem, o uso de técnicas e ferramentas simples facilitariam a inclusão do cliente na modelagem (um dos princípios dos métodos ágeis). Modeladores experientes transformariam os artefatos gerados nessa etapa em PIMs (Platform Independent Model). Os modelos seriam refinados e posteriormente transformados, com a ajuda de ferramentas automatizadas, em PSMs (Platform Specific Model). Esses modelos seriam novamente refinados e transformados finalmente em um software funcional.

Essa abordagem é bem semelhante à abordagem tradicional da MDA, mas difere em alguns pontos cruciais:

• Deve-se aplicar os princípios e práticas da modelagem ágil (gerar apenas os modelos necessários, com o grau de complexidade e completude suficientes para o momento);
• Participação ativa dos stakeholders (uso de técnicas que permitam a inclusão do cliente na modelagem);
• Uso de uma abordagem iterativa e incremental, em passos pequenos.

Cabe ressaltar que essa abordagens não se excluem. É possível mesclá-las para aproveitar o que parecer mais interessante, gerando assim uma abordagem que possa ser mais interessante de ser aplicada.

Para maiores informações sobre princípios, práticas e metodologias ágeis, consulte o blog Ligeirinhos. Maiores informações sobre a Agile MDA podem ser encontradas nas referências.

Referências:

[1] MELLOR, Stephen J. Agile MDA, 2004. Disponível em: http://www.omg.org/mda/mda_files/Agile_MDA.pdf. Último acesso em 12/12/08.

[2] AMBLER, Scott W. A roadmap for Agile MDA. Disponível em: http://www.agilemodeling.com/essays/agileMDA.htm. Último acesso em 12/12/08.

Meta-Objetivo

Quando se trata de desenvolver software para um cliente, é frequente o uso da palavra "insatisfação". É uma palavra que tem como fundamentos os vários erros cometidos no processo de desenvolvimento como um todo (desde a especificação, até a implantação). Isso pode ser percebido com a analogia feita na imagem a seguir.

O fato de criar um foco em cima do código gera muitos desses problemas. A preocupação em fazer a aplicação funcionar, e o tempo e esforço gasto para o mesmo, ofuscam o que deveria ser a principal meta da construção do software: Atender a necessidade do cliente.

A MDA, como já fora explicado anteriormente, pretende mudar o foco do código para modelos. Com essa abordagem, atinge-se determinadas benefícios:

• Melhora na produtividade - Uma vez que se trata de uma programação de alto nível, há uma maior facilidade com a programação. Graças à automatização da geração de código, torna-se um processo mais rápido e, por consequência, o feedback para o cliente também.
• Portabilidade - Como há uma criação de modelos, sendo um deles o PIM (Plataform Independent Model), torna-se possível a criação do software para plataformas diferentes de maneira eficiente.
• Manutenção - As modificações não são feitas em código, mas em modelos.
  

Não adianta apenas melhorar práticas e técnicas para o desenvolvimento a nível de código se no final o cliente não recebe o que precisa. A atenção deve ser voltada a um nível mais alto, e mais próximo ao cliente.

Imagens e texto baseado na postagem Introduction[2] - The MDA Approach, do blog http://modeldrivenarchitecture.wordpress.com/

Deixo em aberto uma sugestão para as próximas postagens: Viabilidade da MDA. "Is It possible???". Existem aqueles que acreditam, outros que duvidam. Seria interessante o desenvolvimento de um debate sobre essa questão aqui no blog.

OptimalJ

Na apresentação final foram mostradas duas ferramentas que podem ser utilizadas para auxiliar o desenvolvimento utilizando MDA. Uma delas já foi um post desse blog em tempos não muito distantes, a AndroMDA. Porém, a outra ferramenta só foi mostrada na apresentação e não foi sequer citada por aqui (desleixo de minha própria pessoa, confesso). Se nunca é tarde para começar, então vou deixar registrado aqui algumas palavras a respeito da OptimalJ.

A OptimalJ é um ambiente de desenvolvimento comercial que permite o rápido design, desenvolvimento e modificação de aplicações J2EE e se encontra atualmente na versão 4.3. Ela é construída em cima do Eclipse e utiliza a UML para construção de modelos. Além de possibilitar a modelagem do PIM e gerar código a partir dele, como a AndroMDA faz, a OptimalJ permite a transformação do PIM em PSM, registrando a devida transformação, como sugerido pela MDA. Essa ferramenta também insere uma arquitetura de camadas quado realiza a transformação do PIM em PSM. Vale ressaltar que o PIM dentro da OptimalJ é chamado de "Modelo de domínio", enquanto que o PSM é chamado de "Modelo de aplicação" e o código fonte é chamado de "Modelo de código".

Abaixo posto uma animação que dá uma visão geral dos modelos e transformações realizadas pela OptimalJ. É em inglês, mas vale a pena dar uma conferida:



Essa apresentação foi retirada do site da Compuware e pode ser encontrada a partir do link:
http://frontline.compuware.com/javacentral/tools/
Além da animação, outras informações podem ser encontradas a respeito da OptimalJ nesse link.

Outra referência interessante é uma dissertação de mestrado que pode ser baixada pelo link:
http://www.teses.usp.br/teses/disponiveis/3/3141/tde-08012008-103612/
A dissertação tem o título "Transformações e mapeamentos da MDA e sua implementação em três ferramentas". Epa! Três ferramentas?? É isso mesmo. Essa dissertação ainda fala de uma terceira ferramenta denominada ArcStyler. Quem tiver interesse, pode baixar a dissertação e ler mais a respeito dessa ferramenta e a respeito da própria MDA. Fica aqui a dica.

Inté!

MDA - Apresentação Final

TEES - MDA Apresentação Final

View SlideShare presentation or Upload your own.

ADM - MDA para softwares legados

Pesquisando sobre o mistério das aplicações de MDA, descobri que essa abordagem pode ser usada no rejuvenescimento de software.

MDA se baseia na idéia de forward engineering, isto é, a geração de código a partir de especificações abstratas das regras do negócio. O objetivo da ADM (MDA ao contrário, se vocês ainda não perceberam) é fornecer padrões e modelos para engenharia reversa de softwares legados. Ah, ADM significa Architecture-Driven Modernization.

Vocês (principalmente o pessoal de rejuvenescimento de software) podem encontrar mais informações no site da ADM.

Fontes: Wikipedia
adm.omg.org

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.