Arquitetura da Plataforma 1.x

Da AMADIS

Revisão das 21h19min de 25 de Agosto de 2006 por Juliano (discussão | contribs)

Índice

Introdução

No desenvolvimento do AMADIS foram utilizadas várias técnicas e soluções visando facilitar a manutenção e expanção do ambiente, assim como das suas ferramentas. Embora ele ainda não tenha atingido a maturidade, o caminho percorrido até este momento, já trouxe muitas melhorias à plataforma.

O que será mostrado dentro deste documento é uma visão geral sobre a arquitetura da plataforma AMADIS, com o objetivo de esclarecer idéias e consolidar conceitos utilizados no desenvolvimento, de modo a facilitar o entendimento da construção do AMADIS. Pois um dos objetivos no desenvolvimento do AMADIS é construir um ambiente poderoso, rico e estável, e que propicie a entrada de novas funcionalidades e facilite a sua própria manutenção.

Desenvolvimento em Camadas

Pensando em desenvolver um ambiente que apresentasse uma construção modular e de fácil manutenção, foi adotado o desenvolvimento em camadas. Para uma construção deste tipo fez-se necessária a utilização dos Desing Patterns(Padrões de Desenho)[ex. A.Christopher].

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

O Desing Pattern que pode ser identificado em uso dentro do 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. Indicando uma separação conceitual entre as partes e suas funções dentro do sistema, fazendo com que tenhamos três camadas principais que representam um modelo de dados, um conjunto de visões e um conjunto de controladores. Isso torna mais simples a visualização e análise do fluxo de execução, como visto abaixo:

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

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

O AMADIS tem suas ferramentas divididas usando este padrão, isto é, para toda ferramenta do AMADIS, existem classes de manipulação de dados, classes de visualização e os controladores que é a primeira camada de acesso dos usuários. Na verdade poderiamos considerar o desenvolvimento do AMADIS não em três camadas mas sim em 5 camadas, pois na parte de visualização somam-se duas camadas uma a nível de servidor, onde os widgets são gerados e outra no cliente, onde parte da interface não corresponde somente a visualização, pois possuem um nível de intertividade e independência do restante da aplicação considerávelmente elevado. A quinta camada seria o banco de dados e objetos de persistência, pois essa é realizada pelo CMDevel e não pelo AMADIS.

Core do AMADIS

Core é o nome dado para o conjunto de classes, scripts e ferramentas que constituem uma base para um sistema. No caso do AMADIS ele é representado pela AMADIS-API, esta utilizada em todas as operações da plataforma durante a execução de um script.

Esta API fornece um conjunto de classes e funções para facilitar a construção da interface e para manipulação de dados, tanto do banco de dados, como no sistema de arquivos. Também fazem parte da API algumas funcionalidades apresentadas no ambiente, das quais sem elas não haveria a plataforma AMADIS como os projetos e o webfolio.

Variáveis globais

As variáveis globais no PHP são muito utilizadas pela maioria dos programadores, mas um cuidado grande dever ser tomado ao utilizar este recurso, primeiro por questões de segurança e segundo por criar confusões dentro da execução do sistema, gerando erros difíceis de diagnósticar.No Core do AMADIS existem quatro variáveis comumente utilizadas, a variável $_FILES, $_REQUEST e $_SESSION, essas geradas pelo próprio PHP e a $_CMAPP, criada pelo scrip config.inc.php. A essas variáveis correspondem respectivamente a 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 suas funcionalidades

As variáveis globais de transferência $_FILES E $_REQUEST são geradas pelo PHP durante a execu cão de um script, ele pega todo conteúdo postado por mecanismos de input GET, POST e COOKIE e deposita no array associativo $_REQUEST. Ao $_FILES ficam os 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(desconecta do ambiente) e a sessão é destruída, ou quando o sistema faz uma limpeza, deletando variáveis que não serão mais utilizadas. O PHP registra as variáveis de sessão na variável global $_SESSION.

As variáveis $_FILES, $_REQUEST E $_SESSION são variáveis pertencentes ao grupo das SUPER GLOBALS, ou seja, 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. Diferentemente das variáveis de globais de script que são redefinidas a todo momento, sempre que o usuário recarrega a página, ou seja, quado executa qualquer ação no ambiente.

Na variável $_SESSION são registrados dados de permanência de navegação do usuário, como o objeto AMUser, que contém os dados do usuário logado. Também são registrados cache de consultas executadas com mais freqüência, como a lista de amigos e projetos do usuário, isso faz com que o ambiente fique um pouco mais rápido. A sessão também pode ser usada por ferramentas do AMADIS, para registro de dados temporários ou para fins de consistências das operações solicitadas.

A variável $_CMAPP, é uma variável global de script, utilizada para guardar informações referentes a configuração da plataforma. Nela são registrados 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 AMADIS. A grande facilidade de compor uma tela utilizando-se de técnicas como o MVC, é a possibilidade de poder ter no controlador uma única chamada que despacha uma série de ações encapsuladas em uma classe de apresentação dos dados. A estas 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 na contrução da visualização de uma aplicação. O AMADIS possui dois tipos de widgets: Templates e Boxes(caixa). Os templates correspondem a uma construção primitiva de uma página, neles são contidos os menus, barra superior e rodapé da página que será exibida.

Os widgets do tipo box são utilizados inseridos nos templates, eles são a implementação mais básica de componentes de interface, pois somente possuem propriedades de aparência e renderização. Estes são comumentes utilizados de duas formas:

  • A primeira é como um renderizador, onde o controlador realiza uma consulta no banco de dados, através do modelo, ou executa qualquer outro tipo de operação e somente repassa para o widget informações prontas em formato html.
  • A segunda é em modo extendido, onde são criados widgets que extendem as propriedades dos box primários, e nele são criados mecanismos de interpretação das informação passadas pelo controlador.

Dentro das práticas de desenvolvimento utilizadas, a segunda é a mais comum, isso faz com que o código seja distribuído, mas dentro de uma lógica consistênte. Como o widget é o reponsável pelo processamento da informação que lhe é passada, ele torna-se mais portável, possibilitando a sua aparição em diversos pontos da aplicação, sem a necessidade de réplica de linhas de programação, facilitando a manutenção.

Como última instância de classes responsáveis pela geração de visualização do AMADIS, temos o CMHTMLObj do pacote CMDevel::CMInterface, este possui uma pilha de saída onde os objetos de interface são registrados, e assim que o comando de impressão é dado ele faz 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 na construção da interface tudo é tratado como um objeto. O único ponto fraco existente é a manutenção do código HTML dos widgets, pois o código HTML deve ser encorporado ao código PHP do mesmo. Isso significa que pra poder dar manutenção no layout o desenhista fica na dependência do desenvolvedor.

Uma re-modelagem deverá ser feita para as próximas versões do ambiente, pois este modelo apresentado ao mesmo tempo em que facilita na construção da interface em geral, gera uma forte demanda em momentos de manutenção ou re-implementação de um widget, justamente por ter o conteúdo de exibição e parte da lógica misturados, tornando impossível a visualização do componente fora do AMADIS. O novo modelo proposto será o de utilizar um script do tipo fastTemplate(Modelo rápido) que possibilita ter todo o conteúdo de visualização em HTML serparado da lógica do widget. O fastTemplate funciona por métodos de busca e substituição de conteúdos de texto, e pode ser um caminho em que o processamento na construção de uma tela pode aumentar bastante, por este motivo ainda está sob estudo da equipe de mantenedores.

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: este modelo é o mais utilizado dentre os três modelos, é que o possui o funcionamento mais simples e apresenta a melhor performance, Neste modelo, o programador monta as seus comandos SQL e os envia ao banco de dado através de um provedor. Com o uso deste modelo a maioria dos desenvolvedores optam por criarem seus próprios frameworks, visando diminuir a quantidade de trabalho gerado pelo modelo.
  • Modelo Prevalência: este modelo trabalha sobre a perspectiva de que os dados devam ficar 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 é, salvar todas as trasações que estejam na memória no disco rígido, afim de não se perder dados durante uma queda de luz, ou 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 campos do seu banco de dados. Existem várias formas de fazer esse mapeamento, alguns frameworks utilizam a linguagem XML, outros trabalham sobre o a construção de interfaces que obrigam ao desenvolvedor a implementar algumas regras, todos com o mesmo objetivo de 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 a geração de comandos dinâmicos, o framework pode analisar qual banco de dados a aplicação está acessando e 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, pois para uma aplicação como o AMADIS, que possui um número muito elevado de consultas SQL e por consumir muito em memória com a geração de consultas não seria possível utilizar os outros dois modelos. Por este movito é 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 correspondente a camada de modelo, essa que é responsável pela manipulação de dados da plataforma. Os dados trabalhados aqui não restringem-se 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, pacote de persistência de dados do CMDevel Framework, como mensionado anteriormente, ele realiza a construção das consultas e fornece a possibilidade 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 criação de rotinas de trabalho sobre elas. Desta forma o desenvolvimento do AMADIS e de suas ferramentas foi facilitado, pois nos primórdios do desenvolvimento de ambientes virtuais dentro do LEC, as coisas não eram tão estruturadas, mas mesmo assim ainda ter muito a ser melhorado.

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 que envolvem somente um único dado registrado no banco de dados. 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. Para consultas mais expressivas, como listagens e buscas, é utilizado o CMQuery, pois este sim é preparado para gerar listas de CMObjs, já que 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.

Distribuição dos Arquivos

Para a organização dos arquivos do AMADIS foi adotado um modelo semelhante ao usado no Gnu/Linux, que contempla uma organização em diretórios sob um modelo de separação de contextos, onde arquivos de funcionamento semelhante, residem dentro do mesmo diretório. Este padrão de distribuição contribui para uma melhor localização e organização dos módulos e suas dependências, embora cause alguns problemas, como por exemplo, o não encapsulamento das ferramentas da plataforma. Pois as mesmas tem seus arquivos espalhados pelas pastas do AMADIS. Mas isso pode ser resolvido com a utilização de um script de instalação de novos pacotes, que ainda não encontra-se disponível para uso.

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 nao favorece a utilização de modularidade, pois o mais comum é fazer uma concentração dos pacotes, de modo que a simples remoção do diretório o faça não aparecer mais no ambiente. Mas para um desenvolvimento desse nível o AMADIS precisaria ter modos de interagir com os pacotes. Mas isso fica para as próximas versões.

Considerações finais da Arquitetura

O AMADIS ainda precisa sofrer algumas mudanças de arquitetura para atingir o patamar de software modular. Embora as ferramentas estejam bem distribuidas, o MVC ainda não apresenta uma implementação bem difundida dentro do Core, tornando a interpretação do código um pouco confusa. Além dele possuir algumas implementações desastradas, que estão em remodelagem e re-implementação.

Outro ponto de evolução que esperá-se 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. E a diminuição de carga de processamento nos controladores, pois os mesmos, em algumas partes, realizam operações que seriam do View ou Model gerando problemas de manutenção. Estes são efeitos de desenvolvedores em apredizado e que faz parte de todo grande projeto 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