Trilha Arquitetura

Separando Negócio da Arquitetura com Modelos Executáveis
Rafael Chaves
A palestra parte da premissa que arquitetura e negócio (ou domínio do problema) são ""criaturas"" muito diferentes e que requerem técnicas, ferramentas, níveis de abstração e talentos bem particulares, mas tipicamente tais diferenças são completamente ignoradas, resultando em sistemas que custam muito mais para construir do que o esperado e são extremamente difíceis de evoluir para atender novos requisitos técnicos e de negócio. A abordagem de modelos executáveis, inicialmente promovida por Shlaer and Mellor, e hoje incorporada pela OMG em UML/MDA, fornece uma solução para esse problema, separando negócio da arquitetura, e realizando a combinação das duas dimensões de maneira automatizada. Com modelos executáveis, a aplicação é desenvolvida independentemente da arquitetura, usando uma linguagem mais rica e de mais alto nível que linguagens de implementação típicas (como Executable UML). A combinação de um modelo executável e um padrão arquitetural (ou modelo de plataforma na terminologia de MDA) pode ser feita automaticamente e quantas vezes for necessário (sempre que a aplicação precisar satisfazer novos requisitos de negócio ou técnicos). Tal abordagem oferece oportunidades interessantes: - fácilidade de evolução arquitetural - atualize o padrão arquitetural e re-gere a aplicação - suporte a padrões arquiteturais variados - iOS vs. Android vs. Javascript, GAE vs. EC2 vs. Azure, relacional vs. NoSQL - possibilidade de arqutetura como commodity - Cloudfier oferece arquitetura como serviço (AaaS) - especialização de trabalho - alguns desenvolvedores têm mais interesse em negócio ou domínio do problema), outros mais em tecnologia. As idéas promovidas serão demonstradas através do Cloudfier, um ambiente de desenvolvimento rápido que é um exemplo da abordagem de modelos executáveis. Em Cloudfier, o desenvolvedor se encarrega de definir a solução conceitual, e a arquitetura é provida automaticamente pela plataforma. Cloudfier é um serviço gratuito (para prototipação), e participantes serão convidados e encorajados a usá-lo.

Uma DSL que transformou o produto
Marcos Vinicius
1. O que é uma DSL (ver alguns livros sobre o assunto) 2. Apresentação do caso prático - Trata-se de uma DSL que iniciou timidamente e depois revolucionou o desenvolvimento, a arquitetura e o produto. 2.1. DSL como ferramenta para melhorar o desenvolvimento. - Uma linguagem é mais fácil de implementar que uma GUI, e suporta mudanças muito mais rápidamente; pode ser amigável ao usuário, e permitir que todo o back-end seja construído sem UI e o usuário ainda assim validar a lógica de negócio) 2.2. DSL como ferramenta para melhorar os testes. - Uma vez que ambientes podem ser configurados usando DSL, vários testes (funcionais, regressão, etc) podem ser configurados a partir da DSL. 2.3. Arquitetura e DSL (princípios de arquitetura de serviços) - É cada vez mais comum a idéia de você desenhar um sistema de forma que tenha uma aplicação que realize toda a lógica de negócio e oferece vários serviços para input e output de dados. Você pode orientar seu sistema de maneira que a DSL seja a linguagem que ele fala. 2.4. DSL e GUI (separação front-end e back-end) Mesma idéia dos SGBD (sistemas gerenciadores de bancos de dados): eles ""falam"" SQL e você pode trabalhar várias GUIs para interagir com eles (desde linhas de comando até ferramentas complexas como o SQLDeveloper). 2.5. DSL e o produto A DSL fornece ao produto novas features, como possibilidade de scripting (você pode ter um script de criação de um ambiente completo para sua aplicação, salvar este script e utilizar depois), templating (muitas vezes vários objetos podem ser configurados através de um só input de dados), code complete (caso seu cliente goste), APIs para delegar desenvolvimento (você cria o SQL e deixa outros implementares os editores gráficos, por exemplo). 2.6. Desenvolvendo uma DSL com Antlr4: lexer, parser, abstract syntax tree, interpreter e a conexão com um sistema.