A concepção/desenho da aplicação web implementada teve como referência o padrão MVC, com um nível de apresentação, um nível de lógica de negócio e um nível de dados. O seu funcionametno recorre ao modelo cliente-servidor e a estruturação de todas fontes seguiu uma estrutura modular. O padrão MVC [Wikipedia, 2007] é uma recomendação para arquitecturas de software que defende a separação de uma aplicação em três camadas: Model (Modelo); View (Vista) e Controller (Controlador). Isto é feito de tal forma que quaisquer alterações numa das partes (componentes) possam ser feitas em qualquer altura sem que isso implique alterações/impacto nas outras partes.
5.4.1 Componentes da arquitectura
O nível de apresentação é suportado por um browser (cliente fino/leve) que acede ao servidor por HTTP (sobre uma ligação TCP/IP). O nível de lógica de negócio é suportado pelo servidor aplicacional ZOPE-2 [Fulton, 1998]; [Fulton, 2005] com as diversas classes implementadas em Python [van Rossum, 1991] e em Java. O nível de
dados é suportado por uma base de dados relacional (mySQL). A Figura 17 ilustra o padrão MVC implementado.
Zope Page Templates; HTML Lógica de negócio: Ferramenta de autoria de diálogos Python; JAVA Dados mySQL
Ligação HTTP sobre TCP/IP
Conectores para mySQL Apresentação Zope Page Templates;
HTML Lógica de negócio: Ferramenta de autoria de diálogos Python; JAVA Dados mySQL
Ligação HTTP sobre TCP/IP
Conectores para mySQL Apresentação
Figura 17: Padrão MVC implementado
O diagrama da Figura 18 detalha os principais componentes da ferramenta e o modo de interacção entre eles, numa perspectiva mais detalhada do padrão MVC implementado. Interface de Utilizador: web browser (cliente) Autor http
Ferramenta de autoria de diálogos para o Midiki
Servidor Aplicacional ZOPE (com plugin ZetaDB) Núcleo da aplicação web mySQL Ambiente de execução JAVA Biblioteca JAR com as classes geradoras Chamada : Classes geradoras Retorno: ficheiro(s) Java compiláveis com Midiki Cliente Servidor Interface de Utilizador: web browser (cliente) Autor http
Ferramenta de autoria de diálogos para o Midiki
Servidor Aplicacional ZOPE (com plugin ZetaDB) Núcleo da aplicação web mySQL Ambiente de execução JAVA Biblioteca JAR com as classes geradoras Chamada : Classes geradorasChamada : Classes geradoras
Retorno: ficheiro(s) Java compiláveis
com Midiki
Cliente Servidor
O ambiente de execução da ferramenta é o ZOPE, o qual inclui um servidor web integrado e apresenta mecanismos próprios para a geração de páginas HTML dinâmicas (as ZOPE Page Templates ou ZPT). Um documento ZPT pode ser editado com um editor HTML standard, permitindo um tratamento separado de cada parte do desenvolvimento (apresentação, lógica de negócio e dados). O ZOPE integra um interpretador Python e possui conectores para os principais sistemas de gestão de bases de dados, nomeadamente mySQL. Permite igualmente a ligação a funcionalidades externas através da invocação indirecta de classes Python externas, as quais permitem aceder, por exemplo a bibliotecas/pacotes JAR. Sobre o ambiente ZOPE de base instalamos o product ZetaDB [Camps, 2003]. Os products no ZOPE correspondem a módulos (ou plugins) que adicionam funcionalidades extra ao Zope. O ZetaDB facilita o desenvolvimento de aplicações web, sobre Zope, baseadas em dados. A ligação da lógica de negócio ao nível de dados é efectuada sobre conectores ZOPE e Java (para mySQL).
A estrutura de pastas e objectos de “código fonte” criados reflecte igualmente a separação modular e por níveis MVC: Cada funcionalidade principal disponível na aplicação final possui uma correspondência com uma determinada parte do código fonte. Por sua vez, cada uma dessas partes (ou módulos) apresenta e distingue claramente os objectos que dizem respeito à apresentação, à lógica de negócio ou aos dados.
5.4.2 A base de dados que suporta a ferramenta
A base de dados armazena toda a informação sobre os diversos projectos em implementação. Inclui ainda tabelas de suporte e gestão (ex.: utilizadores e
passwords, etc). As tabelas que compõem a base de dados relacional são
sumariamente descritas nos parágrafos seguintes.
A tabela “project” guarda informação de gestão dos vários projectos/diálogos que sejam criados. Um projecto será sempre detido por um utilizador. Um projecto serve de referência para agrupar toda a informação de um diálogo tal que, um diálogo está relacionado com um projecto de forma biunívoca. Para cada projecto existe apenas um domínio e um léxico e podem existir várias cells e handlers.
A tabela “cell” guarda informação relativa às cells criadas. Uma cell pertence a um projecto e um projecto poderá incluir várias cells.
A tabela “cellattribute” (corresponde aos slots) guarda informação relativa aos nomes dos slots a criar e tipos de atributos que podem conter.
A tabela “cellquery” guarda informação relativa à associação entre estratégias do tipo
QueryCall e as queries/handlers que deverão implementá-las.
A tabela “cellmethod” guarda informação relativa à associação entre estratégias do tipo MethodCall e os methods/handlers que deverão implementá-las.
A tabela “handler” contém a indicação dos nomes dos handlers de cada query ou
method. O nome de um handler corresponde a uma classe Java chamada para tratar
uma query ou um method.
A tabela “domain” guarda informação relativa ao domínio de um diálogo. É ao nível do domínio que são criados os planos.
A tabela “plan” guarda informação relativa aos planos criados. Um plano pertence a um domínio. O detalhe do plano em termos de estratégias será dado por registos na tabela “strategy”.
A tabela “attribute” guarda informação de base de um atributo do domínio. A lista de valores de cada atributo é guardada na tabela “attributevalue”.
Na tabela “strategy” cada registo guarda informação relativa a uma estratégia de um determinado plano.
A tabela “strategytype” guarda informação de referência sobre os tipos de estratégias suportados pela ferramenta. Os tipos de estratégias são descritos no Anexo II.
A tabela “questiontype” guarda informação relativa à associação entre estratégias do tipo Findout e tipos de atributos para um determinado domínio/diálogo.
A tabela “movetype” guarda informação de referência sobre os tipos de dialogue moves suportados pela ferramenta. Os tipos de dialogue moves são descritos no Anexo II.
A tabela “lexicon” guarda informação relativa ao léxico de um projecto. É ao nível do léxico que são criados input e output matches.
Na tabela “outputmatch” cada registo descreve um output match num diálogo.
Na tabela “inputmatch” cada registo descreve um input match num diálogo.
A tabela “inomconstructtype” guarda informação de referência sobre os tipos de construtores de entrada para os output matches suportados pela ferramenta. Esses tipos de construtores são descritos no Anexo III, embora apenas sejam relevantes ao nível do código Java pois são manipuladas de forma transparente pela ferramenta.
A tabela “outomconstructtype” guarda informação de referência sobre os tipos de construtores de saída para os output matches suportados pela ferramenta. Esses tipos de construtores são descritos no Anexo III.
A tabela “outimconstructtype” guarda informação de referência sobre os tipos de construtores de saída para os input matches suportados pela ferramenta. Esses tipos de construtores são descritos no Anexo III.
A tabela “synonym” guarda informação da definição de sinónimos. Cada sinónimo é guardado num registo da tabela “synvalue”.
Na tabela “generics”, para cada projecto, são guardadas strings de texto a serem utilizadas nos input ou output matches genéricos.
O modelo entidade-relação da base de dados é apresentado no no Anexo V.