[Pesquisar este blog]

quinta-feira, 16 de fevereiro de 2017

MDA::Uma visão geral::Vantagens & Desvantagens (parte III)

Parte I::ApresentaçãoParte II::Desenvolvimento | Parte III::Vantagens&Desvantagens
Como qualquer outra tecnologia, a utilização da Model Driven Architecture (MDA) proporciona uma série de vantagens, mas também possui desvantagens. Conhecer então seus pontos fracos e fortes possibilita explorar todo o seu potencial em favor da solução dos problemas enfrentados.

Benefícios da utilização da MDA

Através do emprego da MDA espera-se obter os seguintes benefícios: produtividade, portabilidade, interoperabilidade, manutenabilidade, teste e validação e documentação.

Produtividade. Na MDA o foco da atividade de desenvolvimento é deslocado para a construção do Platform Independent Model (PIM), pois os Platform Specific Model (PSM) deverão ser obtidos através de transformações automáticas suportadas pelas ferramentas MDA. Embora as transformações envolvidas sejam complexas, requerendo especialistas em sua especificação, depois de definidas podem ser aplicadas em diferentes contextos, possibilitando o retorno do investimento em termos de produtividade. Eventualmente algumas transformações comuns na indústria podem ser adquiridas ou mesmo colocadas em domínio público. Outro ganho possível se relaciona ao fato da construção do PIM não envolver detalhes específicos de implementação, concentrando a atividade na correta definição do sistema. Além disso, a quantidade de código que deverá ser manualmente gerada é reduzida [3].

Portabilidade. Como um mesmo PIM pode ser transformado em diferentes PSMs, possibilitando que um sistema possa operar em diferentes plataformas, então a construção do PIM é portável para qualquer plataforma para a qual exista a definição da transformação PIM para PSM especificamente envolvida [3]. Para plataformas menos populares é possível a definição particular das transformações desejadas, assim como o surgimento de novas plataformas irá requerer apenas a definição do mapeamento específico, o que em tese maximiza a portabilidade de qualquer PIM com relação as tecnologias atuais e futuras [1][8].

Interoperabilidade. Os PSMs dirigidos para plataforma diferentes não são interoperáveis diretamente. Mas para não deixar esta questão em aberto, a MDA também prevê a existência de bridges entre os PSMs e também entre o código de cada plataforma. A própria geração destas bridges pode ser automatizada pois é conhecida a origem de cada elemento do PSM em termos de sua definição no PIM e, por conseguinte, qual o elemento correspondente no outro PSM de interesse sistemas legados podem ser integrados através de adaptadores (wrappers) especificados em termos da MDA [1]. Um PIM baseado em uma máquina virtual não exigirá transformações, mas sim o PIM da máquina virtual, o qual deverá ser mapeado em um PSM destinado a uma plataforma específica, mantendo o sistema independente de plataforma e interoperável naquelas aonde exista uma máquina virtual apropriada [5].

Manutenabilidade. Através de alterações no PIM do sistema é possível a geração de novos PSMs e código correspondente muito rapidamente, agilizando e barateando os procedimentos de manutenção do sistema. Com isto correções, adaptações ou mesmo a adição de novas funcionalidades tornam-se tarefas mais simples de serem realizadas, prolongando a vida útil do sistema [1]. Espera-se que boas ferramentas MDA permitam manter a correspondência adequada entre PIM e PSM nas situações em um ou outro destes modelos sejam modificados.

Teste e Validação. Da mesma forma que os modelos construídos podem ser automaticamente transformados em outros modelos e também em código, é possível que sejam validados segundo critérios pré-definidos e também testados dentro dos parâmetros das plataformas em que deverão operar [5]. Isto também abre algumas possibilidades em termos de simulação, reforçando o grande potencial da MDA na geração de sistemas mais robustos, portáteis e adequados as necessidades identificadas.

Documentação. A MDA é baseada na construção de modelos formais, que sob muitos aspectos correspondem a uma importante documentação do sistema. O PIM é o artefato mais importante, pois corresponde a uma documentação de alto nível [8]. Além disso, como tais modelos podem ser visualizados, armazenados e processados automaticamente, não são abandonados após a finalização do sistema, pois tanto o PIM, no nível de abstração mais alto, quanto o PSM, num nível de abstração intermediário, podem ser reutilizados para a incorporação de alterações no sistema ou mesmo sua migração para outras plataformas. Embora a formalização dos modelos necessários a MDA cumpra o papel de documentação do sistema, outras informações deverão ser adicionadas aos modelos, tais como os problemas e necessidades diagnosticadas bem como o racional das escolhas efetuadas [3].

Tais benefícios se refletem diretamente na redução dos custos de desenvolvimento, redução do tempo de desenvolvimento, aumento da qualidade das aplicações produzidas, aumento do retorno dos investimentos realizados e aceleração do processo de adoção de novas tecnologias, bem como simplificação dos problemas associados com a integração de sistemas [11].

Também se enfatiza o fato  dos modelos da MDA serem exibidos num maior ou menor nível de detalhes, permitindo a análise, conversão e comparação de modelos. Além disso, o mapeamento explícito entre os modelos, que possibilita sua transformação automática, permite a rastreabilidade e controle de versão dos artefatos utilizados [4].

A aplicação de padrões de projeto também é um dos benefícios a serem obtidos com a MDA, pois na transformação PIM para PSM é possível que padrões conhecidos possam ser aplicados no sistema em questão [5], automatizando algumas das etapas de construção dos componentes do sistema na tecnologia escolhida [14].

Booch [8] defende o emprego da MDA afirmando que seus praticantes não necessitam ser profissionais altamente gabaritados em UML, cujo trabalho iterativo em equipe deverá resolver as questões mais sérias das abstrações envolvidas na elaboração do PIM. Também argumenta que o uso de padrões de projeto é favorecido, que os ganhos em portabilidade e interoperabilidade são enormes e que com o desenvolvimento das ferramentas MDA os ganhos serão ainda maiores.

Outros aspectos, menos tangíveis, são: que a modelagem em alto nível favorece as tarefas de validação, pois os detalhes de implementação não estão inclusos no PIM; que a aplicação ou integração de plataformas diferentes tornam-se mais claramente definidas, facilitando a produção de implementações particulares [4].

Dificuldades na aplicação da MDA

A UML é uma linguagem de modelagem, que originalmente se destinava a oferecer uma forma visual de comunicação para representação dos principais conceitos e elementos de um sistema. Embora seja utilizada amplamente pela indústria de desenvolvimento de software, que reconhece suas muitas qualidades, deixa algumas lacunas: não possui uma semântica completamente formalizada, o que deixa brechas para diferentes interpretações e implementações de suas representações; não existe uma implementação de referência cuja semântica permita garantir a correta interpretação e transformação de seus modelos; não possui um formato de intercâmbio definido, o que dificulta o compartilhamento de seus modelos entre as ferramentas que a suportam; e requer o uso de várias outras linguagens de extensão para que sejam expressos elementos que não fazem parte do seu escopo (as restrições de atributos, por exemplo) ou para que seja armazenada e processada [15][9][17].

Apesar dos argumentos da “engenharia de modelagem”, um meta-modelo [9], tal como o PIM, permite a adição de novas funcionalidades com relativa facilidade, mas por si só não garante que tais funcionalidades se articulem de modo coerente. Assim continua nas mãos dos projetistas avaliar e garantir tal consistência, o que continua a exigir a alocação de profissionais experientes, onde percebemos que a MDA não contribui de forma efetiva neste sentido. COOK [18] argumenta que a neutralidade do PIM em termos de plataforma poderá significar, em última instância, perdas em termos de performance, o que poderá comprometer o desenvolvimento de sistemas com alto volume de transações ou em tempo real. Conforme MEDVIDOVIC et al. [19], apenas a UML não é suficiente para “capturar” todos os aspectos necessários a modelagem de uma arquitetura de software completa, necessitando de extensões ADL (Architecture Description Languages). O direcionamento da modelagem para domínios específicos (domain specific modeling) poderia trazer ganhos para MDA [7][18][20] possibilitando a geração de aplicações melhor ajustadas para suas efetivas condições de utilização.

Existem ainda as dificuldades na transformação PIM para PSM, pois além da oferta de uma enorme diversidade de plataformas (CCM, JavaEE, .NET [21], etc.), se tal transformação não for precisa o suficiente, a geração de código não será possível ou não produzirá os ganhos de produtividade esperados. Cada uma destas plataformas possui uma API bastante ampla, complexa e nem sempre bem documentada, é muito difícil a construção dos (standard mapping) para realização das transformações automáticas. Efetivamente só foram demonstrados os mapeamentos para CORBA [22][23] e JavaEE [14][18]. Existem sérias dúvidas quanto a capacidade e interesse da indústria de TI na confecção de UML profiles para todos os domínios específicos [15]. Ainda nesta questão, FOWLER [18] não vê ganhos adicionais da MDA quando comparada com os resultados do desenvolvimento sustentado por padrões, bibliotecas e frameworks.

Observamos também que dentre as diversas ferramentas oferecidas pelos inúmeros fornecedores que “adotaram” a MDA, nenhuma é capaz de realizar completamente as transformações entre PIM e PSM, ou mesmo efetuar a geração de código a partir do PSM, pelo menos não como idealizado pela proposta desta arquitetura. Efetivamente as ferramentas existentes apenas adaptam os métodos de trabalho previamente existentes numa “roupagem” MDA. Este cenário é desconfortável, pois remete a uma situação semelhante durante a década de 80, quando muito foi “prometido” para as ferramentas CASE (Computer Aided Software Engineering) e efetivamente pouco foi implementado e disponibilizado, mesmo que comercialmente [9][17][18].

Percebemos, finalmente, que nos mesmos argumentos que incentivam o uso da MDA residem algumas dúvidas, bastante sérias, quanto aos ganhos que podem ser obtidos.

Conclusões

A proposta da MDA é oferecer meios concretos para melhorar a produtividade, portabilidade, interoperabilidade, manutenabilidade e documentação de sistemas. Para isto esta arquitetura estabelece seu foco na modelagem da funcionalidade e comportamento de aplicações e sistemas distribuídos, separando os aspectos particulares das tecnologias que serão de fato usadas em sua implementação. Desta maneira é necessária a criação de modelos detalhados e representativos dos aspectos funcional-comportamental e tecnológico, onde se posiciona a UML e as demais linguagens que sustentam a MDA.

A UML, elemento central para a construção de modelos MDA, provê uma grande variedade de elementos para o projetista de software, tais como múltiplas visões inter-relacionadas do sistema, uma semântica que permite a expressão de meta-modelos e uma série de linguagens de extensão que permitem suprir outras necessidades. Mas como discutido, além de sua complexidade, a UML ainda não permite a definição semanticamente completa de modelos para qualquer domínio.

Embora seja coerente a proposta da OMG na utilização de outras linguagens complementares para expressão, armazenamento e processamento dos modelos necessários a operacionalização da MDA, isto adiciona uma complexidade indesejável ao processo.

Outro benefício proposto é a automação da tarefas de transformação através do emprego de técnicas de mapeamento dos modelos, mas neste ponto também residem dúvidas sobre a real capacidade das ferramentas oferecidas hoje e nos próximos anos, o que compromete parcialmente os ganhos prometidos.

Considerando este contraponto, concluímos que o principal benefício da MDA é, efetivamente, os ganhos de qualidade e neutralidade proporcionados pelas atividades de modelagem, especialmente quando realizada independente da plataforma. A automatização do processo de transformação destes modelos em outros tecnologicamente particularizados poderá trazer grandes ganhos, justificando os trabalhos de pesquisa realizados nesse sentido. Até lá, vale a pena utilizar os conceitos da “engenharia de modelagem”, mesmo que seus procedimentos sejam efetuados manualmente.

MDA::Uma visão geral

Versão adaptada do artigo de JANDL JUNIOR, P.. Uma análise da OMG Model Driven Architecture. Análise (Jundiaí), v. 11, p. 35­49, 2005. 

Para Saber Mais

(A numeração dos itens não é sequencial, pois só constam os elementos citados.)
  • [1] SOLEY, Richard. & OMG Staff Strategy Group. Model Driven Architecture. Object Management Group White Paper, 2000. Disponível em: http://www.omg.org/mda/mda_files/model_driven_architecture.htm, recuperado em 02/01/2017.
  • [3] KLEPPE, Anneke, WARMER , Jos & BAST, Wim. MDA Explained: The Model Driven Architecture - Practice and Promise. Addison-Wesley, Reading, MA, 2003.
  • [4] MILLER, Joaquin & MUKERJI, Jishnu. Model Driven Architecture (MDA). Object Management Group Architecture Board ORMSC. 2001. Disponível em: https://pdfs.semanticscholar.org/fab3/6d29bd18fe7743ab710caf9faacb495f10d7.pdf, recuperado em 26/10/2004.
  • [5] MILLER, Joaquin & MUKERJI, Jishnu (eds). MDA Guide Version 1.0.1. Objetc Management Group. 2003-05-01. Disponível em: http://www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf, recuperado em 02/01/2017.
  • [7] MELLOR, S., SCOTT, K., UHL, A., WEISE, D.. MDA Distilled. Addison-Wesley, Reading, MA, 2004.
  • [8] BOOCH, Grady. MDA: A motivated manifesto IN Dr. Dobb's Magazine. 2004-08-01. Disponível em: http://www.drdobbs.com/architecture-and-design/mda-a-motivated-manifesto/184415169, recuperado em 02/01/2017.
  • [9] THOMAS, D.. MDA: Revenge of the modelers or UML utopia? IN IEEE Software, pages 22–24, May-Jun 2004.
  • [11] OMG. MDA (Model-Driven Architecture) Executive Overview. On-line: http://www.omg.org/mda/executive_overview.htm, recuperado em 02/01/2017. 
  • [14] ALEXANDRE, T.. Using design patterns to build dynamically extensible collaborative virtual environments. IN Proceedings of the 2nd international conference on Principles and practice of programming in Java, pages 21–23. Computer Science Press, Inc., 2003.
  • [15] THOMAS, D.. Unified or universal modeling language? IN Journal of Object Technology, 2(1):7–12, Jan-Feb 2003.
  • [17] FOWLER, Martin. Model Driven Architecture. On-line: http://martinfowler.com/bliki/ModelDrivenArchitecture.html, recuperado em 02/11/2004, 2004.
  • [18] COOK, S.. Domain-Specific Modeling and Model Driven Architecture. On-line: http://www.bptrends.com/publicationfiles/01-04\%20COL\%20Dom\%20Spec\%20Modeling\%20Frankel-Cook.pdf, recuperado em 02/11/2004. MDA Journal, 2004.
  • [19] MEDVIDOVIC, N, RESENBLUM, D. S., REDMILES, D. F., ROBBINS, J. E.. Modeling software architectures in the unified modeling language. IN ACM Transactions on Software Engineering and Methodology (TOSEM), 11(1):2–57, 2002.
  • [20] AGRAWAL, A.. Metamodel based model transformation language. IN Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 386–387. ACM Press, 2003.
  • [21] MICROSOFT. Microsoft .NET Platform. On-line: http://www.microsoft.com/net/, recuperado em 28/09/2004.
  • [22] OMG. UML Profile for CORBA. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/profile_corba.htm, recuperado em 22/10/2004.
  • [23] OMG. Common Object Request Broker Architecture. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/corba_iiop.htm, recuperado em 26/10/2004

terça-feira, 14 de fevereiro de 2017

Cursos Gratuitos na USP

A Universidade de São Paulo disponibiliza uma série de cursos on-line, gratuitos, por meio da plataforma VEduca. É uma oportunidade muito interessante para estudar diversos conteúdos (Física, Saúde, Economia, Inovação, Gerenciamento de Projetos...) de maneira confortável e sem custos. Basta um tantinho de organização e alguma dedicação.

Segue a lista. Escolha um curso e ... aprenda!

  1. Física Básica
    http://www.veduca.com.br/cursos/gratuitos/fisica-basica
  2. Gestão de Projetos
    http://www.veduca.com.br/assistir/gestao-de-projetos
  3. Engenharia Econômica
    http://www.veduca.com.br/assistir/engenharia-economica
  4. Princípios de Sustentabilidade e Tecnologias Portadoras de Inovação
    http://www.veduca.com.br/assistir/principios-de-sustentabilidade-e-tecnologias-portadoras-de-inovacao
  5. Gestão do Desenvolvimento de Produtos e Serviços
    http://www.veduca.com.br/assistir/gestao-do-desenvolvimento-de-produtos-e-servicos
  6. Liderança, Gestão de Pessoas e do Conhecimento para Inovação
    http://www.veduca.com.br/assistir/lideranca-gestao-de-pessoas-e-do-conhecimento-para-inovacao
  7. Gestão da Inovação
    http://www.veduca.com.br/assistir/gestao-da-inovacao
  8. Medicina do Sono
    http://www.veduca.com.br/assistir/medicina-do-sono
  9. Oceanografia - Sistema Bentônico
    http://www.veduca.com.br/assistir/oceanografia-sistema-bentonico
  10. Eletromagnetismo
    http://www.veduca.com.br/assistir/eletromagnetismo
  11. Probabilidade & Estatística
    http://www.veduca.com.br/assistir/probabilidade-e-estatistica
  12. Sistemas Terra
    http://www.veduca.com.br/assistir/sistemas-terra
  13. Produção mais Limpa (P+L) e Ecologia Industrial
    http://www.veduca.com.br/assistir/producao-mais-limpa-pl-e-ecologia-industrial
  14. Instrumentos de Política e Sistemas de Gestão Ambiental
    http://www.veduca.com.br/assistir/instrumentos-de-politica-e-sistemas-de-gestao-ambiental
  15. Fundamentos de Administração
    http://www.veduca.com.br/assistir/fundamentos-de-administracao
  16. Visões do Brasil, Século XIX
    http://www.veduca.com.br/assistir/visoes-do-brasil-seculo-xix
  17. Escrita Científica: Produção de Artigos de Alto Impacto
    http://www.veduca.com.br/assistir/escrita-cientifica-producao-de-artigos-de-alto-impacto
  18. Escrita Científica
    http://www.veduca.com.br/cursos/gratuitos/escrita-cientifica
  19. Tópicos de Epistemologia e Didática
    http://www.veduca.com.br/assistir/topicos-de-epistemologia-e-didatica
  20. Atualidade de Sérgio Buarque de Holanda
    http://www.veduca.com.br/assistir/atualidade-de-sergio-buarque-de-holanda
  21. Economia Monetária - Moeda e Bancos
    http://www.veduca.com.br/assistir/economia-monetaria-moeda-e-bancos
  22. Empirismo e Pragmatismo Contemporâneos
    http://www.veduca.com.br/assistir/empirismo-e-pragmatismo-contemporaneos
  23. Filosofia e Intuição Poética na Modernidade
    http://www.veduca.com.br/assistir/filosofia-e-intuicao-poetica-na-modernidade
  24. Ciência Política: Qualidade da Democracia
    http://www.veduca.com.br/assistir/ciencia-politica-qualidade-da-democracia
  25. História do Brasil Colonial II
    http://www.veduca.com.br/assistir/historia-do-brasil-colonial-ii
  26. Enunciação
    http://www.veduca.com.br/assistir/enunciacao
  27. Libras
    http://www.veduca.com.br/cursos/gratuitos/libras

Além destes cursos, existem outros. Basta explorar a plataforma VEduca!

quinta-feira, 9 de fevereiro de 2017

MDA::Uma visão geral::Desenvolvimento (parte II)

Parte I::Apresentação | Parte II::Desenvolvimento | Parte III::Vantagens&Desvantagens
O ciclo de desenvolvimento de sistemas através da Model Driven Architecture MDA é relativamente semelhante a outros processos de desenvolvimento de software, ou seja, compreende fases de levantamento de requisitos, análise, projeto (ou modelagem), codificação, teste e implantação.

Desenvolvimento com MDA

Uma das maiores diferenças do processo MDA em relação a outros reside na natureza dos artefatos criados durante a etapa de desenvolvimento.Segundo a especificação MDA tais artefatos devem ser modelos formais que possam ser processados automaticamente [3]. Existem três modelos ou visões (viewpoints) na MDA:
  • Modelo computacional independente ou Computacional Independent Model (CIM);
  • Modelo independente de plataforma ou Platform Independent Model (PIM); e
  • Modelo específico de plataforma ou Platform Specific Model (PSM).
O código (code), embora não constitua um modelo propriamente dito, também é um elemento importante nesta arquitetura, pois representa seu resultado concreto, como veremos adiante.


Modelo computacional independente (CIM)
O Computacional Independent Model (CIM) representa uma visão do sistema de um ponto de vista estritamente computacional e independente em termos de plataforma, que descreve apenas os requisitos gerais de funcionamento do sistema, isto é, não exibe detalhes da estrutura dos sistema, mas considera um determinado tipo de sistema cujo ambiente possui necessariamente características comuns a outros sistemas do mesmo domínio computacional. Por isso também é denominado modelo de domínio (domain model) ou modelo de núcleo (core models) [1][5]. Sistemas em tempo real possuem requisitos bastante distintos de sistemas transacionais ou sistemas distribuídos baseados em componentes, assim a primeira visão do sistema deverá considerar em qual destes domínios se dará sua operação. Embora esta visão contenha informações importantes, não é tratada usualmente como um elemento essencial, diferente do PIM e PSM, que são fundamentais na MDA.

Modelo independente de plataforma (PIM)
O primeiro artefato especificado pela MDA é o Platform Independent Model (PIM) ou modelo independente de plataforma, cujo alto grau de abstração deve permitir representar o sistema de modo independente de qualquer tecnologia de implementação. O PIM é um modelo declarativo formal da estrutura funcional do sistema [4], ou seja, tem foco na operação do sistema e, por isso, deve oferecer a melhor descrição possível para suportar o negócio em questão, mas sem considerar qual plataforma será utilizada ou como tal sistema será construído [3][6], ou seja, é neutro tecnologicamente. É um modelo destinado a preservar a informação essencial a respeito do projeto da aplicação, sua arquitetura e infra-estrutura [8].

O PIM também constitui um modelo bastante rico em termos semânticos, pois pode ser representado gráfica ou textualmente em termos da UML e suas extensões (tais como a Object Constraint Language - OCL - que facilita a indicação de restrições), dando ao projetista meios de expressar mais precisamente suas intenções e, com isso, reduzindo o trabalho das etapas posteriores. Outro aspecto importante é que o PIM poderá armazenado em um repositório através da  Meta Object Facility (MOF), possibilitando sua recuperação e processamento posteriores.

Modelo específico de plataforma (PSM)
O segundo artefato determinado pela MDA é o Platform Specific Model (PSM) ou modelo específico de plataforma. Este modelo, também expresso através da UML, deve representar o sistema em termos de construções apropriadas de uma tecnologia particular, ou seja, considerando a operação descrita pelo PIM e também detalhes específicos da implementação em termos da tecnologia selecionada [3][4][5][6]. Assim um PSM voltado para a tecnologia EJB descreverá o sistema utilizando suas estruturas, tais como home interface, session bean ou entity bean; enquanto um PSM voltado para Web Services incluirá termos como SOAP, provider ou XML schemas. Um PSM será, como um PIM, também armazenado em repositório através da MOF.

Cada PSM deve ser o resultado de uma transformação automática do PIM em termos de uma tecnologia específica (standard mapping), implicando que um mesmo PIM pode originar diferentes PSM, conforme as transformações aplicadas [1][3][6]. Isto significa que uma determinada plataforma deverá ser escolhida, implicando na seleção de mecanismo de mapeamento particular, para a transformação de um artefato PIM em um PSM. A transformação de um PIM em um PSM CORBA[22] exigiria a escolha de elementos específicos definidos num UML profile [4], onde as classes UML representariam as interfaces, tipos e outras construções do CORBA [23] através de estereótipos (stereotypes).

A operação de transformação de um PIM em um PSM é o passo crucial do processo de desenvolvimento MDA [3], pois representa o maior ganho oferecido dado que é relativamente comum que um mesmo sistema tenha que operar em diferentes plataformas, evitando a repetição dos esforços de desenvolvimento [6].

Código

O código é o produto final da MDA e deve ser o resultado da transformação de um dado PSM considerando uma tecnologia de implementação específica. A geração de código é uma etapa relativamente simples dada a proximidade do PSM com a tecnologia particular em uso [3]. Em algumas circunstâncias, quando existir suporte para múltiplas linguagens de programação deverá ser efetuada a seleção da linguagem de implementação desejada. Além do código também poderão ser gerados outros artefatos necessários ao sistema, tais como arquivos de configuração, entradas de registro, scripts, etc.

Após a geração do código será provável a necessidade de alguns ajustes e complementações, que deverão ser feitos por uma equipe de programação, mas espera-se que em quantidades bastante menores do que com as atuais ferramentas.

Transformações automáticas

O grande diferencial da MDA reside na forma de realização das transformações entre os modelos PIM, PSM e o código. Tradicionalmente as transformações entre modelos de um processo de software são realizadas manualmente. Diferentemente na MDA, os modelos deverão ser usados para geração automática da maior parte do sistema [6]. Na MDA todas transformações devem ser realizadas automaticamente por ferramentas apropriadas, o que pode significar maior rapidez e flexibilidade na geração de aplicações de melhor qualidade, caracterizando assim os benefícios imediatos de sua aplicação [3]. As transformações entre modelos ou mapeamento (mappings) são entendidas como o conjunto de regras e técnicas aplicadas em um modelo de modo que seja obtido um outro com as características desejadas. A MDA considera a existência de quatro tipos de transformações diferentes [4]:
  • PIM para PIM. Utilizada para o aperfeiçoamento ou simplificação dos modelos sem a necessidade de levar em conta aspectos dependentes de plataforma.
  • PIM para PSM. Transformação “padrão” do modelo independente de plataforma para outro específico durante o ciclo de desenvolvimento típico de aplicações.
  • PSM to PSM. Esta transformação permite a migração da solução entre plataformas diferentes, bem como o direcionamento de partes da implementação para tecnologias específicas, usadas por questões de interoperabilidade ou benefícios obtidos através do uso de certas plataformas.
  • PSM to PIM. Quando é necessário obter-se uma representação neutra em termos de tecnologia de soluções específicas.
Entre as transformações pode existir o processo de marcação (marking), que constitui uma forma “leve” e pouco intrusiva de extensões dos modelos com elementos voltados a facilitar uma transformação particular [7]. Por exemplo, um PIM (sem marcações) pode receber anotações destinadas à uma plataforma A ou B, originando marked PIMs e mantendo o PIM original sem qualquer “contaminação”.

Embora hoje existam muitas ferramentas capazes de gerar algum código a partir de modelo particulares, usualmente tal código é pouco mais que um “esqueleto” (um template), exigindo que a finalização da implementação seja feita através de atividades de programação convencional. Atualmente [3] não dispomos de ferramentas que sejam capazes de realizar completamente a transformação PIM para PSM e deste para código, requisitando a intervenção manual de programadores para finalização dos modelos e da codificação, mas que as ferramentas MDA existentes são capazes de gerar protótipos funcionais, embora simplificados, do sistema acelerando o ciclo de desenvolvimento. As transformações completas são possíveis em ambientes dotados de restrições [4], dentre as quais: ausência de legados a considerar; o modelo de partida é semanticamente rico; e os algoritmos de transformação são de alta qualidade.

A geração de código não é considerada o aspecto mais importante da MDA [3][4], pois este é bastante próximo à estrutura declarativa e atributos, sendo simples a estrutura funcional de métodos de acesso (setter and getter methods), por outro lado é bastante complexa a geração das características comportamentais do sistema como um todo. Exatamente por isso, projetistas que utilizam a MDA não devem esperar que a primeira versão gerada para o sistema seja perfeita, pois o próprio processo MDA assume a necessidade de múltiplas iterações entre o projeto e a implementação obtida, ou seja, a necessidade de refinamento como meio de produzir-se sistemas de qualidade [4][12].

MDA::Uma visão geral

Versão adaptada do artigo de JANDL JUNIOR, P.. Uma análise da OMG Model Driven Architecture. Análise (Jundiaí), v. 11, p. 35­49, 2005.

Para Saber Mais

(A numeração dos itens não é sequencial, pois só constam os elementos citados.)

  • [1] SOLEY, Richard. & OMG Staff Strategy Group. Model Driven Architecture. Object Management Group White Paper, 2000. Disponível em: http://www.omg.org/mda/mda_files/model_driven_architecture.htm, recuperado em 02/01/2017.
  • [3] KLEPPE, Anneke, WARMER , Jos & BAST, Wim. MDA Explained: The Model Driven Architecture - Practice and Promise. Addison-Wesley, Reading, MA, 2003.
  • [4] MILLER, Joaquin & MUKERJI, Jishnu. Model Driven Architecture (MDA). Object Management Group Architecture Board ORMSC. 2001. Disponível em: https://pdfs.semanticscholar.org/fab3/6d29bd18fe7743ab710caf9faacb495f10d7.pdf, recuperado em 26/10/2004.
  • [5] MILLER, Joaquin & MUKERJI, Jishnu (eds). MDA Guide Version 1.0.1. Objetc Management Group. 2003-05-01. Disponível em: http://www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf, recuperado em 02/01/2017.
  • [6] SIEGEL, Jon. Developing in OMG’s New Model-Driven Architecture. Object Management Group White Paper, 2001. Disponível em: https://www.icmgworld.com/corp/developer/whitepapers/UsingMDA.pdf, recuperado em 02/01/2017.
  • [7] MELLOR, S., SCOTT, K., UHL, A., WEISE, D.. MDA Distilled. Addison-Wesley, Reading, MA, 2004.
  • [8] BOOCH, Grady. MDA: A motivated manifesto IN Dr. Dobb's Magazine. 2004-08-01. Disponível em: http://www.drdobbs.com/architecture-and-design/mda-a-motivated-manifesto/184415169, recuperado em 02/01/2017.
  • [12] SIEGEL, J.. Using OMG’s Model-Driven Architecture (MDA) to integrate Web Services. Object Management Group White Paper, 2004. Disponível em: http://www.omg.org/mda/, recuperado em 26/10/2004. Object Management Group White Paper, 2002.
  • [22] OMG. UML Profile for CORBA. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/profile_corba.htm, recuperado em 22/10/2004.
  • [23] OMG. Common Object Request Broker Architecture. Object Management Group White Paper, 2004. On-line: http://www.omg.org/technology/documents/formal/corba_iiop.htm, recuperado em 26/10/2004.

quinta-feira, 2 de fevereiro de 2017

MDA::Uma visão geral::Apresentação (parte I)

Parte I::Apresentação | Parte II::Desenvolvimento | Parte III::Vantagens&Desvantagens
Dentro do cenário corporativo existe uma grande preocupação quanto a preservação dos investimentos feitos no desenvolvimento do software, ou seja, a utilização de estratégias que garantam a integração dos sistemas existentes com aqueles que serão construídos; que sejam flexíveis quanto a mudanças necessárias na infra-estrutura utilizada; e que estendam o ciclo de vida das aplicações construídas, reduzindo retrabalho, custos de manutenção e aumentando o retorno dos investimentos realizados [1][2][13].
http://www.omg.org/mda/mda_audio/mda_rollovers/mda_left_new2.gif

Apresentando a Model Driven Architecture (MDA)

Projetistas experientes de aplicações usualmente investem mais tempo na construção de modelos do que em atividades de programação, pois a definição e uso de modelos precisos e completos facilitam o desenvolvimento de sistemas corporativos dentro dos prazos e custos previstos, mesmo quando tais sistemas são grandes e complexos [3]. Considerando a demanda contínua das mudanças necessárias nas aplicações corporativas e a rapidez da evolução da tecnologia, temos que o cenário de desenvolvimento de soluções de TI corporativas é bastante complicado e dinâmico, dificultando a definição de modelos abrangentes e duradouros para os sistemas necessários.

Dentro deste panorama, a OMG (Object Management Group) propôs a Model Driven Architecture (MDA), uma estratégia para a construção de sistemas de TI onde são separadas as especificação das funcionalidades do sistema da especificação da implementação destas funcionalidades em uma plataforma de tecnologia particular [5]. Segundo a OMG [11], a MDA provê uma aproximação aberta, neutra em relação ao fornecedor, para os desafios das mudanças nos negócios e nas tecnologias.

Deseja-se que a MDA seja capaz de [6]: especificar um sistema de modo independente da plataforma a ser adotada; especificar características das várias plataformas; permitir a escolha de uma plataforma particular; e permitir a transformação da especificação deste sistema numa implementação para a plataforma escolhida.

A MDA representa uma visão das necessidades de interoperabilidade expandida para abranger completamente o ciclo de desenvolvimento de aplicações [5]; e permite que os desenvolvedores construam sistemas de acordo com a lógica de negócios e os dados existentes, independentemente de qualquer plataforma particular [3], cujos detalhes tecnológicos são considerados irrelevantes na definição dos aspectos essenciais da funcionalidade desejada [4].

Como as novas tecnologias vêm oferecer benefícios tangíveis para as companhias, muitas destas não podem “se dar ao luxo” de não empregar as inovações disponíveis [3], assim a MDA foi concebida para auxiliar tais organizações na adoção rápida de novos conceitos e soluções tecnológicas, sem necessitar reconstruir inteiramente seus sistemas, pois é neutra em termos de linguagem, plataforma e fornecedor [1][2]. Novos sistemas podem então ser construídos com middlewares mais atuais, sem comprometer sua interoperabilidade com sistemas existentes [6].

A MDA é um framework para desenvolvimento de software centrado na definição de modelos formais, cuja chave de sua compreensão e utilização é a importância dos modelos durante o processo de desenvolvimento de software. Dentro da arquitetura proposta pela MDA o processo de desenvolvimento de software é dirigido completamente pelas atividades de modelagem do sistema em diferentes níveis de abstração [3][7].

O framework MDA é baseado grandemente na Unified Modeling Language (UML) e também em outros padrões adotados pela indústria de software, tais como a Meta-Object Facility (MOF), Common Warehouse Meta-model (CWM) e XML Metadata Interchange (XMI). A UML é uma linguagem de modelagem de sistemas, cujo padrão é composto por uma linguagem gráfica e textual bem definida, adotado de fato pela indústria. O papel da UML é especificar a estrutura, funcionalidade e comportamento dos sistemas. A MOF também tem papel central na MDA, pois unifica a notação da UML [8][9], além de especificar a gerência dos modelos nos repositórios. A CWM padroniza a representação de modelos de bancos de dados (schemas) e suas transformações, bem como modelos para On-Line Analytical Processing (OLAP) ou mineração de dados (data mining). Já a XMI corresponde a um formato de troca para modelos baseado na MOF e também no XML. Tais padrões permitem a visualização, o armazenamento e a troca de projetos de software e modelos [1][3][6].

Mas diferentemente dos modelos puramente UML, a proposta da MDA é promover a criação de modelos abstratos que possam ser processados automaticamente (machine-readable models), desenvolvidos independentemente das tecnologias de implementação e também armazenados em repositórios padronizados. Ferramentas apropriadas (MDA tools) poderiam acessar tais modelos, transformando-os automaticamente em esquemas, esqueletos de código, código integrável, scripts de implantação, entre outros elementos [3].

Um dos caminhos possíveis de evolução tecnológica a partir da orientação a objetos é o que poderia ser chamado “engenharia de modelagem” [10], que dá aos modelos o status máximo, tal como anteriormente feito para as classes e objetos. A mudança essencial reside no fato de tais modelos deixarem de ser apenas peças de documentação, passando a ser usados diretamente para conduzir uma nova geração de ferramentas. A “engenharia de modelagem” trata o desenvolvimento de software como um conjunto de transformações sobre uma sucessão de modelos, partindo do levantamento de requisitos até a implementação e distribuição [9]. O argumento de que estas tarefas poderiam ser completamente automatizadas é sustentado por muitos daqueles que contribuíram com a definição da MDA [5].

Conceitualmente a MDA unifica e simplifica a quase totalidade das etapas do processo de desenvolvimento de software, principalmente aquelas relacionadas a modelagem, projeto, implementação e integração de aplicações, pois a definição do software se dá como um modelo funcional e comportamental separado dos elementos tecnológicos que serão posteriormente utilizados [11][12].

MDA::Uma visão geral

Versão adaptada do artigo de JANDL JUNIOR, P.. Uma análise da OMG Model Driven Architecture. Análise (Jundiaí), v. 11, p. 35­49, 2005.

Para Saber Mais

(A numeração dos itens não é sequencial, pois só constam os elementos citados.)

  • [1] SOLEY, Richard. & OMG Staff Strategy Group. Model Driven Architecture. Object Management Group White Paper, 2000. Disponível em: http://www.omg.org/mda/mda_files/model_driven_architecture.htm, recuperado em 02/01/2017.
  • [2] FRANK, Karl. Keeping your business relevant with Model Driven Architecture (MDA). Borland White Paper. 2004. Disponível em: http://www.omg.org/borland-mda-wp, recuperado em 02/01/2017.
  • [3] KLEPPE, Anneke, WARMER , Jos & BAST, Wim. MDA Explained: The Model Driven Architecture - Practice and Promise. Addison-Wesley, Reading, MA, 2003.
  • [4] MILLER, Joaquin & MUKERJI, Jishnu. Model Driven Architecture (MDA). Object Management Group Architecture Board ORMSC. 2001. Disponível em: https://pdfs.semanticscholar.org/fab3/6d29bd18fe7743ab710caf9faacb495f10d7.pdf, recuperado em 26/10/2004.
  • [5] MILLER, Joaquin & MUKERJI, Jishnu (eds). MDA Guide Version 1.0.1. Objetc Management Group. 2003-05-01. Disponível em: http://www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf, recuperado em 02/01/2017.
  • [6] SIEGEL, Jon. Developing in OMG’s New Model-Driven Architecture. Object Management Group White Paper, 2001. Disponível em: https://www.icmgworld.com/corp/developer/whitepapers/UsingMDA.pdf, recuperado em 02/01/2017.
  • [7] MELLOR, S., SCOTT, K., UHL, A., WEISE, D.. MDA Distilled. Addison-Wesley, Reading, MA, 2004.
  • [8] BOOCH, Grady. MDA: A motivated manifesto IN Dr. Dobb's Magazine. 2004-08-01. Disponível em: http://www.drdobbs.com/architecture-and-design/mda-a-motivated-manifesto/184415169, recuperado em 02/01/2017.
  • [9] THOMAS, D.. MDA: Revenge of the modelers or UML utopia? IN IEEE Software, pages 22–24, May-Jun 2004.
  • [10] BÉZIVIN, J.. From Object Composition to Model Transformation with the MDA. IN Proceedings of TOOLS’USA. IEEE Press, 2001. Disponível em: http://users.dsic.upv.es/~einsfran/mda/TOOLS.USABezivin.pdf, recuperado em 02/01/2017.
  • [11] OMG. MDA (Model-Driven Architecture) Executive Overview. On-line: http://www.omg.org/mda/executive_overview.htm, recuperado em 02/01/2017. 
  • [12] SIEGEL, J.. Using OMG’s Model-Driven Architecture (MDA) to integrate Web Services. Object Management Group White Paper, 2004. Disponível em: http://www.omg.org/mda/, recuperado em 26/10/2004. Object Management Group White Paper, 2002.
  • [13] HART, J.. Connecting your applications without complex programming. On-line: http://www.ibm.com/software/integration/wmq/, recuperado em 30/10/2004., Sep 2003. IBM White Paper.

quinta-feira, 12 de janeiro de 2017

JavaScript na JVM

O uso do JavaScript tem crescido consistentemente nestes últimos anos, tanto que a linguagem não apenas figura, mas aparece bem posicionada nos mais conhecidos rankings de utilização de linguagens de programação (TIOBE Index, GitHub PYPL, RedMonk, IEEE Spectrum, etc).


Não é preciso justificar porque o JavaScript é importante. Introduzido em 1995 por Brendan Eich, sob o nome original Mocha, acabou sendo renomeado para JavaScript para aproveitar o sucesso inicial do Java, lançado no mesmo ano. Sua característica mais marcante é trazer interatividade a páginas HTML, sendo executada pelo browser, ou seja, operando do lado do cliente.

Com o passar do tempo e apesar das críticas de muitos programadores, o JavaScript evoluiu e hoje permite o controle sofisticado do conteúdo de páginas web, permitindo a troca de estilos, a ocultação/exibição de elementos, a realização de validações e outras operações mais complexas.

A partir de 2005, com o advento do AJAX (Asynchronous JavaScript and XML), ocorre seu renascimento do JavaScript, e surgem frameworks importantes como Prototype, JQuery, Dojo e Mootools, assim como esforço consistente para sua padronização (ECMAScript 3.1 a 5.1). Hoje o JavaSript é uma linguagem de programação amplamente utilizada.

Nashorn

O Nashorn é uma implementação de um mecanismo (ou motor) de execução para linguagem de programação JavaScript integrado a plataforma Java, disponível a partir da versão 8, compatível com a especificação ECMAScript 262 v5.1, que se beneficia da enorme quantidade de ferramentas e bibliotecas disponíveis para JavaScript, possibilitando sua integração com a plataforma Java e, portanto, conjugando as vantagens destes dois mundos.

Até a versão 7 do Java, o mecanismo de execução padrão do JavaScript disponível no Java era o Rhino, baseado num projeto de mesmo nome voltado para os navegadores Mozilla. Apenas como curiosidade, a palavra nashorn significa rinoceronte em alemão e também denominou um tanque de guerra conhecido como destruidor de tanques.

O mecanismo de execução Nashorn é acessível por meio da API javax.script e da ferramenta de linha de comando jjs, suportando a execução de scripts escritos em JavaScript embutidos em programas Java, incluindo aplicações JavaFX.

A sintaxe da linguagem JavaScript é bastante semelhante a do Java e o acesso a elementos Java a partir do JavaScript, como arrays e objetos, é praticamente idêntico, de modo que o Java tem acesso a valores e elementos do JavaScript e vice-versa.

Programa Java executa script JavaScript

O exemplo que segue (classe Nashorn01) mostra um programa de console Java que utiliza o Nashorn para executar um comando JavaScript.

import javax.script.*;

public class Nashorn01 {
    public static void main(String[] arg) {
        // Obtem acesso ao mecanismo de execucao JS Nashorn
        final ScriptEngine nashorn =
               new ScriptEngineManager().getEngineByName("nashorn");
        try {
            // Script JS pode ser hardcoded ou
            // obtido por outros meios (p.e., arquivo)
            String script = "print('Hello World!')";
            // Execucao do script JS
            nashorn.eval(script);
        } catch (final ScriptException se) {
            System.out.println(se);
        }
    }
}

Na classe Nashorn01, uma instância de ScriptEngineManager é criada para que, por meio de seu método getEngineByName(String) e o nome "nashorn", se possa obter uma instância do mecanismo de execução correspondente ao Nashorn. Com o objeto ScriptEngine obtido é possível executar-se diretivas JavaScript individuais ou scripts inteiros com uso do método eval(String). É necessário monitorar tal avaliação com um try/catch.

Retorno de valor do script JavaScript para Java

Neste outro exemplo (classe Nashhor02), o script é lido de um arquivo cujo nome é fornecido como argumento para o programa. O mecanismo de execução Nashorn é obtido da mesma maneira, mas sua utilização é um pouco diferente.

import java.io.*;
import javax.script.*;

public class Nashorn02 {
    public static void main(String[] arg) {
        // Script obtido do arquivo indicado como argumento
        StringBuffer script = new StringBuffer();       
        try (BufferedReader br =
                 new BufferedReader(new FileReader(arg[0]))) {
            String line = null;
            while ( (line=br.readLine()) != null) {
                script.append(line);
                script.append("\n");
            }
        } catch (Exception exc) {
            System.out.println("Erro: " + exc);
            System.exit(-1);
        }
        try {
            // Obtem acesso ao mec. execucao JS Nashorn
            final ScriptEngine nashorn =
             = new ScriptEngineManager().getEngineByName("nashorn");
            // Execucao do script JS
            Object returnValue = nashorn.eval(script.toString());
            System.out.println("Java: " + returnValue);
        } catch (final ScriptException se) {
            System.out.println(se);
        }
    }
}

O resultado do método eval(String) é atribuído a uma variável Java do tipo Object, de modo que é possível transferir um resultado do script Javascript para o programa Java. Basta para isso que a variável cujo valor deseja-se retornar seja indicada como uma diretiva ao final do script, como no script simples que segue, onde a variável f tem seu valor retornado para o programa Java.

// teste01.js
var c = 33;
print('JavaScript: ' + c);
var f = c*9.0/5.0 + 32.0;
print('JavaScript: ' + f);
f; // retorno de valor

O valor retornado pode ser convertido em outros tipos por meio de operações de coerção, no caso, como o resultado é do tipo double, poderia ser aplicado:
double resultValue = (Double) nashorn.eval(script.toString);

Passagem de valores entre programa Java e script JavaScript

Também é possível passar valores do programa Java para o script Javascript com o uso do método put(String, Object) disponível na classe ScriptEngine. que define uma variável com o valor indicado (ou global variable binding). O exemplo que segue transfere dois valores do programa Java para o script, que soma tais valores, retornando tal resultado para o programa, usando o método get(String).

import javax.script.*;

public class Nashorn03 {
    public static void main(String[] arg) {
        // Obtem acesso ao mecanismo de execucao JS Nashorn
        final ScriptEngine nashorn =
               new ScriptEngineManager().getEngineByName("nashorn");
        // Script JS hardcoded
        String script =
               "var c = a + 2*b;\nprint('JavaScript: ' + c);";
        try {
            // Transferência de valores: programa -> script
            nashorn.put("a", 123);
            nashorn.put("b", 0.456);
            // Execucao do script JS
            nashorn.eval(script);
            // Transferência dos resultados: script -> programa
            double result = (Double) nashorn.get("c");
            System.out.println("Java: " + result);
        } catch (final ScriptException se) {
            System.out.println(se);
        }
    }
}

Script JavaScript que utiliza classes Java

Outra possibilidade interessante decorrente da integração do mecanismo de execução Nashorn na JVM é o compartilhamento da API Java por parte dos script JavaScript. Um objeto Java pode ser instanciado de duas formas:
  • Instanciação direta:var lista = new java.util.ArrayList();
  • Instanciação indireta:var AL = java.util.ArrayList;
    var lista = new AL;



As duas formas produzem o mesmo efeito. O que muda é a quantidade de código digitado: a instanciação direta é mais verborrágica, portanto, mais longa, no entanto, clara e direta; a instanciação indireta permite instanciar objetos com menos código, embora possa ser menos clara conforme os apelidos usados para as classes efetivamente usadas.

O uso dos objetos é como no Java, tal como mostrado no exemplo que segue, onde um script JavaScript utilizar uma tabela de hashing, um array elástico e um buffer para String para manipular uma lista de linguagens de programação e seus inventores.

// teste02.js
var HM = java.util.HashMap; // instanciação indireta
var map = new HM();
var list = new java.util.ArrayList(); // instanciação diretas
var buffer = new java.lang.StringBuffer("|");

map.put("JavaScript","Brendan Eich");
map.put("Java","James Gosling");
map.put("C#","Anders Hejlsberg");
map.put("Pascal","Niklaus Wirth");

for (var key in map) { print('key: ' + key); list.add(key); }
for each (var value in map) {
    print('value: ' + value);
    buffer.append(value); buffer.append("|");
}
for each (var key in list)
    print('{ ' + key + ', ' + map.get(key) + ' }');

print(buffer.toString());
list // retorno de objeto


Este script, salvo sob o nome de teste02.js, é executado com uso da classe/exemplo Nashorn02, dada anteriormente.

Console JavaScript


Junto com o JDK 8 existe um console JavaScript (uma ferramenta de linha de comando) denominada jjs que provê acesso direto ao mecanismo de execução Nashorn, comportando-se como um REPL (Read-Evaluate-Print-Loop), ou seja, um console que lê comandos JavaScript, executando-os e imprimindo os resultados no próprio console, interativa e repetidamente, o que é muito conveniente para testar comandos, executar pequenas rotinas e testes, incluindo experimentar elementos Java e JavaScript sem a necessidade de escrever programas completos.

Para acioná-la basta digitar 'jjs' (considerando que a variável de ambiente path está corretamente configurada para incluir o diretório <java_install>/bin). Considere as várias sequências que seguem de comandos que podem ser digitados no jjs. A primeira define variáveis e exibe o resultado de uma expressão:

jjs> var a = 1.5;
jjs> var b = -3;
jjs> print (2*a - 0.5*b);
4.5

Agora a definição e a exibição de um array simples:

jjs> var array = [];
jjs> array[0] = 'Peter';
Peter
jjs> array[1] = 2017;
2017
jjs> array
Peter,2017
jjs> array.length  
2
jjs> for(var i=0; i<array.length; i++) print(array[i]);
Peter
2017
jjs> for each (var v in array) print(v);
Peter
2017

Para encerrar o jjs deve ser fornecido quit().
Objetos Java podem ser instanciados e utilizados, como segue:

jjs> var list = new java.util.ArrayList();
jjs> list.add('Peter');
true
jjs> list.add('Jandl');
true
jjs> list
[Peter, Jandl]
jjs> list.size();
2
jjs> var i = 10;
jjs> for each (var v in list) { print(i + ':' + v); i = i + 10; }
10:Peter
20:Jandl
30

Características avançadas do Java, como expressões lambda e streams também podem ser usadas (com alguns cuidados). Considerando o ArrayList list definido acima, poderia ser escrito:

jjs> list .stream() .filter(function(s) s.startsWith('J')) .forEach(function(s) print(s));
Jandl
null

Neste fragmento devem ser observados alguns aspectos:
  • onde é possível usar uma expressão lambdas no Java, emprega-se uma função JavaScript; de maneira que o lambda Java
    "s -> s.startsWith('J')"
    torna-se
    "function(s) s.startsWith('J')";
  • o valor 'Jandl' é o valor resultante da exibição dos elementos filtrados do stream obtido da coleção list;
  • como o método forEach(Consumer) é terminal, seu valor de retorno é void, assim sua avaliação pelo jjs retorna null.


O modo interativo do jjs é bastante útil para experiências e testes diversos. Mas não é conveniente quando desejamos executar (ou repetir) uma sequência conhecida (ou longa) de comandos. Um conjunto de comandos JavaScript, com ou sem uso de elementos do Java, pode ser salvo num arquivo de script, o qual pode ser executado pelo jjs em seu modo de interpretação (ou batch). Para executar o script teste02.js basta escrever:

> jjs –scripting teste02.js

Conclusões

Dada a importância atual do JavaScript, sua utilização integrada à plataforma Java é bastante interessante. Assim o Nashorn é bastante útil ao permitir que programas Java utilizem funcionalidades JavaScript; que programas JavaScript compartilhem elementos do Java; que o desenvolvedor disponha de um console JavaScript para testes diversos, execução de tarefas rápidas, prototipação, teste de características do Java e construção de scripts usando Java e JavaScript combinados.
Atualmente o Nashorn (Java 8) suporta completamente o padrão ECMAScript 5.1, além de algumas extensões. Pretende-se que com o Java 9 o Nashorn seja atualizado para suportar o ECMAScript 6. Tudo muito útil e conveniente.

Para Saber Mais