Pedro Lemos - pg10946@alunos.uminho.pt Pedro Ribeiro - pg11059@alunos.uminho.pt. Departamente de Informática Universidade do Minho Braga, Portugal

Transcrição

1 Modelação de Arquitecturas Aplicacionais no desenvolvimento de Aplicações complexas expansíveis O sistema de disponibilização de resultados eleitorais Pedro Lemos - pg10946@alunos.uminho.pt Pedro Ribeiro - pg11059@alunos.uminho.pt Departamente de Informática Universidade do Minho Braga, Portugal Resumo O suporte dos diferentes modelos eleitorais, impõe o desenvolvimento de um modelo congurável, que permita acomodar com simplicidade, as diversas legislações regionais, quer na sua organização territorial quer nos algoritmos de cálculo aplicáveis. Sendo a utilização do sistema essencialmente restrita a umas horas após o fecho do acto eleitoral, é fundamental a garantia de qualidade, robustez, redundância e escalabilidade, para cumprir o objectivo da disponibilização dos resultados. Este artigo descreve um caso de estudo, de modelação e construção de uma plataforma eleitoral, que suporte a recolha, agregação e disponibilização dos resultados eleitorais por território, como forma de análise ao desenvolvimento de aplicações complexas e de larga escala bem como o impacto que a fase de concepção tem na criação de uma solução propícia a evoluções e adaptações aos requisitos. É neste contexto que surge este artigo, escrito no âmbito do Projecto da UCE15 do Mestrado de Engenharia Informática da Universidade do Minho, como forma de relatar e demonstrar o trabalho de Modelação de Arquitecturas Aplicacionais desenvolvido integradamente, com a Critical Software S.A., numa aplicação empresarial - a Plataforma Eleitoral. 1 Introdução Existem inúmeros sistemas eleitorais (ou de votação) como sejam referendos, legislativas, autárquicas, presidenciais, europeias, entre outras. Cada um desses sistemas eleitorais possui regras e requisitos bem denidos, e que os tornam diferentes entre si. Tanto que, as regras eleitorais hoje, podem não ser as mesmas amanhã. No entanto, pode-se armar que o propósito (escolher algo, ou alguém, de entre um conjunto de opções disponíveis através de contagem de votos) é o mesmo. Quer-se com isto dizer que, apesar de termos eleições diferentes, o propósito de expressão dos votos nessas eleições é o mesmo.

2 2 Lemos, Pedro; Ribeiro, Pedro Assim sendo, o objectivo principal deste trabalho passa por construir e modelar uma aplicação que suporte diferentes sistemas eleitorais e simultâneamente dê resposta às evoluções e actualizações de que estes sistemas possam ser alvo. Repare-se que construir um sistema eleitoral, é um processo rigoroso que necessita de especial atenção no que diz respeito à validação e aceitação dos requisitos. É preciso dar garantias que a aplicação está a funcionar exactamente como é previsto, é segura, preparada para grandes volumes de dados e níveis de acesso bastante elevados. Dessa forma, construir uma aplicação para umas eleições (por exemplo um Referendo) acaba por ser uma tarefa rigorosa, que obriga à utilização de uma equipa de projecto, que, se composta por cerca de 5 a 6 elementos 1, é provável que necessite de cerca de 2 meses para poder concluir o projecto, o que o torna custoso. O desao é portanto, acabar com as transformações de código de aplicações precedentes e modelar, planear e construir uma plataforma, baseada num modelo de serviços, para recolha, agregação e divulgação dos resultados por território, que seja: modular: com capacidade de expansão. Ou seja, que permita a adição de novas funcionalidades, através de importação de novas bibliotecas ou alteração de cheiros de conguração existentes, sendo a aplicação sucientemente "inteligente"para integrar essas novas funcionalidades de forma transparente sem necessidade de alterações ao nível do código. parametrizável: congurável. Que possa ser calibrada e ajustada às necessidades de cada eleição. extensível: que permita extender a funcionalidade base de forma facilitada sem alterações ao código. Por exemplo, através do uso de plugins ou módulos. escalável: na medida em que é capaz de suportar maiores cargas de acessos através da alocação de novos recursos. Aliado ao referido no parágrafo anterior, pretende-se neste artigo, salientar a fase de modelação porque, quando se trata da construção de sistemas complexos, a utilização de boas práticas na denição da arquitectura aplicacional é determinante para garantir uma solução de qualidade, com capacidade de expansão e maior facilidade em tarefas de manutenção. Segundo [BCK03], acredita-se que a arquitectura do software é o produto resultante do desenvolvimento de software que permite um maior ganho no que diz respeito à qualidade e custo do mesmo. Possivelmente essa é a principal razão pela qual as arquitecturas de software têm ganho relevância sendo hoje a sua prática fundamental para o desenvolvimento e evolução de sistemas de software complexo [TMD09]. 1 elementos com experiência e total domínio das tecnologias

3 Modelação e Desenvolvimento 3 2 Trabalho Relacionado Actualmente existem várias soluções destinadas a dar resposta às necessidades dos sistemas eleitorais. No entanto, cada uma delas foi desenvolvida para um acto eleitoral em especíco, arriscando-se a não ser utilizada novamente. Aquando da realização de um novo acto eleitoral, muito possivelmente com diferentes características, há a necessidade de desenvolver uma nova solução. O que acaba muitas das vezes por ser feito é uma reestruturação do código de soluções anteriores. Mas para tal, continua a ser necessário ter cerca de 3 pessoas durante um mês dedicadas a olhar para as aplicações anteriores e perceber o que é que se pode aproveitar para a nova eleição que surge, e adaptá-la às novas necessidades. O sistema de eleições é uma aplicação em que se destaca a segurança e performance, devido ao curto período de tempo em que é usada, a qual aliada a níveis de tráfego muito intensos, resulta num grande número de pedidos efectuados na hora da divulgação dos resultados via web. Chegando a atingir picos de acessos simultâneos na ordem dos 300 pedidos por segundo 2, fora nesse sentido adoptada a utilização da rede AKAMAI [CWS00, Rev04, adi07, Art06]. Consegue-se com o serviço do Akamai garantir a escalabilidade do website de disponibilização de resultados, garantindo a continuidade da entrega dos conteúdos publicados, bem como o aumento da segurança nas infra-estruturas de origem. Tudo isto porque o serviço permite [AKA09a]: colocação de mecanismos de cache, melhorando a performance da aplicação, nomeadamente na distribuição de conteúdos ao público; redução do peso nas infraestruturas; redução do número de transacções por segundo; aumento da largura de banda disponível. Segundo informação obtida na página web [AKA09b]: "Akamai routinely delivers between ten and twenty percent of all Web trac, at times reaching more than 650 Gigabits per second." 3 O que fora referido até agora nesta secção remete para o modo como as soluções de sistemas eleitorais são desenvolvidas de momento. No entanto o tipo de problemas abordado, como o caso de estudo da Plataforma Eleitoral, não é muito diferente dos que são necessários abordar no desenvolvimento de outro tipo de plataformas ou sistemas como homebanking ou mesmo um centro de apostas online. Pode-se dizer que estes sistemas se enquadram na mesma classe de problemas que a Plataforma Eleitoral, na medida em que possuem características semelhantes. Em todos os sistemas acima enunciados, se verica: 2 no caso de eleições realizadas em Portugal, abrangendo todo o território nacional 3 O Akamai rotinamente entrega entre dez a vinte porcento de todo o tráco da internet, atingindo muitas vezes mais de 650 Gigabits/seg.

4 4 Lemos, Pedro; Ribeiro, Pedro elevado grau de complexidade; níveis de segurança exigentes: por estar a lidar com dados importantes e condenciais, que, em caso de falha, pode trazer danos bastante custosos, e talvez mesmo irreversíveis; necessidade de elevado grau de disponibilização de resultados: sendo fundamental que a informação disponibilizada aos utilizadores reicta em tempo real o estado actual do sistema; a necessidade de uma solução escalável: de forma a suportar o aumento do número de utilizadores sem haver a necessidade de reestruturar a aplicação; parametrizável: de forma a que se possa modicar comportamento rapidamente, sem modicação da aplicação. Podendo-se dessa forma ajustar o negócio (leis, regras, características, entre outras); modular: de forma a facilitar a adição de novos módulos, e proporcionar um rápido crescimento da aplicação; Algum do estudo realizado mostra a forma como, alguns dos sistemas da classe de problemas denida acima, são abordados. Em especíco, no que diz respeito ao desenho da arquitectura aplicacional. Segundo, a NOUS Infosystems, empresa de desenvolvimento de software, aplicações na área do jogo, como um centro de apostas online, têm normalmente como base uma arquitectura multi-camada [Inf], essencial para a correcta operação do sistema em tempo de execução permitindo ter várias camadas lógicas, as quais podem ser distribuídas, garantindo maior escalabilidade. Para além disso, segundo o CEO da Xendex, Michael Haberl [Ent08]: "Registrations on poker and gambling websites are exploding currently. Casino portal sites are under permanent full-load with gambling applications handling thousands of processes in the background that need to be controlled and executed with highest accuracy." Segundo [CdLF00], a forma de dotar uma aplicação web complexa, de capacidade de evolução reside no desenho de uma arquitectura composta por 3 camadas, que têm a comunicação entre si assegurada por inter-camadas. Esta solução foi aplicada em diferentes sistemas web de larga escala, observandose várias vantagens. Entre as quais se destaca a capacidade de integrar alterações feitas numa base de dados, ou nas interfaces, sem que essas alterações se propaguem para o exterior da camada de dados e apresentação respectivamente. Para além disso, verica-se uma maior facilidade na realização de tarefas de manutenção, e na melhoria de performance, sendo mais fácil a identicação de bottlenecks. 3 O Problema O principal problema na construção e modelação de uma plataforma para eleições é a enorme quantidade de variáveis com que se tem de lidar. Não só pelo facto de ser um sistema exigente, mas também por ser regulado por um conjunto de normas jurídicas [CNE09] que explicitam o seu funcionamento.

5 Modelação e Desenvolvimento 5 Essas variáveis dizem respeito a um conjunto de características que vão desde: a organização territorial e sua hierarquia. Por exemplo, em Portugal temos distritos, municípios e freguesias; a divisão (ou não) do território em círculos eleitorais; o número e distribuição dos mandatos; a forma de candidatura (individual ou por listas); a caracterização do boletim de voto; a forma como o eleitor pode exprimir a sua opção/opinião; as metodologias de cálculo aplicadas para conversão dos votos; entre muitas outras regras de negócio" Aspectos tão simples como as horas de abertura de uma eleição estão de- nidas na legislação (as assembleias de voto abrem as 8h e encerram as 19h horas locais). Mas todas estas pequenas regras no seu conjunto dão origem a um sistema bastante complexo mas rigorosamente denido. Sendo assim, é muito provável que tenhamos diferentes requisitos de uma eleição para outra. E, se temos requisitos diferentes, então o sistema que tinhamos construído anteriormente para outra eleição, por muito semelhante que seja, já não servirá a totalmente para esta nova eleição. Portanto, ajustes e adaptações vão ser necessárias para fazer cumprir os novos requisitos. Desta forma, e dadas a conhecer tais situações, para que possamos construir uma solução que suporte diferentes modelos eleitorais, é preciso pensar bem na solução que irá satisfazer as exigências de cada uma das eleições. E é neste contexto que as arquitecturas de software se mostram importantes. Não se pode simplesmente avançar para a implementação sem haver uma arquitectura aplicacional bem denida, dado que o conjunto de decisões tomadas na fase inicial do projecto serão as mais difíceis de se tomar, mas serão também, mais tarde, as mais difíceis de se alterar no processo de desenvolvimento. Portanto, tendo em conta o nosso objectivo é imprescindível modelar correctamente o sistema da plataforma eleitoral. Segundo Tom Mens [MD08], o Software tem-se tornado omnipresente e indispensável para a nossa sociedade baseada na informação. Sendo que, todos os que constroem software devem assumir responsabilidade sobre a sua abilidade. Originalmente isto signicava que o importante era ter implementações sem erros, no entanto, questões como a adaptabilidade e manutenção ganharam recentemente igual importância. Ora, montar uma plataforma eleitoral que seja capaz de ser utilizada para umas eleições hoje, e adaptada amanhã para outras completamente diferentes, bastando para tal efectuar algumas congurações, irá certamente ser uma mais valia, na medida em que permitirá poupar recursos que seriam necessários se não houvesse tal plataforma. Segundo Tom Mens [MD08]: The ability to evolve software rapidly and reliably is a major challenge for software engineering

6 6 Lemos, Pedro; Ribeiro, Pedro 4 A Solução Como foi referido atrás, pretende-se construir software com qualidade, que cumpra os requisitos propostos, e que seja portanto ável. E para tal, concentrase o estudo nas questões arquitecturais e de modelação pois, segundo [NFG + 06], não podemos simplesmente efectuar melhorias nas tecnologias e esperar que isso faça melhorar a nossa capacidade de construir software. É preciso utilizar práticas bem fundamentadas para a denição da arquitectura aplicacional, a qual é indispensável, em sistemas complexos, para obter resultados satisfatórios. No entanto, é necessário ter em atenção que não existe nenhum parâmetro de qualidade que dependa unicamente do design, nem unicamente da implementação. É necessário ter uma boa arquitectura mas é igualmente importante que a implementação esteja correcta. No caso prático em questão, como já fora referido anteriormente, optou-se pela construção de uma arquitectura que permita a adaptação a diferentes eleições e com isso dar uma melhor resposta às necessidades do cliente, bem como aproveitar para poupar nos recursos a alocar. Segundo Len Bass [BCK03], não existem propriamente nem boas nem más arquitecturas. Existem sim arquitecturas que servem melhor, ou pior, determinado propósito. Para que se possa construir e modelar uma boa arquitectura, segundo [Key02], é necessário adquirir uma profunda análise do sistema e funcionalidades do mesmo, antes de se poder decidir sobre a organização dos módulos, dado que produzir uma estrutura modular não é uma tarefa mecânica. Começou-se então por efectuar um estudo exaustivo dos sistemas eleitorais existentes bem como das diferentes características de cada um. Desse estudo resultou a decisão de estruturação da aplicação em vários módulos aplicacionais. Não apenas por ser um projecto de grande dimensão e complexidade, e por existirem tarefas e funcionalidades que se evidenciam e que, independentemente da eleição em questão, existem sempre. Mas também porque [TMD09, BCK03]: permite dotar a aplicação de capacidade de expansão: permitindo-nos adicionar, remover, recarregar componentes e módulos em tempo de execução sem afectar o restante sistema; melhora a segurança do sistema; facilita a manutenção da aplicação na medida em que um módulo é relativamente mais pequeno e autónomo relativamente aos outros; facilita a compreensão e realização de testes sobre o sistema; permite focar num componente e módulo: pois normalmente cada módulo está associado a diferentes elementos da equipa de projecto, e como tal a dedicação é total.

7 Modelação e Desenvolvimento 7 A arquitectura resultante da análise feita é apresentada na Figura 1. E, como se pode ver, separamos a aplicação em cinco módulos, que representam funcionalidades distintas e autónomas: Core - é o cérebro de todo o sistema (contém as regras de negócio). E, para além disso, é aquele com quem todos os outros módulos interagem. Nele existem 2 sub-módulos (DataLoader e Cache) que serão abordados posteriormente. Web Back Oce - módulo com a responsabilidade de fornecer funcionalidades de gestão da aplicação durante a sua execução. É este módulo que permite alterar a congurabilidade da aplicação através da interacção com o Core, mais especicamente com o sub-módulo DataLoader, permitindo a alteração das regras de negócio da aplicação. Data Insertion - módulo que fornece uma interface para introdução de votos e auências no sistema através de comunicação com o Core. Results Disclosure - módulo responsável pela disponibilização dos dados e resultados da aplicação através de páginas web. Interage com o módulo Core, mais especicamente com o módulo de Cache. Web Services - módulo responsável por fornecer dados de forma prioritária a entidades especiais através de fornecimento de webservices. Interage também com o sub-módulo de Cache, do módulo Core. Data Loader - módulo responsável pela leitura dos dados (de cheiro) necessários à aplicação, como informações territoriais, candidatos, círculos eleitorais, entre outras. É um sub-módulo integrado no Core, com o qual comunica e que facilita grande parte do processo de adaptação de umas eleições para outras carregando tudo o que seja congurações de forma rápida e transparente; Cache - módulo responsável por determinar o funcionamento da cache aplicacional. É um sub-módulo integrado no Core que garante o fornecimento de resultados ao público. Segundo [BD04], a decomposição e organização dos componentes de software é tão indispensável que todas as abordagens às questões de arquitectura de software acabam por abordar este assunto de uma maneira ou de outra. A mais valia da separação de uma aplicação em módulos é a sua exibilidade. Imagine-se, por exemplo, que agora, ao invés de se lerem os dados necessários à aplicação a partir de cheiro, os queremos importar de uma base de dados. O que se teria de fazer era substituir o módulo Data Insertion - que lê os dados de cheiro - por um novo módulo que lesse os dados a partir de uma base de dados. Até aqui concentramo-nos na vista estrutural que as arquitecturas de software nos fornecem em termos de componentes e suas relações. No entanto, a separação modular da arquitectura não resolve todos os problemas, sendo que alguns dos requisitos exigidos pelo negócio deverá ser abordado mais em termos de comportamento do que em termos estruturais.

8 8 Lemos, Pedro; Ribeiro, Pedro Figura 1. Módulos da aplicação e sua organização. É caso disso a denição dos territórios nas eleições. Pois, estes têm inuência não só no que diz respeito à organização e hierarquia dos territórios, mas também à inserção de votos e auências, particularmente devido à denição dos níveis de inserção desses mesmos dados. A solução encontrada para o problema foi a utilização de cheiros XML de conguração para a aplicação, nos quais se dene algumas das regras da aplicação (de modo a que possam ser parametrizáveis), incluindo a hierarquia dos territórios a usar ou os níveis dos territórios que irão receber os votos e as auências. Como consequência da utilização de regras parametrizáveis, temos de ter especial atenção na forma como denimos cada uma das funcionalidades que depende directa ou indirectamente da hierarquia dos territórios. Um exemplo disso é a inserção de votos e auências, que apesar de serem introduzidas a um determinado nível territorial (em Portugal esse nível é a freguesia), cada uma dessas inserções inuencia os resultados de todos os territórios de nível superior (munícipio, distrito e país - no caso de Portugal). A situação acima descrita, levanta outra questão que se prende com o facto de, quando se inserem votos e auências, estamos já a mostrar os resultados ao público. Esta situação leva a um dos requisitos mais importantes do sistema: impreterivelmente os dados da aplicação têm de estar sempre num estado consistente. Assim sendo, imaginemos o seguinte exemplo: Exemplo: Sejam 2 freguesias {'A1' e 'A2'} que pertencem a 1 município 'A'. Então quando inserimos em 'A1' 10 votos, temos que ter em 'A' igualmente '10'

9 Modelação e Desenvolvimento 9 votos. E, assim que inserirmos em 'A2' 14 votos, temos que em 'A' passar a ter 24 votos. Este requisito é extremamente crítico pois, inuencia: o modo como se efectuam inserções de votos e auências na aplicação; o modo como se trata a propagação dos resultados de um território de inserção para todos os outros a ele associados; e também o desempenho da aplicação. Imaginemos o caso de Portugal, com mais de 4000 freguesias, mais de 300 concelhos, 18 distritos e 2 regiões autónomas. Quando as inserções começassem a ser feitas (ao nível das freguesias), teríamos que actualizar os dados dos concelhos, distritos e regiões autónomas e país. Isso iria implicar a necessidade de efectuar locks à base de dados e consequentemente ir-se-ia formar uma la de espera, devido aos pedidos de inserções pendentes para actualizar os valores na base de dados de um determinado território. Para acrescer ao problema teríamos ainda o problema de leitura dos valores da base de dados, para mostrar ao público os resultados. O que iria implicar um lock global para que ao lermos os valores das freguesias, e posteriormente os valores dos municípios (distritos e pais), os valores estivessem consistentes. Como é expectável, isto iria degradar o desempenho da aplicação. Para se resolverem estes problemas decidiu-se que ao ser feita uma inserção num território (freguesia), não se iria propagar (de imediato) o resultado para os níveis superiores, mas de certa forma simular essa propagação através da utilização de uma cache aplicacional. A qual tem como principal objectivo guardar conteúdos frequentemente acedidos, de modo a melhorar o tempo de resposta da aplicação. No caso em questão, é útil essencialmente para mostrar os resultados das eleições ao público, nos vários níveis territoriais hierárquicos (por exemplo: desde uma freguesia, subindo para o nível dos municípios, depois distritos, e nalmente o próprio país) garantindo a sua consistência e disponibilidade. Como resultado da utilização de um mecanismo de cache aumentamos o desempenho da aplicação, e garantimos a consistência dos dados(pois ainda que o servidor da base de dados seja desligado, continua a ser possível consultar os resultados, mostrando-se os últimos valores em cache). Assim sendo, as inserções de votos e auências passam a ser mais rápidas, na medida em que se deixa de efectuar a propagação dos resultados inseridos (durante a fase de inserções de resultados, devido aos acessos concorrentes) 4 e como tal deixa de haver a necessidade de locks à base de dados. 4 Todos os valores serão propagados assim que tenha terminado a fase de inserções

10 10 Lemos, Pedro; Ribeiro, Pedro Por isso, sempre que for necessário mostrar os resultados inseridos, tiramos um snapshot à base de dados e efectuam-se os cálculos e respectiva propagação para níveis superiores com os valores que se obtêm do snapshot, com isso garante-se que os resultados dos níveis territoriais superiores se encontram sempre consistentes. Em seguida passam-se os valores calculados para a cache. E posteriormente, quaisquer resultados que sejam passados para o exterior serão sempre lidos da cache. 4.1 Padrões Arquitecturais No decorrer da modelação da aplicação procurou-se, sempre que possível, aplicar design patterns que são úteis por já terem sido testados e representarem uma boa solução (para determinado contexto bem denido), solução essa que pode ser reutilizada. Para além disso facilitam a implementação, teste e manutenção das aplicações na medida em que denem um modelo standard que é reconhecido por outros developers, tanto para comunicarem, documentarem e explorarem alternativas de design, melhorando efectivamente o nível de programação de cada um. [GHJ + 93] Os 'patterns' são bastante úteis na medida em que fornecem uma boa solução para um problema comum. [AMC + 03] Refere-se assim, em seguida, um conjunto de patterns utilizados na arquitectura da aplicação em estudo - Plataforma Eleitoral - de modo a resolver alguns dos problemas. Singleton Como foi referido anteriormente a aplicação em questão, contem vários cheiros de conguração. Os dados contidos nestes cheiros são utilizados por diferentes componentes do sistema, durante o tempo de vida da aplicação. Com o intuito de melhorar a performance, estes dados são mantidos em memória. No entanto, precisam de ser únicos no sistema de forma a preservar a sua consistência e a serem alcançáveis pelos diversos componentes. Para solucionar este problema foi utilizado o pattern singleton. Este pattern de criação assegura a existência de apenas uma instância de uma determinada classe, a qual possui um ponto global de acesso [GHJV95]. A Figura 2 exemplica a utilização deste pattern no caso de estudo, em que a instancia ConfigurationManager é única no sistema e acessível por todos os outros componentes. Esta contém o objecto ConfigurationData que possui todos os dados de conguração. Simple Factory

11 Modelação e Desenvolvimento 11 Figura 2. Singleton pattern Uma das funcionalidades do caso em estudo é o calculo de resultados. Estes resultados são consequência da execução de um algoritmo, que pode ser diferente perante varias eleições, e variar ao longo do tempo. De forma a resolver este problema deniu-se um componente que permite carregar classes por reflection. Esta tecnologia permite que programas em Java carreguem novas classes, individualmente, permitindo alcançar um maior grau de exibilidade. Como esta operação ocorre inteiramente dentro do Java, a portabilidade é também preservada [FF04]. No entanto, este mecanismo de criação de classes de algoritmo, poderá mudar. Por esta razão existiu a necessidade de separar a instanciação da classe concreta que implementa o algoritmo, e assim utilizou-se o pattern Simple Factory. Este pattern devolve uma instância, de várias possíveis, dependendo do tipo de dados que lhe é passado [Coo00] Ao encapsular a criação de um objecto numa outra classe, existe apenas um sítio para alterar quando a implementação muda. Como se pode vericar na Figura 3, a classe AlgorithmFactory possui apenas o método create, que tem como objectivo criar um algoritmo. Este algoritmo é criado segundo o método descrito anteriormente: reflection. Caso haja a necessidade de alterar o mecanismo de instanciação de algoritmos (e.g denir os algoritmos em tempo de compilação), basta modicar o método create do simple factory e tudo o resto se mantém. A classe Algorithm é abstracta e obriga que todas as suas subclasses implementem o método calculateresults. Exemplos de algoritmos que poderão ser utilizados são o método D'Hondt [STA], e o método Absoluto. Data Access Object A aplicação em questão, foi desenvolvida com base numa arquitectura multicamada, contendo diferentes camadas de apresentação as quais comunicam com o módulo Core através de Session Beans [mic] locais. Para separar o camada de negócio da camada de dados foi utilizado o pattern DAO 5, o qual implementa mecanismos de acesso e manipulação de dados persistentes, podendo apenas ser acedidos pelas Session Beans presentes no modulo Core. Estes foram utilizados em todos os objectos da camada de dados com o objectivo de dissociar a implementação de acesso a dados da lógica de negócio facilitando a manutenção, a portabilidade e a segurança [AMC + 03]. Um dos 5 Data Access Object

12 12 Lemos, Pedro; Ribeiro, Pedro Figura 3. Factory pattern DAO's implementados na aplicação encontra-se presente na Figura 4, o qual por utilizar a tecnologia Java Persistence, interage com Entity Beans, como é o caso das classes ElectoralAct e Election. Figura 4. Data Access Object pattern Facade Uma boa prática na resolução de um problema, é a separação deste em vários mais pequenos, facilitando a sua resolução, bem como tarefas de manutenção. Assim sendo, foi utilizado o pattern facade, que dene uma interface unicada de maior nível que permite esconder a complexidade de objectos que

13 Modelação e Desenvolvimento 13 contribuem para a resolução do problema [FFBS04]. A figura 5 exemplica o uso deste pattern. Neste, a Session Bean BackOce utiliza a Session Bean LifeCicleManager para validar a possibilidade de executar determinadas operações tendo em conta não só as conguração como o estado interno do sistema. Para além disso, foram utilizados mecanismo de protecção, para evitar acessos directos aos DAOs apartir da camada de apresentação, pois apenas os facades criados têm acesso a estes. Service Locator Figura 5. Facade pattern O acesso a um serviço da camada de negócio, (por exemplo a partir da camada de apresentação) é feito com a ajuda do InititialContext. No entanto, criar um JNDI 6 InitialContext e através deste obter a interface pretendida (lookup), é potencialmente uma operação dispendiosa, e que se realizada repetidamente poderá degradar o desempenho [AMC + 03]. De forma a minimizar este problema foi utilizado o pattern Service Locator, o qual implementa e encapsula o acesso ao serviço de lookup de componentes, disponibilizando um ponto único de controlo e melhorando a performance ao utilizar um mecanismo de cache. O Service Locator é implementado tipicamente como um singleton e pode ser reutilizado por clientes da aplicação, reduzindo assim a complexidade do seu código. Este pattern encontra-se exemplicado na Figura 6. Iterator 6 Java Naming and Directory Interface

14 14 Lemos, Pedro; Ribeiro, Pedro Figura 6. Service Locator pattern Como na aplicação em estudo temos uma arquitectura separada em camadas, existe a necessidade de passar informação da camada de negócio para a camada de apresentação, de uma forma sequencial, permitindo uma abstracção da estrutura interna do agregado de objectos [FFBS04]. A solução para este problema está na utilização do pattern iterator, que disponibiliza todas estas características. A Figura 7 demonstra este pattern, utilizado para obter informações de cada eleição, tendo em conta que o número de eleições é congurável. Figura 7. Iterator pattern

15 5 Caso de Estudo: Plataforma Eleitoral Modelação e Desenvolvimento 15 Para denir o comportamento do acto eleitoral foram utilizados cheiros xml [W3C]. A razão pelo qual foi escolhido este tipo de cheiros, tem a ver com a capacidade de descrever bastantes tipos de dados. Trata-se pois de um formato neutro que permite a organização dos dados de forma hierárquica. Estes cheiros contêm não só dados especícos de cada eleição, como o nome, territórios associados, datas entre outras, mas também dados que introduzem comportamento no negócio. Isto é, contém o nome das classes a serem carregadas por reexion em tempo de execução, nomeadamente classes que possibilitam o cálculo de resultados. Permitem também a geração de utilizadores, que podem entrar em contacto com o sistema, e outros dados que variam de eleição para eleição. Figura 8. Diagrama de Deployment A aplicação - Plataforma Eleitoral - foi desenhada de forma a que, em caso de shutdown (ou falha) inesperada do servidor de origem, seja possível retomar rapidamente a aplicação, recuperando o estado em que se encontrava imediatamente antes do servidor ter sido desligado, sem que para isso seja necessária