Tecnologias


Olá pessoal,

Continuando minha tentativa de manter o blog atualizado, como prerrogativa para estudar e aprender sobre novas tecnologias , escolhi um tema interessante pra mim e espero que para vocês também.

Quem trabalha com aplicações para Internet, sabe que o grande desafio é criar uma interface bastante amigável para os usuários, apesar das limitações características ao ambiente. Existem diversas tecnologias distintas no mercado open source ou não, que atendem esses requisitos de forma desintegrada e de diversos fornecedores.

Dentro do projeto JBoss, existem diversos frameworks que compõem o JBoss AS ( Application Server ), entre os mais conhecidos estão o Hibernate, Web Services, Web,  Transactions, jBPM e o Seam.

JBoss AS

JBoss AS

O Seam integra as tecnologias mais badaladas do mercado open source como AJAX, JSF, EJB3.0 e BPM  em um único framework, para facilitar o desenvolvimento de aplicações RIA, de maneira integrada e “eliminando” a complexidade dessas APIS. Ele promete a criação de aplicações complexas com poucas classes java, interfaces com usuário poderosas e com arquivos xml de configuração.

No próximo post, vamos mostrar de forma resumida, suas principais características e como utilizá-las.

Para concluir o tema que abordamos nos ultimos dois posts, vamos falar um pouco sobre os padrões e as técnicas para adotá-los, que são tão importantes no papel do arquiteto de software.

O uso de padrões ou como é mais conhecido Design Patterns, é uma das partes mais difícieis no dia-a-dia de qualquer profissional de TI, pois a todo tempo novas abordagens surgem para otimizar ou modificar a maneira de solucionar um mesmo problema. Quando eu leio sobre uma nova tecnologia, tento listar e identificar os diferentes padrões que são utilizados e extrair qual a abordagem que a diferencia das outras ( essa parte não é fácil de implementar).

Para se definir qual o padrão ou framework a se utilizar, deve-se observar primordialmente que os melhores, são geralmente desenvolvidos de forma genérica a atender todas as possíveis abordagens, podendo assim dessa forma, incrementar a produtividade no desenvolvimento de uma solução de software, sem invenções incríveis.

Durante reuniões técnicas para discussão de um problema, deve-se evitar erros comuns, como as famosas siglas, criando uma “sopa de letras” que não permitem que todos entendam de forma clara e objetiva o que se pretende fazer, deixando na verdade, mais dúvidas que soluções nas cabeças das pessoas. Ser objetivo é o principal !

“Entender como uma tecnologia trabalha, não é o bastante para desenvolver uma solução de software robusta, entender aonde a tecnologia é aplicável numa solução, é essencial para o desenvolvimento de um produto de qualidade.”

Essa frase resume bem qual o real sentido da coisa, utilizar tecnologia por si só, não é garantia de solução para os problemas.

Com isso concluímos essa série e espero que todos tenha gostado.

Olá pessoal, estive ausente um longo tempo, pois andei extremamente ocupado com um projeto no trabalho e por isso não postei mais novos assuntos por aqui. Mas nesse longo tempo, tive oportunidade de aprender um pouco mais sobre tecnologia e especialmente sobre arquitetura de software.

Nessa última, descobri uma vertente interessante de assuntos que andei me questionando há algum tempo e que estão no topo dos foruns e revistas especializadas. Entre eles estão:

  • Qual o papel do arquiteto de software ?
  • Nós precisamos de um arquiteto de software ?
  • Tornando-se um arquiteto de software, Quais os pré-requisitos ?
  • Entre outros…

Nos próximos post’s falaremos sobre esses assuntos e também sobre tecnologia é claro !

 

Dando continuidade ao tema hibernate, neste post, vamos traçar um paralelo entre o mapeamento O/R com e sem a utilização do hibernate, mostrando os principais ganhos no uso desse framework.

Quem já trabalha ou trabalhou com java, sabe que fazer o mapeamento de objetos aos ResultSets do JDBC, com as tuplas obtidas de uma consulta em um banco de dados, é um trabalho repetitivo, criterioso e que gera muita codificação. O trecho de código abaixo dá um exemplo disso:

 

hibernatesource1.gif

 

 

Observamos que para cada elemento que será retornado do BD, uma nova instancia do objeto é criada, preenchida e adicionada a uma lista (padrão comumente utilizado em projetos). Por fim uma nova instância da coleção é criada e recebe a lista preenchida para ser retornada para quem consumiu o método. Lembrando que o consumidor do método terá que extrair dessa coleção os objetos , fazer o casting para o objeto desejado, para em seguida acessar os atributos desejados.

No trecho abaixo, agora com o Hibernate, veja como o mesmo método foi implementado:

 

 

hibernatesource2.gif

 

Observamos agora, algumas das importantes características do código utilizando Hibernate. Na linha 1, inicia-se uma transação: é aconselhável sempre se trabalhar com esse conceito permitindo o trabalho de transações integradas com o gerenciador de BD; Na linha 2, obtem-se uma sessão gerenciada pela classe utilitária HibernateUtil; Na linha 3, o objeto Criteria, permite mapear os atributos de uma classe que o engine do hibernate irá converter para uma HQL (Hibernate Query Language), semelhante a um comando SQL. Esse ponto é especial pois deixamos de trabalhar com as tabelas, ou seja, sempre nos referimos às intâncias dos objetos e seus atributos na hora de criar consultas especializadas.

Na linha 4, cria-se dinamicamente uma ordenação para o resultado da consulta, utilizando-se o método addOrder e o objeto Order ordenando ascendentemente pelo atributo da classe “descrição”; Na linha 5, a consulta é efetivamente executada, retornando uma lista de objetos do tipo da classe passada no Criteria (Produto).;Na linha 6, a sessão com o banco é liberada e por fim na linha 7, a transação é “comitada”.

Por fim, nota-se que não foi necessário fazer o trabalho de mapeamento dos dados da base para os objetos java, porque o hibernate faz isso de forma “quase automática”. E isso não é mágica, existem arquivos de configuração e mapeamento que fazem isso para o desenvolvedor.

O arquivo produto.hbm.xml(abaixo), que mapeia os atributos da classe aos atributos da tabela do BD. Alem dos arquivos de hibernate.properties e hibernate.cfg.xml que contem respectivamente as informações de acesso ao BD (usuário, senha, esquema, etc) e configurações adicionais do hibernate.

hibernatesource3.gif

No próximo e ultimo post falaremos um pouco mais sobre essas funcionalidades, mais especificamente, sobre as relações entre os objetos e suas cardinalidades e dicas de literatura para aprofundamento dos conhecimentos.
Até lá !

Dando continuidade ao tema hibernate, neste post, vamos falar um pouco sobre suaa arquitetura e suas principais caracterísiticas.

A API do Hibernate está dividida em duas camadas que são aderentes à J2EE API. Existe a camada de negócios (Business Layer) que garante o ciclo de vida dos objetos, suas validações e as classes que serão responsáveis pela persistência, a ser gerenciada pela camada de persistência (Persistence Layer).

Os componentes responsáveis pelo gerenciamento de sessão, transação, queries, fábrica de sessões e configurações são parte integrante da camada de persistência. A imagem abaixo ilustra essa arquitetura.

hibernate1.gif

É possível utilizar o Hibenate rodando em uma ambiente stand alone , como também , num ambiente gerenciável , através do uso de containers como WAS, JBOSS , BES, TOMCAT.A figura abaixo exemplifica de forma simples e objetiva como funciona o hibernate em um

ambiente não gerenciado.

hibernate2.gif

Na próxima figura , está o exemplo de como funciona o hibernate no ambiente gerenciado, adicionando as características de controle que um Aplication Server permite.

hibernate3.gif

 

Mas para que se possa utilizar o Hibernate de forma adequada e correta, é preciso entender um conceito muito importante que permeia todo o ciclo de vida de um projeto que o utilizará. Existem estados e transições que devem ser considerados como exemplificado na figura abaixo.

 

hibernate4.gif

Transiente (Transient)– o objeto ainda não foi persistido na base , ou seja, esse seu estado indica que o objeto só existem em memória.

Persistente (Persistent)– o objeto foi salvo no BD em uso, e já poderá ser acessado de lá.

Desatachado (Detached)- o objeto não é mais utilizado e será liberado para descarte pelo gerenciado de lixo (Garbage Collector)

 

Trazendo uma atualização para Java EE 5 , o Hibernate implementa Entity Mananger, Annotations , Core e Seam e para quem trabalha com .NET da microsoft o NHibernate implementa .NET 2.0 também.

 

No próximo post, faremos um exemplo prático sobre o uso do hibernate , exemplificando como seria sua utilização e mostrando a diferença para o modo tradicional de mapeamento O/R em java.

Hoje vamos iniciar uma série de três post’s falando sobre um dos principais, senão o principal, framework de mapeamento e persitência O/R para quem trabalha com Java e também .NET !

Um dos principais desafios para quem trabalha com java, por exemplo, é fazer o trabalho árduo de mapeamento dos objeto para relacional viabilizando a persistência dos dados em um BD. Existem diversos frameworks no mercado como iBatis (Projeto da Apache para mapeamento O/R para os ambientes Java e .NET) mas o mais conhecido e famoso é o Hibernate.

nHIBERNATE

Projeto do Grupo JBoss para agilizar e facilitar o mapeamento OR para Java e .NET (NHibernate), para a maioria dos BD´s de mercado (pagos ou gratuitos).

Dentre suas principais propostas está a diminuição do trabalho no mapeamento O/R, aumentando assim a produtividade, manutenibilidade, performance e independência de Bancos de Dados. Utiliza arquivos de mapeamento , no formato hbm.xml, e de configurações, no formato .properties, que permitem associar e gerir objetos às tabelas de um BD Relacional.

No próximo post falaremos a fundo sobre a arquitetura do hibernate e suas principais características….

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.

Próxima Página »