Modeling Framework
A Framework de Modelação resulta da iniciativa da PRIMAVERA em 2007 para construir uma nova plataforma de desenvolvimento em .NET para construir um novo ERP, com outros paradigmas de desenvolvimento de software, de produtividade e de qualidade.
Esta framework foi construida com base em 4 conceitos fundamentais, como uma abordagem ao problema de produtividade em que vivia (ainda vive) a industria de software:
- Model-driven Software Development (ver Model-driven software development).
- Domain-driven Design (ver Domain-driven design).
- Software Factories (ver Software factory Microsoft.NET).
- Geração de código (e automação) (ver Automatic programming).
A visão por trás da framework é resumida pela seguinte frase:
The Athena Framework provides a unique business framework with tools and methods to create distinctive and high-value business applications fast and built to last, using state-of-the-art design principles and technologies.*
A Framework de Modelação faz parte da Plataforma Elevation e corresponde a uma software factory específica de domínio para construir aplicações (e módulos dessas aplicações) segundo a arquitetura Elevation.
A software factory é composta por um conjunto de designers que são extensões para o Visual Studio e que permitem modelar partes da aplicação/módulo.
Designers
Um designer é uma "área gráfica de desenho" que assenta num ficheiro específico de um projeto .NET (parte da solução do produto ou do módulo) e que permite modelar determinado(s) aspeto(s) da aplicação ou do módulo e depois gerar o código fonte correspondente.
Cada designer tem o seu próprio meta-modelo (que define aquilo que o designer permite modelar) e um modelo de objetos que representa cada instância (o modelo) e permite manipulá-lo, nomeadamente nos geradores de código associados.
A versão atual da framework inclui os 5 designers desenvolvidos com a tecnologia [Microsoft Domain-specific Language Tools] (https://msdn.microsoft.com/en-us/library/bb126327.aspx). Cada um dos designers e dos respetivos modelos tem propósitos distintos.
O ED (Entities Designer) permite construir o modelo de dados de um módulo.
A partir desse modelo são gerados vários artefactos do módulo, sendo os principais a base de dados do módulo e o modelo de objetos (entidades de negócio).
O SD (Services Designer) permite construir o modelo de serviços de um módulo.
Esses são os serviços (REST) que permitem manipular os dados do módulo (as entidades de negócio) através de uma API interna à aplicação e uma API visível externamente (a Web API) que é uma adaptação da primeira.
O PRD (Presentation Designer) permite definir a camada de apresentação (as views) de um módulo.
A partir desse modelo é gerada 100% da camada de UI do módulo, incluindo as views HTML5 e os respetivos controllers JavaScript.
O PD (Product Designer) permite definir os elementos (os módulos) de um produto (uma aplicação).
A cada produto está associado um branding diferente, bem como um menu e restrições funcionais. Os módulos podem ou não ser partilhados entre módulos (ver modularidade).
Finalmente, o MD (Menu Designer) permite, a partir dos modelos dos vários módulos do produto, construir o menu da aplicação.
Fluxo de Trabalho
Os designers estão desenhados para poderem ser utilizados intermitentemente, à medida que a aplicação vai sendo construída. No entanto, uma utilização padrão seguirá o seguinte fluxo:
- Primeiro desenha-se o modelo de dados no ED.
- Depois os serviços no SD.
- De seguida, constroi-se a camada de apresentação para esses serviços no PRD.
- Depois de construídos os modelos dos vários módulos da aplicação, deve usar-se o PD para definir os módulos que farão parte da aplicação.
- E, finalmente, constroi-se o menu da aplicação no MD.
Vantagens
Este tipo de abordagem ao desenvolvimento de aplicações, assente em modelos e geração massiva de código tem várias vantagens muito importantes:
Abstração
É um facto que os seres humanos são melhores a conceptualizar do que a realizar tarefas repetitivas. A taxa de erro aumenta drasticamente à medida que o trabalho se torna repetitivo e requer o processamento de muita informação.
Ao construir a aplicação sobre modelos, os developers concentram-se nos problemas a resolver e nos conceitos de negócio, deixando o trabalho mecânico de produzir milhares de linhas de código para a máquina (os geradores de código).
Redução da Variabilidade
A padronização é instrinseca aos modelos Athena e essa padronização reduz drasticamente a variabilidade das aplicações. Por duas vias:
- Reduzindo a liberdade de ação dos programadores, de modo que a mesma coisa seja sempre implementada da mesma forma.
- Reduzindo e simplificando os conceitos que o developer maneja para construir as soluções (há uma entidade, não uma classe C#).
Redução da Complexidade
No geral a complexida das aplicações reduz-se pelas mesmas razões. A sua manutenção torna-se menos custosa, porque os cenários diferentes são menos e mais repetitivos (logo mais fáceis de reproduzir) e, não menos importante, porque a sua correção é muito mais rápida (um problema detetado num gerador de código pode ser corrigido num único sítio e a correção ser imediatamente aplicada em vários produtos e nos vários cenários afetados em cada um desses produtos).
Aumento da Qualidade
Os defeitos reduzem-se porque as tarefas repetitivas são realizadas pela máquina, porque a intervenção do programador é menor, em menos áreas da aplicação e porque a deteção de problemas é mais eficiente.
Promoção da Velocidade
Todos os fatores anteriores contribuem para a velocidade de todo o processo, desde a construção até à manutenção. Para além de que um gerador de código é capaz de produzir um ficheiro de código de milhares de linhas em questão de segundos, milhares de vezes sem nunca se cansar.
Prototipagem
Existe, porém, uma vantagem muito mais importante nesta abordagem que se prende com a protopigem rápida das aplicações.
Quando antes seriam necessárias várias semanas até ter um protótipo executável minimamente funcional que pudesse ser apresentado a um cliente ou discutido em pormenor entre a equipa de desenvolvimento, com esta abordagem é possível que um analista (sem conhecimentos de programação) possa construir esse protótipo numa ínfima porção desse tempo.
Produzindo uma aplicação que executa (no ambiente real), ainda que não tenha praticamente nenhuma regra de negócio implementa, e que pode ser apresentada ao cliente com um aspeto muito próximo do final.
A discussão da solução com a aplicação executável, com as views praticamente finais, prova-se uma ferramenta poderosa para qualquer abordagem ágil de desenvolvimento porque permite a incorporação muito mais cedo de feedback, quando ainda não houve qualquer investimento de tempo nas componentes de programação
Mais ainda se este processo for realizado iterativa e interativamente à medida que mais funcionalidades forem sendo acrescentadas à solução.