Arquitetura da Plataforma 1.x

Da AMADIS

(Diferença entre edições)
(Variáveis globais)
(finalizações)
 
(9 edições intermédias não apresentadas)
Linha 1: Linha 1:
==Introdução==
==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, trouxe muitas melhorias à plataforma.
+
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 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.  
+
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==
==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].
+
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 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.
+
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 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:
+
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)
-
[[image:mvc.jpg|thumb|600px|center|Diagrama de fluxo de execusão sobre o Desing Pattern MVC]]
+
[[image:mvc.jpg|thumb|600px|center|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.
+
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 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.
+
''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===
===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
+
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.
-
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 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 $_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.
+
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.
-
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.
+
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.
-
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.
+
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.
-
==Manipulação e renderização da interface==
+
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.
-
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.
+
==Manipulação e renderização da ''interface''==
-
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 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'').
-
:* 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.
+
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.
-
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.
+
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.
-
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.
+
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.
-
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.
+
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''.
-
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.
+
 
 +
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.
[[image:templates.png|thumb|600px|center|Diagrama sobre a construção da interface]]
[[image:templates.png|thumb|600px|center|Diagrama sobre a construção da interface]]
==Banco de Dados==
==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.
+
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 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.
+
* '''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.  
-
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.
+
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.
-
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.
+
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,
-
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.
+
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:
Abaixo segue diagrama de como funciona a estrutura de uma classe ''Model'' dentro do AMADIS:
Linha 76: Linha 80:
[[image:modelo.png|thumb|600px|center|Representação do model dentro do AMADIS.]]
[[image:modelo.png|thumb|600px|center|Representação do model dentro do AMADIS.]]
-
==Distribuição dos Arquivos==
+
==Sistema 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.  
+
 
 +
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:
Abaixo segue em detalhes a árvore de diretório do AMADIS:
Linha 107: Linha 112:
     |_boxes        **widgets do tipo caixas
     |_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.
+
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==
==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.
+
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==
==Referências Bibliográficas==
CHISTOPHER, A.
CHISTOPHER, A.

Edição actual desde as 01h01min de 1 de Setembro de 2006

Í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