MDA


Antes de iniciar o ultimo post sobre MDA, gostaria de informar a todos que chegamos a um número expressivo de mais de 500 “page views” (e contanto…)do nosso blog no período de 30 dias. Isso me deixou muito satisfeito e também me deu uma carga maior de responsabilidade, pois não imaginaria que tanta gente tivesse interesse nos assuntos que tenho colocado aqui. Tenho tentado postar os assuntos pelo menos duas vezes por semana, mas sinto que as vezes isso não tem sido suficiente, vou organizar melhor o meu tempo !

Dando continuidade ao tema MDA, vou falar rapidamente sobre algumas das ferramentas que implementam o MDA de forma completa (quero dizer, utilizando todos os conceitos que o MDA aborda), e uma breve descrição sobre elas, traçando um perfil de suas principais funcionalidades e comparando-as entre si, baseado num estudo de caso que fiz como parte do trabalho de conclusão da minha graduação, no qual alguns casos de uso de um projeto foram implementados.

ArcStyler 4.0
O ArcStyler 4.0 foi desenvolvido pela empresa Interactive Objects Software GmbH , sediada em Freiburg na Alemanha. Tal empresa destaca-se no meio internacional de engenharia de software como vencedora de prêmios em diversas competições de desenvolvimento de software com a utilização de MDA entre eles, Crossroads A-List Awards 2001, IBM Solution Excellence Award 2002, OMG MDA Application award winner and runner-up 2002 e Europe Information Society Tecnology Prize Award 2003 dentre outros e também fazendo parte da OMG desde 1993.
Possui suporte às principais tecnologias de mercado possibilitando a modelagem de aplicações independentes de plataforma e posteriormente a geração dos códigos fontes específicos para uma plataforma. Entre as tecnologias suportadas para geração do PSM a partir do modelo PIM estão:
· J2EE – Java 2 Enterprise Edition, exigindo o JDK 1.3 ou JDK 1.4
· EJB – Enterprise Java Beans
· Servlet 2.2 ou 2.3
· Web Services exigindo Jakarta Tomcat 4.0
· C# exigindo o .NET Framework 1.0 ou superior,
· IDL CORBA.
Os padrões do MDA estabelecidos pela OMG são utilizados em sua plenitude para possibilitar o ganho de produtividade no desenvolvimento das aplicações. Porém um item não especificado pela OMG é utilizado para possibilitar a integração e troca de informações entre os metamodelos MOF em Java, semelhante ao XMI. O JMI – Java Metadata Interface, padronizado pela Java Communit Process (JCP), possibilita o acesso e a manipulação de modelos de metadados em Java garantindo a criação e deleção de elementos nos modelos.
MDA-Cartridges são ferramentas de transformação que possibilitam a geração automática dos PSM´s e código fonte a partir dos modelos PIM. O principal benefício da utilização desta funcionalidade é a capacidade de trabalhar com diversas ferramentas de transformação para tecnologias distintas permitindo a seleção de classes de um mesmo modelo PIM para a geração de PSM´s para Java ou para C#, por exemplo.

OptimalJ 3.0
O OptimalJ 3.0 foi desenvolvido pela empresa Compuware Corporation. Destaca-se principalmente pela forte aplicação de padrões para J2EE (Java 2 Enterprise Edition) utilizando todos os conceitos de independência de plataforma que o MDA aborda. Dentre suas principais características se destacam os seguintes usos:
Modelo de Domínio para Classes (Domain Class Model) utilizando os padrões da UML para modelagem de classes;
Modelo de Domínio para Serviços (Domain Service Model) para modelagem de serviços;
Modelo para Persistência de Dados (DAO,EJB) e ferramentas de integração com outras plataformas entre as quais estão CORBA, JCA(Java Connector Architecture) e Web services, entre outras.
Outra característica muito importante que a diferencia de outras ferramentas é a utilização de um editor de regras de negócio (Business Rules Editor) que permitem o registro de regras estáticas e dinâmicas.

Todos os padrões do MDA estabelecidos pela OMG são utilizados em sua plenitude para possibilitar o ganho de produtividade no desenvolvimento das aplicações. Porém como o foco da ferramenta está em atender as especificações para J2EE, uma adaptação aos padrões do MDA foi exercida no intuito de agilizar e tornar mais fácil a modelagem de software.

imagem_optimalj.gif

São utilizados diferentes tipos de padrões: padrões de transformação e padrões funcionais. Os padrões de transformação são aplicados nos modelos PIM para gerar os PSM´s e também para converter os PSM´s em código fonte. Também compõem os padrões de transformação os padrões de tecnologia e implementação.
Os padrões funcionais de tecnologia, transformam o modelo de domínio (PIM) em um modelo de aplicação PSM (EJB,WEB,DMBS). Os padrões de implementação, por sua vez, exercem a função de transformação dos PSM´s em código fonte.

O OptimalJ permite a integração com aplicações externas entre elas JCA (Java Connector Architecture) possibilitando o acesso a aplicações distribuídas, baseadas no padrão supra citado. Também permite integração com CORBA Connector, promovendo acesso às aplicações baseadas nas compilações das versões 2.0 e 3.0 do CORBA. Por último integra-se com Web services permitindo a conexão com qualquer Web service disponível e publicado com suporte às camadas de protocolo XML Document, SOAP e HTTP.

Codagen Architect 3.2
O Codagen Architect 3.2 foi desenvolvido pela empresa Codagen Technologies Corp. em 1999, no Canadá. É membro da OMG possuindo parcerias com as principais empresas de software de mercado como Microsoft, IBM, Borland entre outras, nos esforços de implementação do MDA.
Essencialmente é uma ferramenta de transformação divida em três módulos: Codagem Architect Implement, Codagem Architect Launch from XMI e Codagem Architect Specify. Estes módulos não possuem ambiente de modelagem, mas sim, ferramentas que importam os metamodelos das principais ferramentas de modelagem do mercado, através do uso XMI e a partir disso possibilita a geração dos PSM´s para C++, J2EE e .NET( C#, VB.NET, ADO.NET, ASP.NET).

Conforme especificado na documentação do fabricante, as características de transformação a partir da leitura de modelos externos, através do uso do XMI, possibilitam integração com qualquer ferramenta de modelagem que suporte tais padrões. Essa integração foi testada com a tentativa de importação de um modelo simples com três classes de herança simples geradas nas ferramentas Magic Draw 7.5 e PoseidonEE. O resultado obtido foi satisfatório no que tange a integralidade dos atributos e métodos dos modelos. Também é possível gerar PIM´s a partir de templates adotados pela aplicação mas que são de difícil entendimento dada à notação utilizada.

Quadro Comparativo entre as Ferramentas
Na Tabela abaixo estão relacionadas às ferramentas avaliadas e as principais características e similaridades que as tornam aderentes aos padrões estabelecidos pelo MDA. A coluna marcada com “C” contempla e apresenta suporte as características e a coluna marcada com “NC” não contempla e não apresentam suporte as características.
imagem_tabela.gif

Para concluir esse tema, acho que alguém deve está se perguntando se essa tecnologia é aplicável e se realmente pode ser utilizada no mundo real?! Não existiam muitas iniciativas em relação ao uso do MDA na época que estudei o assunto(2004), porém em Pernambuco encontramos uma iniciativa pioneira nesse sentido capitaneada pela empresa In Forma Ltda, que concluiu um projeto para uma empresa de grande porte adotando, com sucesso, todos os conceitos do MDA.

Atualmente os conceitos de transformação são utilizados por diversas ferramentas de mercado, mas são poucas as que implementam o MDA puramente.

Os softwares tem sido historicamente desenvolvidos, gerenciados e integrados usando um conjunto de metodologias, ferramentas e middleware que sempre surgem para dar continuidade às inovações. Tem sido constatado ao longo dos anos, o resultado dos esforços da OMG e W3C, na padronização dos modelos semânticos e para os modelos de representação de troca de dados. Dentre as contribuições da OMG estão CORBA, UML, XMI, MOF e CWM. As contribuições do W3C incluem XML, XML Schema e XML-P para trabalho em grupo. Estas tecnologias podem ser usadas para integrar completamente a série de valores ou ciclo de vida, que serão adotadas para o desenvolvimento e distribuição de aplicações baseadas em componentes para diversas arquiteturas e plataformas de software.

O ciclo de vida de uma aplicação pode variar dependendo da necessidade de construção de uma nova aplicação ou se apenas adiciona-se um pacote de funções para uma aplicação já existente.

No modelo tradicional, mostrado na Figura abaixo, os artefatos gerados após a conclusão de cada uma das atividades e suas interações, são gerados de forma manual ou com o auxílio de ferramentas, porém, baseadas unicamente em texto, mas entre o processo de codificação e geração são necessárias novas interferências dos engenheiros de software a cada mudança de requisitos funcionais ou não-funcionais

Ciclo de vida tradicional

Essa necessidade de modificação de requisitos é intrínseca a todos os projetos, gerando redefinições de regras, atividades, estados, casos de uso e interações que serão desencadeadas até o código fonte. A demanda de re-trabalho gerada pode causar atrasos no cumprimento dos cronogramas, como também, problemas de atualização de documentação e modelos.

A Figura abaixo mostra as modificações no ciclo de vida de um projeto com a utilização do MDA. O ganho de produtividade, aderência aos requisitos e suas mudanças são facilitadas pelo uso dos modelos PIM, ferramentas de transformação e modelos PSM que garantirão de forma automática as adaptações e evoluções necessárias durante o ciclo de vida de um projeto.

Ciclo de Vida com o uso do MDA

As modificações dos requisitos que podem acontecer durante o ciclo de vida do projeto, serão re-avaliadas na fase de análise e daí por diante o processo de atualização se tornará automático com a geração do modelo PIM, seguido do PSM até o código fonte final dentro das fases do ciclo de vida.

MDA oferece suporte aos passos mais comuns existentes no desenvolvimento e distribuição de modelos de dispositivos baseados em componentes. O aspecto chave do MDA está no suporte completo ao ciclo de vida que cobre a análise e projeto, implementação, distribuição e gerenciamento. Um exemplo está no uso da UML, XMI, MOF e CWM que mudaram os conceitos de troca de informações entre ferramentas e aplicações.

As características do MDA estão baseadas nas tecnologias da OMG (MOF,UML,CWM). Estas tecnologias são utilizadas para descrever os PIM´s. Um PIM pode ser refinado e redefinido tanto quanto for necessário até que sejam obtidos todos os níveis de descrição de um sistema. Então, após a definição da infra-estrutura tecnológica, o PIM é transformado em PSM, que também pode ser redefinido quantas vezes forem necessárias

UML

A UML (Linguagem Unificada de Modelagem) é uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software. Ela proporciona uma forma padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processo de negócios e funções de sistemas, além de itens concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis.

Dentre os papeis que a UML exerce no MDA destaca-se a separação da sintaxe abstrata da sintaxe concreta, onde são definidos modelos semânticos formais. Estes modelos definem os conceitos que a modelagem UML usa e os associa a uma sintaxe abstrata ao contrário que em notações gráficas. A notação gráfica é uma sintaxe concreta que permite expressar o que está definido por meio da sintaxe abstrata.

O modelo formal de UML está definido como um metamodelo da UML. Metamodelos são como modelos de um modelo. Em um modelo de um banco incluem elementos como Conta, Cliente, Poupança. Em um modelo de um modelo incluem elementos como classes, operações, atributos, parâmetros, associações.

XMI

Adaptado e padronizado pela OMG em 1998, XMI surgiu para facilitar e acabar com as dificuldades constatadas durante os mapeamentos de modelos MOF para XML. A aplicação de XMI aos metamodelos UML produzem DTD´s (Definição de Tipos para Documentos) para troca de modelos UML. O XMI também define um conjunto de regras para a produção de documentos XML que são validados contra as DTD´s geradas. Estas regras são necessárias porque as regras de produção de uma DTD especificam somente a sintaxe XML para a representação de modelos.

O XMI é utilizado como um padrão de troca de dados utilizado entre várias ferramentas, repositórios de dados e middleware. Também podem ser utilizados automaticamente a partir de procedimentos XML-DTD e SCHEMAS, UML e modelos MOF, para possibilitar um mecanismo de serialização para estes artefatos.

MOF

MOF estabelece padrões para modelagem e construtores de troca de dados utilizados pelo MDA. Outros modelos padrões da OMG, incluindo UML e CWM, são também definidos pelos padrões dos construtores MOF. Estes padrões fornecem a base fundamental para a interoperabilidade e a troca entre os modelos e os metadados, através dos mecanismos já analisados no tópico sobre XMI.

Um metamodelo usa MOF para definição formal da sintaxe abstrata de um conjunto de construtores de modelos. Em outras palavras, com MOF define-se construtores formalmente. Um metamodelo também especifica informalmente algumas semânticas através de linguagem natural. Chama-se metamodelo MOF a combinação dessas definições formais e informais

CMW

CMW é o padrão da OMG para o armazenamento de dados. Ele cobre todo o ciclo de vida desde o projeto, construção e manutenção de aplicações de data warehouse. Possui um conjunto de metamodelos específicos para bancos de dados relacionais, multidimensionais, estrutura de registros e XML, como também, um conjunto de vários metamodelos para regras de processamento de dados como Processamento Analítico Online (OLAP), Mineração de Dados e Transformação de dados.

Transformação de dados é um requisito significante não só para o data warehouse, mas também para Enterprise Application Integration (EAI) e Business-to-Business Integration (B2Bi). As transformações necessárias podem ser a partir do formato de um banco de dados relacional (BDR) para outro, de um formato XML para outro, de um BDR para XML, de um XML para BDR ou de um banco multidimensional para BDR.

No próximo e final post sobre esse tema falarei sobre algumas ferramentas que implementam o MDA e quais os desafios para o seu uso.

Modelos UML são modelos declarativos, como por exemplo, os modelos de objetos baseados em IDL, interfaces Java e interfaces IDL Microsoft. Entretanto, modelos UML diferem destes outros tipos de modelos declarativos em importantes pontos.

O PIM é uma especificação formal da estrutura e funcionalidade de um sistema que abstrai os detalhes técnicos, possibilitando uma especificação precisa da modelagem do negócio que se pretende desenvolver. Uma visão de componentes independentes de plataforma descreve os componentes e suas interações independentemente de plataforma.

O MDA define como são os relacionamentos entres os modelos de especificação PIM, como mostra a Figura abaixo.

Modelo Consistente de Separações e Relacionamentos no MDA

Nesta Figura estão exemplificados como são os relacionamentos de refinamento entre os sistemas, através das setas duplas entre os modelos de componentes independentes e específicos de plataforma.

Da mesma forma, através de dois sistemas diferentes, sua a integração também é especificada através de uma plataforma específica, plataforma independente, e posteriormente cada negócio pode ser ajustado em diferentes níveis de modelos de abstração.

Para possibilitar a geração de um modelo específico para uma plataforma é utilizada a transformação, que funciona como uma caixa preta, transformando um modelo PIM em um modelo PSM. A Figura abaixo mostra de maneira resumida como são utilizadas as ferramentas de transformação.

Exemplo da utilização da Transformação

As ferramentas de transformação são especificadas para as plataformas desejadas através da utilização de OCL (Object Constraint Language) que garante a formalidade das regras através da UML.

 

To be continued….(3/4)

MDA é um framework de padrões estabelecido pela OMG (Object Management Group) para a modelagem de software. Um novo caminho para se especificar e construir sistemas baseados na UML, com suporte completo ao ciclo de vida de software: análise, projeto, implementação, distribuição, manutenção, evolução e integração com sistemas legados.

MDA Framework

 

Define como separar a especificação das funcionalidades dos sistemas da implementação de tais funcionalidades em uma determinada plataforma tecnológica. Também funciona como um modelo que fornece um conjunto de instruções padrões para uma especificação estruturada de software.

O MDA e os padrões que o suportam permitem que uma mesma modelagem de software que define a funcionalidade de um sistema, possa ser realizada em múltiplas plataformas através de padrões de auxilio, ou através de mapeamentos para plataformas específicas.

Também permitem que aplicações diferentes estejam integradas explicitamente, relacionando seus modelos, permitindo a evolução da interoperabilidade e suporte do sistema à integração.

Existem alguns conceitos que precisam ser contextualizados para os próximos itens a serem abordados, tais como:

Modelo: é a representação de uma parte de uma função, estrutura ou ambiente de um sistema. Abstração: Um modelo que seja baseado em critérios específicos de abstração é consultado freqüentemente como um modelo de ponto de vista definido por aqueles critérios, ou como uma visão do sistema.Linguagem de Implementação e PlataformaNo MDA, o termo plataforma é usado para referenciar os detalhes tecnológicos e de engenharia que são irrelevantes para a funcionalidade fundamental de um componente de software. Numa operação de transferência de fundos, por exemplo, a funcionalidade fundamental é a garantia de que o valor debitado de uma conta específica seja devidamente creditado na outra conta pretendida. Invariavelmente esta funcionalidade poderia ser especificada e executada por um objeto CORBA, ou uma operação SOAP, ou um Enterprise Java Bean.

Neste caso, um modelo independente de plataforma (PIM) é uma especificação formal da estrutura e funcionalidade de um sistema que abstrai os detalhes técnicos. Através desta definição, uma especificação SOAP da operação de transferência de fundos seria uma modelagem específica para esta plataforma. Uma especificação que depende de interfaces para gerar artefatos CORBA, como um ORB, serviços de objetos ou GIOP/IIOP são exemplos de modelos específicos para uma plataforma(PSM).

No próximo post, falarei sobre os segredos que são à base do negócio do MDA: PIM, PSM, OCL – Transformação e o que muda no ciclo de vida de um projeto de software com sua utilização.

Hoje resolvi colocar um post sobre um assunto que me motivou bastante há três anos atrás quando conclui minha graduação: MDA – Model Driven Architecture.

 

Um dos desafios para as empresas produtoras de software é a integração e troca de informações entre plataformas distintas. O mercado de desenvolvimento de software cada vez mais se depara com essa missão de desenvolver as soluções distribuídas para seus clientes, no menor tempo e custo possível e com qualidade.

A diversidade de plataformas tecnológicas exige, das empresas, equipes de desenvolvimento com profissionais especializados em cada uma das tecnologias existentes, elevando consideravelmente os gastos com contratação de especialistas e conseqüentemente aumentando os custos .

Outro fator a ser levado em consideração é o tempo com o qual se deve trabalhar para viabilizar tais integrações de multiplataformas. Por exemplo, qual o tempo necessário para desenvolver um software para consulta de um catálogo de produtos, para dispositivos móveis, com informações em um banco de dados relacional sediado na matriz de uma empresa e com disponibilização dessa mesma consulta para o ambiente da Intranet?

Essas novas características para os sistemas a serem desenvolvidos, como a sua capacidade de distribuição, interoperabilidade, portabilidade, escalabilidade e tolerância a falhas, exige dos engenheiros de software uma especial atenção na modelagem das soluções. O problema é que sempre que uma empresa adotar uma nova tecnologia, todo o trabalho de modelagem terá que ser refeito, e adaptado às novas características tecnológicas.

A nova realidade que faz parte do dia-a-dia da maioria das empresas de desenvolvimento de software é como reaproveitar o modelo de negócios levantado e especificado para uma tecnologia. Garantir que as mudanças para um novo contexto tecnológico, possibilitem aderência a todo o legado existente, permitindo o mínimo de acréscimos de tempo e custo aos projetos.

A modelagem de software exerce um papel de suma importância para viabilizar a integração das diversas tecnologias existentes no mercado, através da modelagem independente de plataforma.

No próximo post, vou tentar resumir e contextualizar os prinicipais conceitos a repeito dessa tecnologia.