En annen hermeneutisk tilnærming til Koran

Para finalizar a análise do Modelo do Domínio da Figura 3.15, falta ape- nas analisar a entidade “Botão de Listar Confs. Default” que efectua uma operação semelhante ao “Botão de Listar Confs. Utilizador”. Assim, quando o Utilizador clica nesse botão, é efectuado um pedido de listagem de configura- ções default da aplicação. Esse pedido é delegado pela entidade “Subsistema Persistência de Configurações” para a entidade Base de Dados (operação SQL de SELECT). Logo que esteja a listagem disponível na interface da aplicação, o Utilizador pode seleccionar a configuração default que desejar para poder efectuar operações de visualização e inserção, correspondentes às entidades “Botão de Visualização” e “Botão de Salvar Configuração”.

Tal como na operação de actualização de configuração de Utilizador, neste último caso (listar configurações default ) também tem que haver um mecanismo para preencher os campos do Formulário com a informação per- tencente à configuração seleccionada. Assim, o Utilizador pode visualizar, salvar configuração e, até, alterar os Parâmetros de Configuração do Formu- lário que achar conveniente, para persistir uma nova configuração que obteve com base em uma default.

3.5

Análise de Requisitos

Nesta secção vão ser analisados os requisitos (tarefas) que a aplicação terá de cumprir, de forma a que esta disponibilize todas as funcionalidades essenciais para o seu bom funcionamento.

Os requisitos funcionais da aplicação são os seguintes:

- Permitir ao utilizador autenticar-se e obter a autorização de acesso ao serviço Google Calendar (recorrendo ao protocolo híbrido OpenID/O- Auth);

- Suportar quatro tipos de visualização para painéis de digital signage: em ecrã inteiro (visualização Full), em coluna (visualização Column), em barra horizontal (visualização Bar) e em XML;

- Definir todos os parâmetros de configuração necessários para cada um dos quatro tipos de visualização (Full, Column, Bar e XML);

- Incluir suporte total a parâmetros de configuração da componente vi- sual, que diz respeito à personalização do aspecto da visualização (não incluir a visualização XML, uma vez que o aspecto visual é sempre o mesmo);

- Incluir suporte total a parâmetros de configuração da componente com- portamental, que engloba todo o comportamento definido para as visu- alizações (Full, Column e Bar) e certos comportamentos da aplicação (gestão de sessão);

- Incluir suporte total a parâmetros de configuração da componente de filtragem, que devem ser parâmetros de ordem temporal ou espacial para efectuar pedidos de eventos ao Google Calendar. Cada um dos quatro tipos de visualizações (Full, Column, Bar e XML) vão ter que suportar parâmetros de filtragem;

- Disponibilizar um formulário user-friendly para que o utilizador possa, facilmente, preencher os campos relativos a parâmetros de configura- ção;

- Permitir a persistência de configurações recorrendo a uma base de da- dos relacional;

- Permitir operações de actualização e de remoção de configurações; - Possibilitar que a aplicação tenha um conjunto de configurações pré-

definidas (configurações default ) para auxiliar o utilizador;

- Permitir que aplicações externas (principalmente o serviço Ubisign.com) utilizem a aplicação a elaborar e possam autenticar-se, obter autoriza- ção de acesso ao Google Calendar e enviar parâmetros de configuração através de query strings;

- Incluir manutenção de estado para os eventos que são retornados pelo serviço Google Calendar.

No que diz respeito aos requisitos não funcionais da aplicação a desen- volver, importa destacar os seguintes:

- Suportar a localização das datas/horas dos eventos apresentadas nas visualizações Full, Column e Bar, ou seja, a aplicação deverá ser capaz de exibir datas/horas de um evento no formato correcto, segundo as definições regionais do cliente que faz o pedido;

- Implementar abstracções ao nível da camada de negócio, de forma a que seja possível, no futuro, estender a aplicação para consumir eventos da Microsoft Exchange, Facebook, Eventbrite, etc.;

- Durante a implementação das visualizações Full, Column e Bar, é es- sencial que haja compatibilidade com o WPF Chromium WebBrowser, uma vez que o serviço Ubisign.com vai utilizar esse browser para em- butir a aplicação a elaborar.

Capítulo 4

A Aplicação DSEventApp

Uma vez terminada a especificação do problema (capítulo 3), ou seja, tudo o que se pretende com o projecto de software a desenvolver (aplicação web sobre apresentação de eventos em painéis de digital signage), vai-se dar início à solução do projecto.

Neste capítulo, após uma introdução mais completa, vai-se começar por detalhar os requisitos da aplicação a elaborar, no que diz respeito à quanti- dade de informação sobre eventos para as visualizações (Full, Column, Bar e XML). Também vão ser detalhados todos os parâmetros de configuração que cada tipo de visualização suporta.

De seguida, inicia-se a fase de especificação da aplicação, isto é, apresentar- se-ão os vários diagramas e esboços que auxiliam o desenvolvimento da apli- cação. Também é importante sublinhar que todas as boas práticas de de- senvolvimento de software vão ser cumpridas (separação entre a camada de visualização, lógica aplicacional e da camada de base de dados).

Na última secção deste capítulo, vai ser descrito todo o processo de de- senvolvimento e dar-se-á a conhecer todas as decisões relevantes tomadas. No final, vai-se demonstrar o funcionamento da aplicação.

4.1

Introdução

Ao longo deste capítulo vai ser descrita a solução a desenvolver, isto é, tudo o que está relacionado com a aplicação web que apresenta informação sobre eventos disponíveis no serviço Google Calendar. É de destacar que a aplicação será desenvolvida recorrendo à .NET Framework 3.5, utilizando a tecnologia ASP.NET MVC 2, juntamente com a linguagem de programação C#.

Como este capítulo vai ser dedicado exclusivamente à aplicação a desen- volver, frequentemente esta será designada por DSEventApp (Digital Signage Event Application). É de notar que o seu desígnio não está relacionado com o Google Calendar, uma vez que, no futuro, esta irá ser estendida para ou- tros serviços de gestão de eventos, como por exemplo: Microsoft Exchange,

Eventbrite, Facebook, etc.. Além disso, a sua lógica de negócio vai estar preparada para que o processo de extensão seja facilitado.

Num primeiro momento, serão detalhados os requisitos da DSEventApp no que diz respeito à quantidade de informação sobre eventos para as visuali- zações em ecrã inteiro (Full), em coluna (Column), em barra horizontal (Bar) e em XML. Também vão ser identificados e detalhados todos os parâmetros de configuração que cada tipo de visualização vai suportar.

De seguida, vai ser feita a especificação da DSEventApp ao nível de três camadas muito conhecidas no mundo do desenvolvimento de software: ca- mada da interface do utilizador, camada da lógica de negócio e camada de acesso à base de dados.

Ao nível da camada de interface, é importante referir que esta é caracteri- zada pelas interacções efectuadas pelo utilizador ao nível dos formulários de configuração e, também, pelas visualizações (Full, Column, Bar e XML) dis- ponibilizadas pela DSEventApp, com base em parâmetros de configuração. Desta forma, nesta primeira fase do capítulo, vão ser apresentados alguns mockups (esboços) relacionados com os componentes existentes na interface do sistema. De seguida, para uma mais fácil compreensão das interacções e comportamentos existentes nos formulários de configuração, vão ser apresen- tados dois diagramas de sequência de alto nível, que apresentam a sequência de acções que o utilizador pode efectuar (em resposta a essas acções, são apresentados os comportamentos do sistema).

No que diz respeito à camada de negócio, vai ser apresentado um dia- grama de classes por cada package especificado, sendo que cada um é com- posto por várias classes e respectivas interacções, e os seus métodos vão traduzir as funcionalidades que a aplicação terá de suportar.

Por fim, relativamente à camada de base de dados, como se vai recorrer à framework NHibernate para .NET (ferramenta ORM – Object Relational Mapping – que faz o mapeamento entre classes C# e relações de uma base de dados), vão ser especificadas as entidades (ou classes persistentes) e as tabelas que dizem respeito à base de dados (diagrama ER). Também importa dizer que se utilizará o motor de base de dados SQL Server 2005, e as tabelas vão servir, essencialmente, para armazenar parâmetros de configuração e dados de autenticação/autorização de utilizadores da DSEventApp.

Na segunda e última secção deste capítulo será descrito todo o processo de implementação, tomando decisões e apresentando soluções para os pro- blemas encontrados. Para terminar, vai ser apresentado um exemplo para cada visualização (Full, Column, Bar e XML) processada pela DSEventApp, juntamente com a respectiva query string de configuração.