Trabalho Experimental

Este trabalho foi realizado em ambiente empresarial nas instalações da equipa R&D (Re- search & Development) da OutSystems. A fase de implementação da solução foi realizada em completa integração com a equipa responsável pelo desenvolvimento da versão 5.0 da Agile Platformseguindo metodologias ágeis de desenvolvimento de Software [41].

Numa fase inicial foi necessário compreender as funcionalidades e utilização dos diversos componentes da Agile Platform: Service Center, Integration Studio e Service Studio. Neste último foi fundamental perceber a linguagem a optimizar e as necessidades actuais, no que diz respeito a cenários de possível optimização e aos seus pós e contras. Depois do levantamento destes padrões, foram definidas prioridades e definido o rumo do projecto no sentido de optimi- zar apenas as operações de Update<Entity>.

A fase inicial do projecto foi essencialmente de pesquisa e compreensão do código existente. A Agile Platform é constituída por mais de 70 projectos em Microsoft Visual Studio 2008 numa base que supera 1 milhão de linhas de código. Foi importante focalizar o processo nas parcelas de código relevantes, nomeadamente no compilador, optimizador e geração de código.

O processo de implementação foi realizado em código sob constantes alterações provenien- tes da equipa de desenvolvimento, o que levou a trabalhar muitas vezes com versões instáveis da plataforma. Esta instabilidade foi responsável por corromper ficheiros de teste (.oml), o que implicou, a certa altura, a ter sempre uma versão estável (versão 4.2) e proceder ao respectivo upgradequando necessário. Em relação ao desenvolvimento em si, foi um processo iterativo marcado por algumas mudanças de opinião e indecisões, muitas delas em prol da usabilidade, mas também devido às delicadas decisões envolvendo alterações semânticas. O aparecimento de novos cenários de utilização que punham em causa a solução iam levando ao reforço a solu- ção e a repensar se o caminho seguido tinha sido o mais correcto. Por isso, foi importantíssimo ter por perto especialistas na linguagem para pensar nestes cenários de utilização e indicar pos- síveis falhas.

A criação de testes foi constante ao longo do desenvolvimento. Estes testes foram colocados numa máquina dedicada (Regression Tests Machine) que corre todos os dias, todos os testes de regressão existentes (cerca de 3500), de forma a mostrar como é que as alterações do dia anterior os afectaram. Isto levou a ter que perceber e aceitar (ou não) as diferenças no output de alguns deles, provocadas pelas alterações introduzidas.

Por fim, todo este esforço foi recompensado com a integração total das optimizações na base de código da versão 5.0 do Service Studio, com data de lançamento marcada para o final de 2009.

5

Conclusão

As linguagens de domínio específico, caracterizadas por elevados níveis de abstracção, apre- sentam geralmente desafios muito interessantes para optimizações. O código gerado pelo com- pilador muitas vezes não é optimizado e introduz overheads consideráveis nas aplicações finais, resultantes de redundâncias, má estruturação ou excesso de código.

Quando estas linguagens combinam lógica aplicacional com consultas e comandos sobre bases de dados, surgem situações onde a ordenação, antecipação, união ou pré-cálculo das queriespode ter impacto significativo nas aplicações. Por outro lado, a análise do fluxo de dados permite também reduzir o fluxo de comunicação entre os servidores e as aplicações aumentando assim a sua eficiência.

Neste contexto apresentámos e estudámos a linguagem OutSystems, identificando seis pa- drões de código sub-optimizados comuns nas aplicações. Para cada um destes padrões, apre- sentámos uma solução geral de optimização, assim como a análise das possíveis alterações semânticas. Devido ás limitações temporais, foi apenas possível implementar a optimização mais relevante relativa à actualização parcial de entidades na linguagem OutSystems.

Através da introdução de um algoritmo de análise de fluxo de dados no compilador, tornou- se possível propagar escritas sobre os atributos de entidades até às respectivas operações de actualização, eliminando 53% da informação que era enviada anteriormente nestas operações. Ainda em tempo de compilação, a informação dos atributos desnecessários passou a ser pro- pagada, por análise liveness, para as queries que os recolhem das bases de dados, introduzindo um ganho de 11% nos dados extraídos em consultas simples. Com esta optimização reduziu-se ainda o tamanho do Viewstate das páginas Web em cerca de 3%.

execução, dos atributos que trocaram de valor nas afectações. Esta optimização permitiu redu- zir ainda mais a informação enviada para as actualizações de entidades, embora o seu ganho potencial seja difícil de calcular sem métricas do comportamento dos utilizadores.

A correcção da solução foi validada através da implementação de um mecanismo de asser- ções que, em tempo de compilação, verifica se os atributos optimizados pelo algoritmo são os esperados. Os testes de asserções, compilação e de browser foram colocados em maquinas de testes de regressão para garantir a estabilidade desta solução.

Todos os resultados experimentais obtidos resultam da compilação sucessiva de quase 50 aplicações reais de forma a garantir que o impacto final calculado está o mais próximo possível da realidade.

Finalmente, todas as modificações realizadas no compilador no contexto da introdução de actualizações parciais de entidades, foram integradas com sucesso no código do compilador da versão 5.0 da plataforma OutSystems.