3.2. Análise Funcional do Sistema
3.2.1. Definições
Antes de se iniciar a Análise Funcional é necessário definir conceitos importantes para a correcta compreensão do sistema que se pretende analisar.
Portal
Um portal consiste num grupo de páginas Web que estão, por norma, associadas a utilizadores, cujo acesso, organização e permissões é gerido por um conjunto de utilizadores- administradores desse portal.
Actualmente e por norma, todos os Portais suportam páginas Web dinâmicas que são constituídas por uma ou mais janelas. Cada janela contém um ou mais Portlets. Por sua vez, um
Portlet tem associado uma lógica de negócio do lado do servidor e uma interface do lado do
cliente.
Portlet
Portlets são componentes orientados à Web que disponibilizam conteúdos dinâmicos. Os Portlets são suportados em páginas Web dinâmicas e, devido ao facto de terem especificações
padrão de desenvolvimento (na especificação Java EE), são reutilizáveis e portáveis. Esta característica fez com que os Portlets ganhassem bastantes adeptos no desenvolvimento de portais para a Web. (Oracle) Na Figura 5 é possível visualizar um exemplo de Portlets num portal.
Arquitectura do Sistema
15
Figura 5 – Exemplo de um Portal com Portlets
Business Intelligence
Os sistemas de Business Intelligence (BI) pretendem melhorar a disponibilidade e qualidade da informação gerada por um sistema. Para tal é necessário conjugar dados com um conjunto de ferramentas analíticas de forma a se obter informação relevante para a tomada de decisão.
Os sistemas de BI extraem informação útil através de ferramentas de análise, a partir de dados recolhidos das operações do sistema que integram. As tarefas associadas ao BI e à respectiva gestão do conhecimento, são:
Análise dos dados históricos e actuais da organização para elaboração de previsões;
Criação de possíveis cenários na introdução ou alteração de variáveis;
Permitir a análise e o acesso a dados para responder a questões não predefinidas;
Análise detalhada da organização (aprofundamento do conhecimento).
Dashboard
Dentro do conceito de BI existem vários conceitos importantes mas, dada a extensão do tema, o enfoque da Dissertação foi restringido à integração da componente de BI num sistema MRM. Como tal, o conceito mais relevante é o de dashboard.
Um dashboard pode ser traduzido como um «Painel de Indicadores». Em BI, os indicadores são o resultado das tarefas de análise dos dados através de ferramentas analíticas adequadas. Os indicadores são normalmente representados por diferentes tipos de gráficos. Por sua vez, os tipos de gráficos têm que ser adequados aos dados que se pretendem apresentar como indicador.
Assim, um dashboard pode ser definido como um conjunto de gráficos/indicadores resultantes dos processos de análise de dados associados ao BI, com o objectivo de apoiar a tomada de decisões. Na Figura 6 é possível visualizar um exemplo de um dashboard constituído por Portlets.
Arquitectura do Sistema
16
Figura 6 – Exemplo de um Dashboard
Deslocação, Movimento, Percurso
O sistema MRM descrito centra-se nos conceitos de deslocação, movimento e percurso. Uma deslocação tem sempre associada a si um local georreferenciado (uma coordenada de GPS), uma ou mais tarefas a executar nesse local e um ou mais recursos necessários para a sua execução.
Se duas deslocações forem representadas como dois pontos num mapa, um movimento será a linha que une esses dois pontos. Ou, por outras palavras, um movimento num mapa georreferenciado interessa apenas o ponto de partida e o ponto de chegada, independente do trajecto adoptado para chegar do inicial ao final.
Assim, um percurso será um conjunto de movimentos cujos pontos de chegada são iguais aos pontos de partida do movimento seguinte, excepto no caso do primeiro e último movimento de um percurso.
Estes conceitos foram elaborados aquando da concepção do modelo relacional da base de dados. A dissecação de percursos em movimentos e movimentos em deslocações foi a solução encontrada mais eficaz para persistir os dados necessários.
3.2.2. Actores
Os principais actores do sistema incluem:
Utilizador não autenticado – Utilizador não registado ou que ainda não efectuou a
autenticação no sistema. Não possui qualquer tipo de permissões de acesso ao sistema a não ser, o acesso à página inicial do portal e ao formulário de autenticação.
Operacional – Utilizador registado e autenticado no sistema, com permissões de acesso
através de um portal Web ou aplicação para dispositivos móveis. Considerados os utilizadores de Front Office, terão acesso à informação relativa à sua actividade e ao preenchimento de pequenos relatórios pré-definidos.
Operador – Utilizador registado e autenticado no sistema, com permissões de acesso
Arquitectura do Sistema
17
os recursos da organização de acordo com as funcionalidades do sistema e lógica do contexto empresarial.
Administrador – Utilizador registado e autenticado no sistema com permissão total sobre
todas as suas funcionalidades tais como, efectuar operações relativas à gestão de utilizadores e manutenção do sistema.
3.2.3. User Stories
As User Stories são uma definição de alto nível dos requisitos do sistema. Faz parte das metodologias ágeis de desenvolvimento de software, mais especificamente da metodologia
Extreme Programming (XP) e desempenha um papel importante no planeamento da
implementação. (Wells, 2010)
Segue-se a apresentação das User Stories do sistema, cada ponto corresponde a uma única
User Story e pode representar um requisito funcional ou não funcional:
Os utilizadores não autenticados no sistema têm que se autenticar obrigatoriamente.
Os utilizadores autenticados podem configurar os seus dados de acesso ao sistema.
Os utilizadores autenticados podem alterar os seus dados pessoais.
Os utilizadores podem consultar os dados de Business Intelligence desde que lhes seja dada permissão por um Administrador.
As deslocações devem ser atribuídas de acordo com parâmetros de optimização.
As deslocações devem ser geridas apenas através do Back Office por um Operador ou, sempre que possível, automaticamente pelo sistema.
Os Operadores podem gerir operacionais, tarefas, deslocações e percursos.
Os Operadores podem atribuir percursos constituídos por deslocações a operacionais.
Os Operadores devem certificar-se que as tarefas são associadas a deslocações e atribuídas a operacionais cumprindo os requisitos estabelecidos para o efeito, quer sejam atribuídas por si ou automaticamente pelo sistema.
Os Operadores terão acesso a um Sistema de Informação Geográfica para efeitos das suas operações.
Os Operadores podem elaborar relatórios de anomalias da operação do sistema.
Os Operacionais terão acesso ao sistema através dos seus dispositivos móveis.
Os Operacionais terão acesso aos percursos pré-estabelecidos e calculados, associados aos seus Planos de Tarefas do dia.
Os Operacionais poderão visualizar os percursos em dispositivos móveis apropriados.
O trajecto a percorrer entre as deslocações de um percurso será calculado pelo próprio dispositivo do Operacional, apropriado para o efeito.
Os Operacionais não podem gerir os seus Planos de Tarefas.
Os Operacionais, após uma deslocação, podem preencher individualmente um Relatório de Execução de Tarefas atribuídas a si para aquela deslocação.
Os Operacionais podem elaborar pequenos relatórios ou actualizar o seu estado de acordo com eventuais problemas ou reparos relacionados com a sua actividade.
Os Administradores podem modificar todas as configurações do sistema e operar com todas as funcionalidades no mesmo.
3.2.4. Fluxo de Dados
Na Figura 7 é apresentado o Diagrama de Fluxo de Dados do Sistema onde é possível verificar a lógica do funcionamento, a ordem das operações e as funcionalidades do sistema.
Com o objectivo de facilitar a percepção do funcionamento do sistema, no Diagrama de Fluxo de Dados referido só está representado a persistência dos objectos do tipo Tarefa através
Arquitectura do Sistema
18
do mapeamento objecto-relacional para a base de dados. Contudo, todos os dados gerados pelas actividades do sistema ou recolhidos pelo sistema são mapeados e persistidos em base de dados.
Os Operadores de Back Office introduzem no sistema as tarefas a executar. Após essa introdução, o sistema deve fazer o planeamento e o escalonamento das tarefas segundo critérios de prioridade e disponibilidade dos recursos necessários à sua execução. As tarefas são associadas a deslocações que vão constituir os percursos a efectuar pelos Operacionais durante um dia. Após o planeamento e o cálculo dos percursos, o sistema atribui os mesmos aos Operacionais, constituindo o Plano de Tarefas a ser executado no dia. Os Operacionais preenchem Relatórios de Execução de Tarefas no final da execução das tarefas associadas a uma deslocação. A actualização da localização dos colaboradores é feita aquando da submissão dos referidos relatórios ou aquando da actualização do estado do colaborador.
Na componente de BI, através da respectiva plataforma e com recurso a ferramentas analíticas faz-se a selecção dos dados relevantes da Base de Dados Operacional (BD OLPT) (dados gerados e recolhidos pelo sistema). Faz-se também a respectiva modelação e armazenamento numa Data Warehouse através de um processo de ETL. Depois procede-se à construção e apresentação dos dashboards com todos os indicadores pretendidos.
Figura 7 - Diagrama do Fluxo de Dados da Aplicação
3.3. Arquitectura Física
Na
Figura 8 é apresentado a estrutura física de alto nível do sistema a desenvolver, o Diagrama da Arquitectura Física.
Arquitectura do Sistema
19
Arquitectura do Sistema
20 Os principais intervenientes incluem os seguintes:
Dispositivo móvel – pode ser Tablet PC, PDA, smartphone ou outro dispositivo móvel
capaz de suportar as funcionalidades pretendidas para os Operacionais através do Portal.
Computadores pessoais – máquina a partir do qual é possível aceder ao sistema e operar
no mesmo de acordo com o tipo de utilizador e as funções designadas ao mesmo. Não necessariamente apenas a partir da intranet mas também, a partir da rede externa.
Servidor Web – máquina onde será alojada a aplicação ou plataforma do sistema.
Servidor de Base de Dados – máquina onde será alojada a Base de Dados necessária ao
funcionamento do sistema.
3.4. Arquitectura do Software
3.4.1. Modelo da Arquitectura
Sendo um dos requisitos a garantia de uma aplicação empresarial completamente de Código Aberto, foi decidido que toda a Arquitectura do Software deveria assentar sobre plataforma Java.
Esta opção foi feita com base na necessidade da interoperabilidade e compatibilidade entre diferentes frameworks e com a eventual necessidade de integração com outros sistemas. Além disso, para integrar esta solução foram estudadas as melhores ferramentas, frameworks e plataformas de Código Aberto para integrar a solução. Após esse estudo, concluiu-se que o conjunto de frameworks e plataformas seleccionadas são todas desenvolvidas com tecnologias Java. Desta forma, faz todo o sentido orientar e adequar a Arquitectura de Software à plataforma Java EE.
Assim, tratando-se de uma aplicação empresarial em Java e orientada à Web, a plataforma é necessariamente a Java Platform, Enterprise Edition (Java EE). Além desta, existe ainda a
Java Platform, Standard Edition (Java SE), a Java Platform, Micro Edition (Java ME) e a Java FX. (Oracle, 2010)
A plataforma Java EE foi construída sobre a plataforma Java SE. Assim, a plataforma Java EE além das funcionalidades da Java SE (desde classes básicas a classes de alto nível utilizadas para redes, segurança, acesso a base de dados, interfaces gráficas e XML parsing), disponibiliza uma API e um runtime environment para o desenvolvimento de aplicações empresariais de grande escala, multi-tiered (com áreas funcionais separadas em camadas chamadas tiers), escaláveis, estáveis e seguras. (Oracle, 2010)
A plataforma Java EE está concebida de forma a dar completa liberdade no desenho de arquitecturas de aplicações empresariais. Embora isso permita utilizar os componentes da plataforma ao gosto do arquitecto da aplicação, nem sempre as opções tomadas são as mais benéficas para o sistema onde será integrada. O arquitecto do sistema pode até encontrar situações em que ele próprio tenha dificuldade em decidir sobre a opção que optimiza a robustez e a eficiência da aplicação. Para colmatar as falhas que poderão surgir desta liberdade, a Sun (agora Oracle) criou o programa Java Blueprints. Este programa constitui um guia com exemplos concretos para que os programadores e arquitectos de sistemas sobre a Java EE saibam maximizar as suas vantagens, assim como identificar os modelos de arquitectura e de programação que melhor se adequam ao tipo de desenvolvimento e implementação das suas aplicações.
Com o programa Java Blueprints, a actual Oracle, pretende educar a comunidade Java através da definição de um conjunto de recomendações de modelos de programação das aplicações, de guias orientadoras e arquitecturas para cenários de aplicações no mundo real. Através deste programa faz ainda a divulgação das novas tecnologias e funcionalidades da
Arquitectura do Sistema
21
plataforma e aborda questões como escalabilidade, portabilidade e interoperabilidade, entre outros assuntos que tenham impacto no futuro e sucesso da plataforma Java. (Oracle, 2010)
Para a arquitectura no Java BluePrints podemos encontrar os padrões de arquitectura recomendados, os Java EE Patterns. Com estes padrões recomendados (padrões testados e com provas dadas) pretende-se solucionar problemas de projecto recorrentes e problemas das consequências e do impacto das soluções. (Oracle, 2010) Deste modo, a arquitectura de
software adoptada para a aplicação segue o modelo Model-View-Controller (MVC). (Oracle,
2010)
No modelo de arquitectura MVC faz-se a separação dos dados da aplicação (Model), da apresentação dos dados (View), e da lógica de negócio (Controller). Na Figura 10 é apresentado o diagrama que representa o modelo de arquitectura MVC. (Oracle, 2010)
Figura 9 - Modelo da Arquitectura Model-View-Controller (Oracle, 2010)
Esta organização, suporta melhor a escalabilidade (múltiplos utilizadores), facilita modificações e a manutenção das aplicações, já que as respectivas camadas podem ser desenvolvidas e testadas em separado.
3.4.2. Descrição da Arquitectura
Para a solução MRM pretende-se que a interface do utilizador do sistema seja desenvolvida e organizada num portal. Sob esse portal estará a funcionar a aplicação com toda a lógica de negócio, de acordo com a Análise Funcional e respectiva persistência. Assim, o portal deverá fornecer toda a informação e todos os dados necessários para as funções dos Operadores e dos Operacionais, segundo os requisitos da aplicação. Paralelamente existe a plataforma de
Business Intelligence, cujos indicadores (resultado das tarefas associadas ao BI) devem ser
visualizados no portal.
De acordo com a estrutura da aplicação descrita, na Figura 10 é apresentada a arquitectura de software genérica da aplicação, segundo a arquitectura MVC padrão. Nela é possível visualizar a estrutura e a organização das diferentes camadas da solução e a sua correspondência com o padrão MVC incluindo, a integração com as camadas associadas à componente de
Arquitectura do Sistema
22
Figura 10 – Arquitectura de Software da Aplicação (MVC)
Nas camadas mais baixas da aplicação que correspondem ao Model da arquitectura, encontram-se a Base de Dados e a Abstracção da Base de Dados. A Base de Dados com sistema OLTP (Online Transaction Processing), está encarregue de suportar todas as transacções necessárias em tempo real. Por sua vez, a camada de Abstracção da Base de Dados faz o mapeamento objecto-relacional. Este mapeamento permite relacionar as tabelas da Base de Dados com os objectos da linguagem de programação da aplicação ou, por outras palavras e neste caso, permite a persistência dos objectos da linguagem Java em Base de Dados.
No correspondente ao Controller da arquitectura existe a Integração Aplicacional. A Integração Aplicacional será o núcleo da aplicação que é desenvolvido em Java e que suporta toda a lógica de negócio e comportamento da aplicação.
Na componente View da arquitectura existe o portal que suporta todas as funcionalidades associadas à interface do utilizador da aplicação através de páginas Web dinâmicas.
Paralelamente irá funcionar a plataforma de Business Intelligence. A plataforma integra a solução de forma independente da aplicação. Esta inclui as suas próprias camadas e interface, com as respectivas ferramentas associadas às tarefas de Business Intelligence. Tem acesso à Base de Dados OLTP da aplicação e ao conhecimento da lógica de negócio, necessário para as ferramentas ETL (Extract, Transform and Load). Ou seja, a própria plataforma tem as ferramentas necessárias para a extracção dos dados da Base de Dados OLTP, a sua transformação e carregamento para uma Base de Dados que irá funcionar como armazém de dados, a Data Warehouse. Por fim, a plataforma integra-se na componente View da aplicação (no portal) através da visualização de dashboards, os indicadores de apoio à decisão.
3.5.
Tecnologias e Arquitectura
Um dos requisitos e factor de inovação da Dissertação é a concepção de uma solução com recurso exclusivo a tecnologias de Código Aberto. O estudo das tecnologias capazes de integrar a solução não é simples. As tecnologias envolvidas estão em constante evolução e de forma pouco linear. Tanto podem dar um salto qualitativo grande entre versões, como dar um salto pequeno apenas para correcção de bugs. O tempo entre os lançamentos das versões pode também variar consideravelmente, o que, por vezes, torna difícil de prever a sua evolução e o seu futuro.
Após o estudo das características das tecnologias candidatas à solução, foram feitos alguns testes de integração das mesmas. No resultado do estudo e dos testes efectuados, foram seleccionadas as tecnologias que reuniam as melhores características, em conformidade com a
Arquitectura do Sistema
23
arquitectura apresentada. Na Figura 11 são apresentadas as tecnologias seleccionadas para as diferentes camadas e módulos da Arquitectura de Software apresentada.
Figura 11 – Tecnologias da Arquitectura do Software
Para o portal foi seleccionado o Liferay Portal, versão 6.0. A Liferay apresenta uma infraestrutura de especificação e gestão de portais, tecnologicamente bastante evoluída e com bastantes implementações e aplicações reais. Apresenta clientes importantes como a CISCO, a T-Mobile, a China Mobile, etc.
A aplicação será implementada com recurso à framework desenvolvida pela SpringSource, a Spring Framework, versão 3.0.4. A SpringSource tem parceiros como a VMware, Accenture, JTeam, Terracotta, etc. A aplicação será desenvolvida de forma a responder às funcionalidades esperadas e será suportada no portal. Pretende-se assim que as operações dos utilizadores sejam executadas na aplicação através do portal.
Na camada de abstracção de dados são utilizadas algumas funcionalidades disponibilizadas pela Spring Framework, o módulo Spring ORM. O Spring ORM em conjunto com as funcionalidades de Mapeamento Objecto-Relacional do Hibernate3, constituem a camada de persistência da aplicação.
Os dados da aplicação são persistidos numa Base de Dados desenvolvida num servidor MySQL 5.1, com todas as tecnologias associadas.
A execução das tarefas de Business Intelligence estão a cargo da plataforma Pentaho, versão 3.6.0. A Pentaho disponibiliza uma suite completa, a Pentaho BI Suite, com as suas próprias ferramentas de ETL, Análise, Reporting e Data Mining. A plataforma Pentaho BI opera sobre a Base de Dados da aplicação e persiste os dados resultantes na sua própria Base de Dados do tipo Data Warehouse. Tal como o portal Liferay, a plataforma Pentaho tem duas versões, a Community Edition e a Enterprise Edition. No caso da Enterprise Edition, a Pentaho disponibiliza ainda uma ferramenta específica para a construção de dashboards.
As versões das tecnologias apresentadas são as versões finais (não beta) mais actualizadas até à data do início dos trabalhos da Dissertação. Apenas as ferramentas da Pentaho BI Suite não têm especificada a versão porque estas pertencem à Suite mas funcionam e são lançadas de forma independente da Plataforma (mas operam sobre a mesma). Além disso, as tarefas de BI e o funcionamento das respectivas ferramentas não são o enfoque da Dissertação, apenas a sua integração na solução/sistema de MRM.
As tecnologias foram seleccionadas de forma a maximizar a sua integração e as respectivas funcionalidades. Toda a solução apresentada tem em comum a Spring Framework. Quer o Liferay Portal, quer a Pentaho BI Platform, têm uma parceria de desenvolvimento com a
Arquitectura do Sistema
24
SpringSource. Consequentemente, faz todo o sentido desenvolver a aplicação MRM também com recurso à Spring Framework.
A decisão sobre as tecnologias teve por base o seu grau de integrabilidade, as suas funcionalidades, a sua interface gráfica (importante no caso do BI) e o facto de terem, no geral, as tecnologias mais sofisticadas do seu Estado da Arte.
Para trabalhar nas tecnologias e frameworks apresentadas para o desenvolvimento da solução é necessário ter um conhecimento alargado das tecnologias Web da plataforma Java EE, das respectivas linguagens e funcionalidades. Na Figura 12 é apresentado um sumário de todas as tecnologias envolvidas, em função das respectivas camadas da aplicação.
Figura 12 – Tecnologias e Linguagens Envolvidas nas Respectivas Camadas da Aplicação
Na Figura 12, é possível concluir que as tecnologias envolvidas na Dissertação são de facto extensas e que além de oferecerem um leque grande de hipóteses de desenvolvimento, permitem personalizar completamente a aplicação.
No capítulo seguinte, as arquitecturas e as tecnologias das frameworks de desenvolvimento apresentam-se com mais detalhe, resumindo-se as suas características principais e as suas potencialidades.
25
Capítulo 4
Frameworks de Desenvolvimento
No presente capítulo são apresentadas as arquitecturas, as tecnologias e as principais funcionalidades das frameworks de desenvolvimento utilizadas na solução empresarial, de forma ordenada: Spring Framework, Liferay Portal e Pentaho BI Platform.