Arquitetura da Plataforma 1.x

Da AMADIS

Índice

Introdução

Durante o desenvolvimento do AMADIS, foram utilizadas várias técnicas e soluções visando facilitar a manutenção e expansão dos módulos estruturais do ambiente, assim como das suas ferramentas. Embora ele ainda não tenha atingido a maturidade plena, os caminhos percorridos até este momento já trouxeram relevantes melhorias à plataforma.

O que será mostrado dentro deste capítulo é uma visão geral sobre a arquitetura da plataforma AMADIS, tendo como objetivo esclarecer as idéias que fundamentaram o projeto e consolidar os conceitos utilizados no seu desenvolvimento. Por meio de tal descrição, procura-se facilitar a compreensão do processo de construção do AMADIS, fundamental para a manutenção do sistema. Trata-se da descrição do desenvolvimento de um ambiente poderoso, rico e estável para EAD, por meio da qual se reflete sobre a entrada de novas funcionalidades e também sobre a própria manutenção do sistema.

Desenvolvimento em Camadas

Ao pensar sobre o desenvolvimento de uma plataforma que apresentasse uma construção modular e de fácil manutenção, a equipe optou pelo desenvolvimento em camadas. Para uma construção desse tipo, fez-se necessária a utilização dos Design Patterns(Padrões de Desenho)[ex. A.Christopher].

Os Design Patterns são uma coleção de padrões de desenho de software, que apresentam soluções para problemas conhecidos e recorrentes no desenvolvimento de softwares. Um Pattern descreve uma solução comprovada para um problema de projeto recorrente, dando ênfase particular no contexto e forçando a aproximação do problema com as conseqüências e os impactos de sua solução.

O Desing Pattern em uso no AMADIS é o Model View Controller(MVC - Modelo Visualização e Controle). Este trata-se de um Design Pattern que descreve como será o funcionamento das camadas do software. Ele indica, por exemplo, a separação conceitual entre as partes e as suas funções dentro do sistema, fazendo com que se tenha três camadas principais para representar o modelo de dados, o conjunto de visões e o conjunto de controladores. A vantagem da sua utilização que ele simplifica a visualização e a análise do fluxo de execução. (Ver ilustração abaixo)

Diagrama de fluxo de execusão sobre o Desing Pattern MVC


O fluxo de execução do sistema obedece a uma ordem bem comum dentro dos sistemas Web. Ou seja, após haver uma requisição pelo navegador web, o servidor processa a execução solicitada pelo usuário. O mais interessante é como essas transações se dão dentro do Core do AMADIS, considerando que muitas ferramentas são interligadas, gerando um grafo de funcionamento bastante complexo.

O AMADIS tem suas ferramentas divididas de acordo com esse padrão. Isto é, para toda ferramenta, existem classes de manipulação de dados, classes de visualização e também controladores, que são a primeira camada de acesso dos usuários. Na verdade, poderíamos considerar o desenvolvimento do AMADIS não apenas em três camadas, mas sim em cinco, visto que, na parte de visualização, somam-se duas camadas (uma a nível de servidor, onde os widgets são gerados e outra a nível de cliente, em que parte da interface não corresponde somente à visualização, já que apresenta uma interatividade e independência elevada em relação ao restante da aplicação). Além disso, a quinta camada seria o próprio banco de dados e os objetos de persistência, que são realizados pelo CMDevel, não pelo AMADIS.

Core do AMADIS

Core é o nome dado ao conjunto de classes, scripts e ferramentas que constituem uma base para um sistema. No caso do AMADIS, ele é representado pela AMADIS-API, que é utilizado em todas as operações da plataforma enquanto se executa um script.

Esta API fornece um conjunto de classes e funções que facilitam a construção da interface e a manipulação dos dados referentes ao banco de dados ou ao sistema de arquivos. Também fazem parte da API algumas funcionalidades apresentadas no ambiente, presentes na área de Projetos ou no Webfólio, que são essenciais na estruturação da plataforma.

Variáveis globais

As variáveis globais no PHP são muito utilizadas pela maioria dos programadores. Porém, deve-se tomar um grande cuidador ao utilizar esse tipo de recurso, já que, em primeiro lugar, apresenta risco de segurança e, em segundo, porque pode ocasionar confusões durante a execução do sistema, gerando erros de difíceis diagnóstico. No Core do AMADIS, existem quatro variáveis comumente utilizadas: $_FILES, $_REQUEST e $_SESSION, geradas pelo próprio PHP, e a $_CMAPP, criada pelo scrip config.inc.php. Essas variáveis correspondem, respectivamente, à variável global de transferência de arquivos, variável de requisição , variável global de sessão e à variável de configuração da plataforma e de suas funcionalidades.

As variáveis globais de transferência $_FILES E $_REQUEST são geradas pelo PHP durante a execução de um script. Este recolhe todo o conteúdo postado por mecanismos de input GET, POST e COOKIE e deposita no array associativo $_REQUEST. O array $_FILES armazena as informações dos arquivos, carregados através do método HTTP POST, ou seja, arquivos enviados por forumlários ou scripts de transferência.

As variáveis de sessão, quando registradas, permanecem ativas enquanto a sessão estiver aberta, perdendo o seu valor quando o usuário solicita uma ação de logout(se desconecta do ambiente). A sessão também é destruída quando o sistema faz uma limpeza, deletando variáveis que não serão mais utilizadas. Cabe ainda ressaltar que o PHP registra essas variáveis de sessão na variável global $_SESSION.

Quanto às variáveis $_FILES, $_REQUEST E $_SESSION, pode-se dizer que pertencem ao grupo das SUPER GLOBALS, ou seja, que elas são globais por natureza e não necessitam do metódo global para sua captura dentro de funções ou metódos de classes. nesse sentido, elas se diferem das variáveis globais de script, que são redefinidas a todo momento que o usuário recarregar a página, ou seja, ao executar qualquer ação no ambiente.

Na variável $_SESSION, são registrados os dados de permanência de navegação do usuário, assim como o objeto AMUser, que contém os dados do usuário logado. Além disso, são registrados caches de consultas executadas com maior freqüência, como, por exemplo, a lista de amigos e dos projetos do usuário. Essa função torna o carregamento das páginas mais rápido, dinamizando o ambiente. Cabe ressaltar ainda que a variável de sessão também pode ser usada pelas ferramentas do AMADIS durante o registro de dados temporários ou para fins de consistência das operações solicitadas.

Por fim, há a $_CMAPP, que é uma variável global de script, utilizada para guardar informações referentes à configuração da plataforma. Nela são registrados os dados como caminho das classes para include, caminho de dependências do AMADIS, url absolutas e configuração do sistema.

Manipulação e renderização da interface

A camada de visualização do AMADIS é representada pelas classes de templates, que fornecem recursos para geração de telas de apresentação dos conteúdos registrados no ambiente. A grande facilidade de compor uma tela utilizando-se de técnicas como o MVC, é a possibilidade de se ter, no controlador, uma única chamada que despacha uma série de ações encapsuladas numa classe de apresentação de dados. A essas classes de templates do AMADIS dá-se o nome de widgets(componentes de interface).

Um widget é um componente de interface dotado de algumas propriedades, ações e eventos, que facilitam a contrução da visualização de uma aplicação. O AMADIS possui dois tipos de widgets: Templates e Boxes (caixas). Os templates correspondem a uma construção primitiva de página, neles são contidos os menus, a barra superior e o rodapé da página que será exibida.

Os widgets do tipo box são utilizados a partir da sua inserção nos templates. Eles correspondem à implementação mais básica de componentes da interface, pois possuem apenas propriedades de aparência e de renderização. Além disso, os widgets são comumentes utilizados de duas formas:

  • A primeira forma é como renderizador. Desse modo, o controlador realiza uma consulta no banco de dados através de um modelo ou, então, executa qualquer outro tipo de operação, repassando ao widget as informações prontas em formato html;
  • A segunda é como modo extendido, em que são criados widgets que extendem as propriedades dos boxes primários, criando mecanismos de interpretação das informações transmitidas pelo controlador.

Dentro das práticas de desenvolvimento utilizadas, a segunda forma de widget' ' é a mais comum. Isso faz com que o código seja distribuído dentro de uma lógica consistente. Como o widget é o reponsável pelo processamento da informação que lhe é transmitida, ele deve ser portável, possibilitando a sua exibição em diversos pontos da interface. Isso é utilizado dentro do conceito de Ponto Único de Falha, que faz que um determido tipo de exibição seja codificado uma única vez numa classe e instanciada sempre que necessário. Tal prática visa facilitar a manutenção do código fonte resultante.

Como última instância de classes responsáveis pela geração de visualização do AMADIS, temos o CMHTMLObj do pacote CMDevel::CMInterface. Ele possui uma pilha de saída em que os objetos da interface são registrados, e assim, o comando de impressão (__toString) é dado, fazendo com que todos sejam enviados ao cliente no formato html.

Esse modelo de composição da interface garante ao programador um poder de controle da interface muito grande, já que durante a sua construção tudo é tratado como um objeto. A única desvantagem existente é a manutenção do código HTML dos widgets, pois esse deve ser incorporado ao script PHP. Isso significa dizer que, para poder realizar alterações no layout, o designer fica na dependência do desenvolvedor.

Uma re-modelagem deverá ser feita para as próximas versões do ambiente, pois esse modelo apresentado, ao passo que facilita a construção da interface em geral, exige, por outro lado, uma forte demanda de manutenção e reimplementação do widget. Justamente por conter o conteúdo de exibição e a parte de lógica misturados, esse modelo torna impossível a visualização do componente fora do AMADIS.

O nova proposta de modelo já está sendo estudada. Uma das hipóteses seria utilizar um script do tipo FastTemplate(Modelo rápido), que possibilita a obtenção de todo o conteúdo de visualização em HTML separado da lógica do widget. O FastTemplate funciona por métodos de busca e substituição de strings e pode ser um caminho interessante para a plataforma, embora o tempo de seu processamento, na construção de uma tela, pode se estender bastante. Aliás, esse é um dos motivos pelos quais a equipe ainda mantém a proposta em estudo.

Diagrama sobre a construção da interface

Banco de Dados

Dentro do desenvolvimento de aplicações que utilizam banco de dados existem três modelos de construção de persistência de dados, são eles: Modelo Tradicional, Modelo de Prevalência e O/RM (Object/Relational Mapping).

  • Modelo Tradicional: é o modelo mais utilizado. Ele possui o funcionamento mais simples dos três modelos e apresenta também a melhor performance. Nesse modelo, o programador monta os seus comandos SQL e os envia ao banco de dado, através de um provedor. Com a sua utilização, a maioria dos desenvolvedores optam por criarem seus próprios frameworks, visando diminuir a quantidade de trabalho gerado pelo modelo.
  • Modelo Prevalência: trabalha sobre a perspectiva de que os dados devem ser registrados em memória RAM, e não em discos rigidos e SGDBs(Sistemas Gerenciador de Banco de Dados). O seu funcionamento consiste em manter registrados em memória todos os objetos de persistência dos dados, realizando, de tempos em tempos, um snapshot dos dados, isto é, salvando todas as trasações que estejam na memória no disco rígido, afim de que não se percam dados durante uma queda de luz ou uma reinicialização do servidor da aplicação.
  • O/RM (Object/Relational Mapping): este é o Modelo Mapeamento / Objeto Relacional, que funciona como mais uma camada da aplicação responsável por mapear classes e atributos do seu projeto para as tabelas e os campos do seu banco de dados. Existem várias formas de se fazer esse mapeamento. Alguns frameworks utilizam a linguagem XML, outros trabalham sobre a construção de interfaces que obrigam o desenvolvedor a implementar algumas regras. Eles tê como objetivo fazer com que o framework consiga gerar os comandos SQL dinamicamente. Uma outra característica deste modelo é a independência do banco de dados. Devido à geração de comandos dinâmicos, o framework pode analisar qual banco de dados a aplicação está acessando e, a partir disso, gerar os comandos no dialeto específico do banco de dados. Ou seja, é possível mudar o banco de dados da aplicação apenas alterando um arquivo de configuração.

Dentre os três modelos, o escolhido foi o O/RM, porque permite o uso de um número muito elevado de consultas SQL e o consumo de muito memória para a geração de consultas que não seriam possíveis através da utilização dos modelos subjacentes. Por esse motivo foi utilizado o pacote CMPersistence do CMDevel Framework para a geração das consultas. Outros frameworks semelhantes podem ser encontrados, como o PEAR_DataObject, Zend Framwork e CakePHP, mas a equipe de desenvolvimento do AMADIS optou por construir o seu próprio.

No diretório lib do AMADIS, encontram-se os arquivos correspondentes à camada de modelo. Esta é responsável pela manipulação de dados da plataforma. Os dados trabalhados aqui não se restringem somente aos salvos no banco de dados, mas também aos arquivos mantidos pelas ferramentas de publicação de páginas. A camada de manipulação de dados do AMADIS é construída sobre o CMPersistence, um pacote de persistência de dados do CMDevel Framework, já mensionado anteriormente. Ele realiza a construção das consultas e fornece possibilidades de execução de ações sobre os dados, restando ao AMADIS somente a construção da descrição das tabelas do banco de dados e a criação de rotinas de trabalho sobre elas. Com a aplicação desse pacote, o desenvolvimento do AMADIS e de suas ferramentas foi facilitado. Houve um grande salto qualitativo em relação à estruturação do ambiente, embora ainda se tenha muitos aspectos a serem melhorados.

O CMObj é a classe principal do CMPersistence. Ele é responsável pela geração das consultas primárias ao banco de dados, que consistem em consultas envolvendo um único dado registrado no banco, tais como o cadastro de um usuário, por exemplo. Através do CMObj o AMADIS registra, deleta, atualiza e consulta dados salvos no banco de dados. Por outro lado, para consultas mais expressivas, como listagens e buscas, é utilizado o CMQuery, pois este sim é preparado para gerar listas de CMObjs. Afinal, o CMObj é a representação de um único dado dentro do banco de dados.

Abaixo segue diagrama de como funciona a estrutura de uma classe Model dentro do AMADIS:

Representação do model dentro do AMADIS.

Sistema dos Arquivos

Para a organização dos arquivos do AMADIS, foi adotado um modelo semelhante àquele adota no Unix. Esse contempla uma organização em diretórios sob um modelo de separação de contextos, onde arquivos com funcionalidades semelhantes, agrupam-se dentro do mesmo diretório. Esse padrão de distribuição contribui para uma melhor localização e organização dos módulos e de suas dependências, embora possua desvantagens, como, por exemplo, o não encapsulamento das ferramentas da plataforma. Nesse sentido, uma mesma ferramenta tem seus arquivos distribuídos pelas pastas do sistema de arquivo.

Abaixo segue em detalhes a árvore de diretório do AMADIS:

amadis            **raiz
 |_ambiente       **diretório publico
   |_ferramentas  **concentrador dos pacotes
     |_pacote     **pacote
   |_media        **elementos de mídia
     |_applets    **applets java
     |_css        **arquivos de css
     |_dtds       **xml dtds
     |_images     **imagens
       |_pt_br    **imagens com textos em portugues Idiomas no AMADIS
     |_js         **arquivos de javascript
     |_paginas    **paginas usadas como padrao
     |_rte        **Rich Text Editor
     |_thumbnails **Miniaturas de imagens
   |_paginas      **hospedagem de páginas
     |_users      **páginas de usuarios
     |_projetos   **páginas de projetos
 |_etc            **configuracao
 |_examples       **exemplos para documentação
 |_lang           **arquivos de idiomas
 |_lib            **biblioteca geral, incluido classes de banco de dados
   |_exceptions   **classes de exceções
 |_log            **log do sistema
 |_templates      **classes de widgtes
   |_boxes        **widgets do tipo caixas

Como dito anteriormente, essa estrutura não é a mais adequada para um sistema modular. Entretanto, ela contribui para a legibilidade do sistema, sob a perspectiva do programador, agrupando arquivos com funcionalidades semelhantes nas mesmas pastas. Esse formato é bastante difundido no desenvolvimento de projetos Web, o que diminui a dificuldade de aprendizagem dos novos desenvolvedores. Em futuras versões, a equipe de desenvolvimento pretende estudar uma abordagem mista, que facilite o desenvolvimento de módulos por terceiros.

Considerações finais da Arquitetura

O AMADIS, apesar de possuir atualmente uma arquitetura clara e bem definida, ainda precisa de algumas alterações que facilitem sua modularidade. Embora as ferramentas estejam consistentes, o core do ambiente ainda não é totalmente coerente com o modelo de MVC, o que torna, em algumas circunstâncias, a interpretação do código muito difícil.

Outro ponto de evolução que se espera para a AMADIS-API é o surgimento dos Facades para separar a lógica de manipulação do banco de dados das classes de descrição. Além disso, objetiva-se ainda diminuir a carga de processamento dos controladores, pois os mesmos, em algumas áreas, realizam operações que seriam originalmente do View ou Model, o que gera, muitas vezes, problemas de manutenção. Estes são efeitos resultantes do trabalho de desenvolvedores ainda em apredizado e que faz parte de todo grande projeto de software.

Essa dificuldade constatada no uso do MVC e em certos patterns de programação, deve-se, em grande parte, ao processo de amadurecimento da linguagem utilizada no projeto: o PHP 5. O PHP nasceu como uma ferramenta para construção de pequenos scripts pessoais, mas tornou-se amplamente difundida no desenvolvimento de ferramentas Web. No entanto, apenas no último ano (2006) é que estão surgindo ferramentas implementadas na linguagem que permitem o desenvolvimento estritamente segundo um modelo MVC. Esse amadurecimento da linguagem, possibilitará a alteração da arquitetura do AMADIS, tornando-a mais elegante e funcional, ou seja, adequada aos padrões de desenvolvimento de software.

Referências Bibliográficas

CHISTOPHER, A.

A Pattern Language [Alex77]
A Timeless Way of Building [Alex79]

GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.

Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95]
Ferramentas pessoais
Parceiros
















SourceForge.net Logo

Supported by Cenqua