Arquitetura do Sistema

Numa primeira fase de definição de um projeto é necessário proceder-se à organização do sistema em análise. Este procedimento reflete uma estratégia de estruturação da aplicação a ser desenvolvida. Desta forma, a definição da arquitetura de um sistema de software é uma fase importante que não pode ser negligenciada.

A decisão acerca da estrutura da arquitetura do modelo deve ser definida com base nos requisitos e sempre numa fase inicial do projeto, onde ainda não foi tomada qualquer decisão operacional. Uma boa estruturação lógica do projeto é fundamental, uma vez que quando o processo criativo de arquitetura terminar será necessário desenvolver “fisicamente” a aplicação. Apesar de cada sistema de software ser considerado ímpar, sistemas que atuam em áreas análogas possuem arquiteturas similares. Estas arquiteturas, de acordo com o sistema a desen- volver, podem apresentar estruturas genéricas ou muito particulares.

Para o caso de estudo concreto, após análise de todos os requisitos de sistema e operacionais procedeu-se à seleção de um estilo de modelo organizacional. Embora existam vários modelos amplamente utilizados e referenciados na literatura [10] optou-se pela utilização do modelo em camadas com caraterísticas específicas, por se revelar o mais adequado. Este modelo organiza o sistema em camadas de forma a que cada uma possua as suas especificidades e disponibilize um conjunto de serviços dedicados ao seu contexto. Cada camada possui um conceito abstrato que pode ser visto como uma diferente “máquina” no sistema que disponibiliza serviços. Nesta fase de projeção de arquitetura o modelo é ainda independente da linguagem de programação. Numa etapa posterior a arquitetura é aplicada a uma linguagem máquina real, cumprindo desta forma os requisitos operacionais do sistema.

A abordagem do desenvolvimento da arquitetura em camadas proporciona um desenvolvi- mento incremental do sistema, ou seja, à medida que a camada é desenvolvida e atualizada, os seus serviços podem ser disponibilizados ao utilizador. É ainda uma arquitetura que pode ser facilmente modificada e é considerada portátil, uma vez que uma camada pode ser substituída por outra equivalente, desde que a interface permaneça inalterada. Quando existe a necessidade de se alterar a camada de apresentação, ou quando são adicionados novos recursos, apenas a camada adjacente é afetada. As camadas mais internas possuem uma forte dependência de recursos dos sistemas operativos ou das bases de dados. Estas dependências são suavizadas

à medida que se caminha para camadas mais externas, não sendo no entanto, completamente independentes do sistema. A principal desvantagem é a dificuldade em estruturar corretamente este modelo, uma vez que as camadas internas podem fornecer recursos de tal maneira básicos que serão necessários em todos os níveis. Esta interação pode contrariar o princípio básico de independência entre camadas.

Para o caso em análise, foi utilizado o modelo em camadas de forma personalizada, cons- tando as 3 principais camadas: camada de persistência, camada de negócios e camada de apresentação. Foi ainda utilizada uma camada que prevê a implementação de funcionalidades inerentes aos modelos de otimização definidos. De forma abstrata pode definir-se o modelo através do esquema representado na Figura 7.1.

Base de Dados Camada de Persistência JDBC:ODBC Camada de Negócios Camada de Apresentação Modelos de Otimização CPLEX GLPK LPSolve Outro Solvers Modelo em Ficheiro Solução em Ficheiro

Figura 7.1: Arquitetura do módulo de otimização

De forma a cumprir os requisitos operacionais, foi necessário criar uma ligação através da ponte entre ODBC (Open Data Base Connectivity ) e JDBC (Java Database Connectivity ) e a ca- mada de persistência, também conhecida como camada de dados. Uma ponte JDBC-ODBC consiste na utilização de um driver JDBC que utiliza um driver ODBC para estabelecer a cone-

7.1. Descrição Geral 79 xão à base de dados de destino. Este driver converte invocações através do driver JDBC em chamadas a funções ODBC. Esta conexão permite a troca de informação entre a base de dados e a referida camada, sendo que todos os serviços disponibilizados se encontram diretamente relacionados com leitura, escrita e atualização de dados.

A camada de negócios gere e implementa todas as funções que lidam com dados e objetos que de alguma forma se encontram independentes da base de dados. Nestas camadas são definidas funções específicas da área de negócio que muitas vezes implicam cálculos numéricos, manipulação de dados, verificações, entre outras. Esta camada comunica diretamente com a camada de persistência, não existindo uma comunicação direta com a base de dados.

A interface, conhecida como camada de apresentação, permite a interação da aplicação com o utilizador final, podendo conter funções disponibilizadas globalmente ou funções que necessi- tam de permissões especiais, como é o caso de conFigurações internas da aplicação que não se devem encontrar disponíveis para o utilizador comum. Esta camada comunica diretamente com a camada de negócios, tendo desta forma acesso a dados calculados e verificados. Comunica ainda com uma camada onde são definidos os modelos de otimização através de uma interface que possibilita a interação entre diversos solvers de otimização, sendo a linguagem de modelação genérica. A interação entre os diversos solvers de otimização é disponibilizada através de uma interface denominada, neste caso concreto, por Java ILP.

Java ILP é uma interface Java que permite código de otimização independente do solver. Esta interface é direcionada para solvers que resolvam problemas de programação linear e inteira. Permite a ligação a solvers comerciais ou livres e fornece uma interface orientada a objetos simples que tem como objetivo o aumento da facilidade de desenvolvimento. A maior parte dos solvers são desenvolvidos em linguagem C/C++ o que faz com que a conFiguração de matrizes, variáveis inteiras, entre outras, seja complexa. Os solvers suportados por esta interface são:

• Lp_solve – licença gratuita LGPL (http://lpsolve.sourceforge.net/5.5/) • ILOG CPLEX – licença comercial, versão trial limitada e versão académica gratuita dispo-

níveis (http://www.ilog.com/products/cplex/)

• Gurobi – licença comercial, verão académica gratuita disponível (http://www.gurobi. com/)

• Mosek – licença comercial, versão trial limitada disponível (http://www.mosek.com/) • GLPK – licença gratuita GPL (http://www.gnu.org/software/glpk/)

• MiniSat+ – licença gratuita MIT (http://minisat.se/MiniSat+.html)

No caso de ser invocado um serviço que prevê a construção de um modelo de otimização, na camada que contém as funcionalidades inerentes aos modelos de otimização desenvolvidos, esta gera um ficheiro em formato específico para os modelos de otimização (formatos LP - Linear Programming, MPS - Mathematical Programming System, entre outros) que poderá ser posteri- ormente importado.

A camada de apresentação interage com a camada de modelos de otimização de forma a que o problema seja processado com a instância pretendida. Após obtenção de uma solução válida, a interface permite a disponibilização dessa solução em formato de ficheiro, a título de exemplo, pdf.

Este sistema será desenvolvido recorrendo à linguagem de programação Java [11], sendo a interface desenvolvida em ambiente JAVA FX, por ser considerado mais flexível em termos de apresentação gráfica de elementos. Por esta ser uma linguagem de programação específica para sistemas orientados a objetos, a interação entre camadas será feita entre entidades, onde os objetos invocam serviços atribuídos por outros objetos. Estas entidades gerem a manutenção do sistema localmente e comunicam internamente através das diferentes camadas. Sistemas desenvolvidos com estratégias orientadas aos objetos são mais fáceis de modificar em relação a outras abordagens.