a estrutura¸c˜ao do sistema [8].
Figura 5.7: Esbo¸co da arquitetura do projeto Open For Business
Outro fator que acelera e facilita o desenvolvimento, como dito anteriormente, ´e a quest˜ao das metadefini¸c˜oes e metalinguagens. Segundo os desenvolvedores [31], essa pr´atica permite tornar tarefas que seriam repetitivas e comuns a v´arias partes do processo de pro- grama¸c˜ao muito mais f´aceis de implementar. Garantem, ainda, que isso pode economizar entre 70 a 90% de tempo.
Por fim, al´em das camadas de apresenta¸c˜ao, servi¸cos e dados, ´e apresentada tamb´em a camada referente `as a¸c˜oes que o sistema dispara baseado em eventos e condi¸c˜oes. Ela interage com a camada de persistˆencia de dados e a de l´ogica de neg´ocios. Gra¸cas a essa ca- racter´ıstica de programa¸c˜ao orientada a eventos, ´e poss´ıvel aumentar o grau de reutiliza¸c˜ao de componentes diminuindo mais ainda o tempo de desenvolvimento e a manuten¸c˜ao de um sistema estruturado.
5.5
Processo recomendado para o desenvolvimento
A Figura 5.8 foi baseada em um diagrama presente em um dos livros de referˆencia do Open For Business [24]. Seu intuito ´e indicar qual o processo mais adequado para o ciclo de desenvolvimento de componentes dentro do contexto do OFBiz.
48 Cap´ıtulo 5. Apache Open For Business
Processo de desenvolvimento
Camada de dados
Camada da lógica de negócios
Camada de apresentação
Início
Definição das entities entitymodel.xml Definição de Entity Group entitygroup*.xml Definição de EECA eecas*.xml
Implementação dos serviços *Services.xml, *Services.java Definição
de Serviços services*.xml
Definição SECA
secas*.xml Service Groupgroups*.xml
Definição de views URLs controller.xml Screen Widget *Screens.xml BeanShell *.bsh FreeMarker *.ftl Form Widget *Forms.xml Tree Widget *Trees.xml Menu Widget *Menus.xml
5.5. Processo recomendado para o desenvolvimento 49
´
E poss´ıvel observar que a sequˆencia tida como ideal parte da modelagem da camada de persistˆencia de dados, passa pela camada da l´ogica de neg´ocios e, ent˜ao, deve terminar com a cria¸c˜ao da interface de usu´ario, o que ´e bastante natural.
Al´em disso, no diagrama da Figura 5.8 s˜ao especificados, por alto, os passos para im- plementa¸c˜ao de cada etapa. S˜ao apresentadas etapas, dentro de um fluxograma, sendo que cada uma delas cont´em os arquivos fundamentais para sua implementa¸c˜ao. O s´ımbolo as- terisco no nome dos arquivos refere-se `a conven¸c˜ao de nomes adotada no projeto. Tomando como exemplo o arquivo entitygroup*.xml, o s´ımbolo asterisco seria substitu´ıdo pelo nome do componente ou parte do nome do componente do qual o arquivo faz parte.
Para a camada de persistˆencia de dados, incia-se o trabalho com a defini¸c˜ao das tabelas e campos a serem usados, tamb´em chamado de Entity Definition. De posse das tabelas definidas, ´e poss´ıvel agrup´a-las para facilitar o acesso (Entity Group) caso sejam usados durante o desenvolvimento, v´arios bancos de dados separados. Ou seja, caso o desenvolve- dor opte pelo uso de mais de uma base de dados, o ideal ´e agrupar as tabelas em grupos definidos no arquivo entitygroup.xml para que o acesso por parte do sistema seja mais eficiente.
Ainda para a camada de persistˆencia de dados, recomenda-se que sejam definidas as a¸c˜oes a serem executadas mediante eventos e condi¸c˜oes que aconte¸cam no ˆambito das entities. Essa defini¸c˜ao poderia ser encarada tamb´em como algo relevante `a camada de l´ogica de neg´ocios, mas, quando se pensa em manter a coerˆencia entre por¸c˜oes de dados, faz sentido mantˆe-la nessa camada apenas a t´ıtulo de uma melhor documenta¸c˜ao.
Logo em seguida ´e mostrada a boa pr´atica para o desenvolvimento da camada de l´ogica de neg´ocios. Segundo a comunidade, o melhor ´e modelar os servi¸cos que ser˜ao implementados, elencando-os todos no arquivo services*.xml. Simultaneamente, indica-se que sejam agrupados (groups*.xml ) de acordo com as necessidades e ainda sejam definidas as a¸c˜oes a serem executadas de acordo com eventos e condi¸c˜oes referentes a qualquer servi¸co, atrav´es do arquivo secas*.xml.
Com todos os servi¸cos listados e especificados, a pr´oxima etapa ´e a implementa¸c˜ao, seja por meio da Mini-Language do OFBiz (*Services.xml ), classes em JAVA (*Services.java) ou mesmo por qualquer outra das op¸c˜oes dispon´ıveis no framework.
Por fim, o diagrama apresenta a sequˆencia indicada para o desenvolvimento da interface gr´afica. Em primeiro lugar, indica-se que seja constru´ıdo o arquivo controller.xml, que, como j´a foi explicado antes, ´e a fonte das informa¸c˜oes necess´arias para o sistema reconhecer requisi¸c˜oes por URLs. Na realidade, nele n˜ao s˜ao declaradas apenas as telas, mas tamb´em os servi¸cos e suas respectivas URLs. Portanto, trata-se de uma etapa de consolida¸c˜ao, por assim dizer, da cria¸c˜ao da camada de l´ogica de neg´ocios e modelagem da interface.
A partir das telas listadas no arquivo controller.xml constr´oi-se o arquivo *Screens.xml que possui a implementa¸c˜ao das telas na referida metalinguagem. A par da implementa¸c˜ao das telas s˜ao constru´ıdos, tamb´em, os arquivos referentes a formul´arios (*Forms.xml ),
50 Cap´ıtulo 5. Apache Open For Business
Menus (*Menus.xml ) e as chamadas Trees (*Trees.xml ), que s˜ao estruturas utilizadas para hierarquizar formul´arios ou regi˜oes dentro das telas.
Al´em de tais defini¸c˜oes, o diagrama indica a cria¸c˜ao de scripts em BeanShell e arquivos FreeMarker. O primeiro refere-se a scripts que facilitem a implementa¸c˜ao da interface, desde a obten¸c˜ao de dados, tratamento de informa¸c˜oes obtidas a partir de servi¸cos ou, at´e mesmo, a automatiza¸c˜ao da cria¸c˜ao de elementos como listas presentes na interface.
J´a os arquivos FreeMarker referem-se a uma t´ecnica usada para a cria¸c˜ao de templates para a interface. S˜ao, na realidade, uma alternativa `a cria¸c˜ao das telas usando a metalin- guagem baseada em XML. Apesar de constarem no diagrama, a indica¸c˜ao da comunidade ´
e que seja dada preferˆencia aos arquivos XML.