7. Etablering og administrasjon av ordningen
7.8 Forvaltningstiltak ved brudd på forskriften og vedtak om tilskudd
A perspetiva de desenvolvimento, tem como objetivo a divisão da aplicação em diferentes componentes de software e a representação das suas relações e dependências [34]. Na Figura 35 é ilustrado o diagrama de componentes que diz respeito ao ambiente aplicacional do SDK a desenvolver.
É possível observar a divisão da aplicação em três packages principais, o SDKControls, o SDKEngine e o VortalNext>InternalServices. O primeiro package contempla os componentes que permitem a construção das aplicações, ou seja, são os componentes com os quais o utilizador do SDK vai interagir (elementos gráficos, ações, páginas, etc.) para desenvolver as aplicações de acordo com as suas necessidades. O package VortalNext>InternalServices é responsável por encapsular todos os serviços da plataforma Next> passíveis de serem usados para o acesso a informação e, por último, temos o package SDKEngine que contém os componentes responsáveis pela geração e compilação de código final de forma transparente para o utilizador. Este componente também é responsável por fazer o deploy das aplicações e por configurar o ambiente de execução das mesmas no servidor aplicacional.
A divisão do SDK em diferentes packages permite acelerar o processo de desenvolvimento e
facilitar a realização de testes, pelo facto de estes poderem ser tratados como componentes independentes. Esta divisão apresenta, também, a vantagem de permitir a separação física de componentes em servidores aplicacionais distintos [34] [35].
Vortal Development Software Kit
Perspectiva Lógica
A definição da perspetiva lógica do SDK foi concretizada recorrendo a diagramas de classe. Para tal, foi necessário ter em conta o leque de funcionalidades a fornecer aos utilizadores finais e, sempre que possível, foram utilizados padrões de desenho de software.
Design Patterns
Os padrões, representam soluções de software utilizadas para a resolução de um problema
recorrente, ou seja, representam o acumular de conhecimento de diferentes especialistas num determinado contexto. Apresentam-se como soluções extremamente vantajosas, pois já foram testadas e comprovadas em diversas aplicações e utilizadores [36] e pelo facto de promoverem a reutilização e modularização do código. Estes podem ser divididos em três categorias distintas, os padrões de criação, os padrões estruturais e os padrões comportamentais [37] :
Padrões de criação caracterizam-se por adequar a instanciação de objetos a diferentes tipos de situação. Representam uma forma de “esconder” a criação de classes concretas e a forma como estas se relacionam. Exemplos deste tipo de padrão são: factory, abstract factory e o singleton [37].
Padrões estruturais simplificam o desenho arquitetural pois definem formas mais simples de relacionar as diferentes entidades. O adapter, composite e facade são exemplos deste tipo de padrões [37].
Padrões comportamentais são utilizados de forma a identificar os diferentes processos de comunicação de um programa de software. Ajudam a reduzir a complexidade e quantidade de código para implementar uma determinada funcionalidade. Nesta categoria inserem-se os padrões strategy e memento [37].
Durante a definição do SDK foram utilizados, sempre que possível, padrões de desenho para garantir a qualidade e escalabilidade da solução (o motivo da utilização e os respetivos padrões serão explicados no capítulo 6.5). É importante referir que, a utilização de padrões é extremamente vantajosa pelo facto de permitir a resolução de problemas comuns no mundo da engenharia de software, mas a utilização de padrões de forma excessiva (over engineering) pode aumentar a complexidade da plataforma e, por consequência, prejudicar o seu
Vortal Development Software Kit
54
Controlos do SDK
Este package define os componentes aos quais o utilizador tem acesso para a criação das suas aplicações, nos quais pode definir diferentes tipos de comportamentos e ações. Este package é constituído pelas ações, pelos elementos gráficos, pelas fontes de informação e pelas entidades responsáveis por agregar todos estes: a aplicação e as páginas da aplicação. Os elementos representam os constituintes típicos de uma página web, como botões e tabelas onde podem ser associadas ações/eventos e fontes de informação. As ações, como o nome indica, representam interações do utilizador com a aplicação (p.e. carregar num link para abrir uma nova página) e as fontes de informação ou datasources representam segmentos de informação que podem ser apresentados em elementos de listagem como as tabelas (p.e. ter uma tabela com todas as mensagens recebidas).
As páginas representam as entidades agregadoras de elementos, ou seja, uma página tem diferentes tipos de containers (p.e. secção da esquerda e a secção central) que possuem, no seu interior, um conjunto de elementos que representam a aplicação pretendida pelo cliente. Por último existe a entidade aplicação, responsável por guardar todas as páginas e elementos introduzidos pelo utilizador. É esta que guarda informação como o estado da aplicação (Edição, Publicada, Em Aprovação e Rejeitada), a sua visibilidade (Pública ou Privada) e qual o utilizador com acesso à sua modificação. Através dos métodos disponibilizados por esta entidade, é possível aceder à hierarquia de elementos criada pelo utilizador e fazer a geração de código intermédio e final.
De referir a existência de um package denominado de Common, onde são definidas todas as classes utilizadas de forma global pelas entidade acima descritas. Neste package, são definidos os enumerados do SDK (p.e. o enumerado que contém os diferentes tipos de eventos do SDK e o que apresenta a lista de masterpages disponíveis para a criação de uma aplicação) e é também definida a classe responsável pelo logging das diferentes ações executadas pelo utilizador. O logging é um ponto bastante importante de uma aplicação pois permite registar todos os eventos relevantes da mesma que, mais tarde, podem ser utilizados para diagnosticar e resolver problemas graves. Para além deste facto, os logs podem também ser utilizados para efeitos de auditoria e para a responsabilização dos autores de determinadas ações.
Vortal Development Software Kit
Na Figura 36 é demonstrada a visão geral do package, com as relações entre os diferentes
tipos de entidades representadas. Cada um destes packages e entidades ilustradas são explicados com mais detalhe e de forma mais aprofundada com o decorrer deste capítulo.
Figura 36 – Package de Controlos
Elementos gráficos
Como já referido, os elementos gráficos (ViewElements) representam os elementos utilizados para a construção de uma página HTML típica. De todos os elementos existentes no contexto web, são de salientar, os botões, as labels’s, os fieldset’s, as grid’s e os seus constituintes, as textbox’s e os datepicker’s como os mais utilizados durante o desenvolvimento da plataforma Next>. Estes elementos apresentam diversos atributos em comum e por isso mesmo na Figura 39 é possível observar a existência de uma classe “pai” (BaseViewElement) que contém todos os atributos e métodos comuns e que cada elemento “filho” vai herdar e implementar. Neste package é possível observar a existência de um classe abstrata (ViewElementCreator) com um método abstracto denominado de CreateViewElement(). É também possível observar a sua especialização em diferentes classes “filho” que são responsáveis por garantir a implementação do método atrás referido. Este é um exemplo de implementação do padrão de desenho Factory Method.
O padrão Factory é utilizado de forma a definir uma classe para a criação de um objeto, onde as suas subclasses decidem qual a classe a instanciar [38]. Este padrão é, normalmente, utilizado quando se quer dar suporte e extensibilidade a uma determinada entidade (p.e. diferentes formatos de documentos), ou seja, quando se pretende encapsular o conhecimento
Vortal Development Software Kit
56
(ConcreteCreator) [38]. Na Figura 37 é apresentado um diagrama geral e simplificado do padrão Factory.
Figura 37 – Diagrama geral do padrão Factory [37]
Quando se pensa num SDK baseado em programação visual, rapidamente se conclui que é extremamente complexo antecipar todos os componentes que serão necessários. Para além disto, com o aumento do número de elementos do SDK é importante que existam classes especializadas na criação destes elementos (Concrete Factory), que saibam exatamente quais os atributos e propriedades a preencher de forma a atingir o comportamento esperado.
Assim, a implementação de uma padrão Factory para a criação de elementos gráficos foi a
solução encontrada de forma a colmatar estes problemas.
É possível fazer a divisão dos diferentes elementos representados na Figura 36 em elementos simples e elementos compostos. Os elementos simples são, como o nome indica, elementos constituídos apenas pelos seus atributos e pelos seus métodos, enquanto os elementos compostos são elementos que, no seu interior, podem ter um número indefinido de elementos (simples ou compostos), ou seja, podem no seu interior possuir uma hierarquia de elementos. No caso dos elementos representados os elementos compostos são os fieldset’s e as grid’s. Apesar de os elementos serem diferentes, para o utilizador final não é necessária essa separação de conceitos e, por isso, é necessário garantir um mecanismo que permita tratar de forma uniforme os objetos simples e os objetos compostos. Este problema pode ser endereçado através da utilização do padrão Composite.
O padrão estrutural Composite tem como objetivo compor objetos em estruturas de árvore (hierarquias) de forma a ser possível representar objetos simples e compostos de forma uniforme e transparente para o utilizador. Neste padrão os objetos simples não possuem qualquer “filho” e definem o seu próprio comportamento enquanto os objetos compostos garantem a lista de objetos simples e as operações relacionadas com os mesmos [38].
Vortal Development Software Kit
Figura 38 – Diagrama geral do padrão Composite [37]
Na Figura 39, existem duas aplicações do padrão Composite, uma no FieldsetViewElement e outra no GridColumnViewElement. Estes elementos, são capazes de possuir um número indefinido de elementos e é através do método WriteChildren() que a hierarquia de objetos é criada e garantida.
Vortal Development Software Kit
58
Todos os elementos possuem a implementação dos métodos Write(), WriteAttributes() e WriteActions(), sendo utilizados para a geração dos ficheiros XML finais que, mais tarde, dará origem ao código final (como explicado em 6.1).
Na figura é representada uma classe [ElementName]Creator com o intuito tornar a visualização e a compreensão do diagrama mais simples. Esta classe, representa os restantes Concrete Factories utilizados para a criação do fieldset, da grid e do datepicker ou de qualquer outro elemento que surja durante o ciclo de vida do SDK.
Ações
Os elementos gráficos de uma aplicação, não são componentes estanques, ou seja, são componentes que podem sofrer modificações durante o ciclo de utilização da página e que podem ter associados inúmeros eventos para, por exemplo, permitir a visualização de mais informação. Assim, um elemento gráfico pode conter a implementação de um variado número de eventos que, por sua vez, são responsáveis por originar uma ação.
A classe Events do package Actions é a classe que representa os eventos existentes e que contém a lista de ações a despoletar. Nesta classe existe um enumerado designado de Type, que é o atributo que identifica o tipo de evento a implementar (OnClick, OnMouseOver, OnMouseDown, OnMouseUp, OnChange, entre outros).
Neste package foi utilizado, mais uma vez, e pela mesmas razões apresentas e explicadas em 6.5.2.1, o padrão Factory para a criação dos diferentes tipos de ações. É uma tarefa bastante complexa antecipar todas as ações com necessidade de implementação e, por isso, existe uma classe abstrata (ActionCreator) que delega a responsabilidade de implementar o método de criação de ações com todos os atributos e propriedades necessárias às suas classes “filho” (Concrete Creator’s).
No diagrama apenas são representadas três ações, a RedirectAction , a RefreshAction e a ExecuteAction. A escolha das ações a representar foi feita depois de uma análise à plataforma Next>, onde foi possível concluir que estas são, de entre as muitas ações existentes, as mais utilizadas no contexto da plataforma.
A RedirectAction, permite que o utilizador introduza um fluxo de navegação nas suas aplicações com links entre páginas da aplicação ou, até mesmo, com links para a plataforma Next>. A RefreshAction permite a atualização de páginas ou de elementos mediante a ação
Vortal Development Software Kit
tomada pelo utilizador na interface. Por último temos a ExecuteAction, que permite a execução de um serviço da plataforma Next>, por exemplo, para permitir o envio de mensagens ou para a criação de tarefas.
Na Figura 40 é representado o package das Actions na sua totalidade com todos os aspetos acima referidos.
Figura 40 – Package de Actions
Na figura é representada uma classe [ActionName]Creator com o intuito de tornar a visualização e a compreensão do diagrama mais simples. Esta classe representa os restantes Concrete Factories utilizados para a criação de qualquer outra ação que surja durante o ciclo de vida do SDK.
Contrariamente ao que acontece com os ViewElements, todas as ações possuem a
implementação do método Write() para a geração dos ficheiros XML mais tarde utilizados na geração do código final (como explicado em 6.1).
DataSources
No contexto de qualquer aplicação, a possibilidade de visualização de informação é extremamente importante de forma a corresponder às necessidades dos utilizadores. Assim, é importante que determinados conjuntos de elementos suportem a ligação a fontes de dados (datasources) para a listagem e apresentação de informação.
O package de DataSources é constituído apenas pela entidade BaseDataSource, responsável pelo mapeamento de entidades presentes na plataforma Next> com as entidades disponibilizadas no contexto aplicacional do SDK. Esta classe é constituída por dois atributos
Vortal Development Software Kit
60
preenchidos através de dois enumerados existentes no package Common. O atributo Entity representa a entidade pretendida (p.e. UserTasks) e assume um dos valores presentes no enumerado Entities. O atributo Operation representa a operação a realizar sobre a entidade escolhida (Create, Update, GetAll, Get, Delete, etc.) e é preenchido através de um dos valores contidos no enumerado Operations da classe MappingEnums.
É através destes dois atributos que é conseguido o mapeamento dos Web Services da plataforma Next> com a aplicação desenvolvida. Vejamos, por exemplo, o seguinte caso onde a entidade BaseDataSource é instanciada da seguinte forma:
Figura 41 – Exemplo de instanciação de uma DataSource
Mais tarde, durante a geração do código a entidade previamente instanciada, será convertida numa chamada a um Web Service existente na plataforma Next> (como o exemplificado abaixo).
Figura 42 – Exemplo do código gerado através de uma DataSource
Na Figura 43 é apresentado o package de Datasources em conjunto com a classe que contém os atributos necessários para a realização do mapeamento entre a plataforma Vortal Next> e as entidades disponibilizadas no contexto do SDK.
Figura 43 – Package de Datasources
Páginas
Já foram apresentados os componentes base que garantem a construção de uma aplicação com diferentes comportamentos e diferentes tipos de ações. Falta apenas referir como é que
esses componentes são agrupados na aplicação de forma a ser criado um layout e um fluxo
Vortal Development Software Kit
O package de Windows é responsável por guardar todas as páginas da aplicação com os seus respetivos componentes e, para cada uma delas, definir a sua estrutura em termos de visualização (layout). Neste package existe uma classe “pai” denominada de Window, que possui duas especializações, a Page e a DashBoardView. A Page representa uma página típica da aplicação e é pelo facto de uma aplicação possuir várias instâncias desta, que é possível criar o fluxo de navegação desejado. Por outro lado, quando uma aplicação implementa a classe DashBoardView não existe qualquer fluxo de navegação, pois esta representa um widget que poderá ser utilizado na página principal da Next> para consulta de informação. Em [39] é explicado o dashboard Next> e introduzido o conceito de DashBoardView.
Por último, na Figura 44 é possível observar a classe Container que é a classe que permite a divisão de uma Window em diferentes seções (p.e secção central, secção de topo, etc.) e, para cada uma delas, guarda os elementos a serem disponibilizados.
Figura 44 – Package de Windows
Todas as classe representadas possuem a implementação dos métodos Write(),
WriteAttributes() e WriteChildren(), utilizados para a geração dos ficheiros XML mais tarde utilizados para a geração do código final (como explicado em 6.1).
Vortal Development Software Kit
62
Vortal Development SDK
Como apresentado nos capítulos anteriores, as aplicações desenvolvidas através do SDK têm acesso à informação guardada na plataforma Next> através dos serviços por esta disponibilizados. A plataforma apresenta um package de serviços internos, responsável por interpretar os pedidos do cliente e responder de forma adequada.
O número de entidades presentes na plataforma Vortal Next> é de grande dimensão, o que torna as chamadas aos serviços um processo bastante complexo. Devido a este facto, houve a necessidade de criar uma camada de abstração intermédia entre o SDK e o package de serviços que o torna de mais fácil utilização. Neste ponto da arquitetura foi aplicado o padrão estrutural Facade.
Este padrão garante a existência de uma interface simplificada para o acesso a um conjunto de funcionalidades/métodos de um sistema [37] (Figura 45).
Figura 45 – Diagrama geral do padrão Facade [37]
A utilização deste padrão tem as seguintes vantagens [38]:
Tornar um sistema (neste caso um package de serviços) mais fácil de utilizar e entender;
Reduzir as dependências do sistema, já que os clientes passam a utilizar a Facade para comunicar.
Na Figura 46 é possível observar que o SDK não tem qualquer acesso ao package de serviços, devido ao facto de a comunicação com o mesmo ser realizada através da classe VortalServiceFacade. De notar que, tanto o Facade como o package de serviços, apenas apresentam um pequeno conjunto das entidades e dos métodos a disponibilizar em cada uma delas, de forma a facilitar a visualização e a interpretação do diagrama.
Vortal Development Software Kit
Figura 46 – Facade para o acesso aos serviços da plataforma Next>
Motor do SDK
Quando uma aplicação se encontra totalmente desenvolvida ou num estado suficientemente avançado para ser feita a sua compilação e validação, é utilizado o package SDKEngine. Este package é completamente transparente para o utilizador e pode, inclusivamente, ser colocado num ambiente físico distinto do package de controlos para, por exemplo, atingir melhores níveis de performance e escalabilidade.
É neste ponto que é feita a geração e validação de código através da entidade Application (ver Figura 36) para uma linguagem/modelo intermédio (neste caso XML) que, mais tarde, será utilizada para gerar o código fonte final. Depois deste processo, é necessário encapsular o resultado num pacote de software para integrar no servidor aplicacional de Thrid Party Applications.
Na Figura 47 encontram-se representadas a classe Installer e a classe Tester que, apesar de serem muito semelhantes, têm um comportamento bastante distinto. A classe Installer é a classe que faz a geração e compilação de código final e que submete a aplicação para o servidor aplicacional onde esta irá ser executada e a classe Tester faz a geração e compilação de código para emular a utilização da aplicação no ambiente Next>. A grande diferença entre estas duas classes, para além de a primeira enviar a aplicação para o servidor aplicacional, reside no facto de a classe Installer fazer a optimização do código final gerado para melhorar aspetos como a performance da aplicação.
É ainda de salientar, mais uma vez, a presença do package Common com mais duas classes
no seu interior, a classe SDKException e a classe Logger. A primeira é responsável por gerir os erros que surgem durante o processo de geração e transformação de código e a segunda é a classe responsável por registar todo o fluxo de execução do Motor do SDK.
Vortal Development Software Kit
64
Figura 47 – Diagrama geral do Motor do SDK
Gerador de Código
A geração de código do SDK é feita em duas fases, na primeira fase é feita uma transformação M2M (entidade Application do package de controlos para ficheiro(s) XML) e na segunda é feita uma transformação M2T (XML em código fonte de uma determinada linguagem).
No primeiro processo de transformação, a entidade Application é percorrida e transformada num modelo XML através do seu método Write(). A escolha da transformação intermédia em XML teve em conta o facto de ser extremamente simples fazer a validação do mesmo através de XML Schema Definition (XSD). O XSD é uma linguagem baseada em XML que permite definir regras de validação de ficheiros e, por isso, apresenta-se como uma solução simples para a definição de uma Domain Specific Language (DSL). A validação do(s) ficheiro(s) XML gerado(s) será feita na classe ModelValidator.
DDepois de todos os modelos serem validados com sucesso, é possível converte-los em código fonte final (transformação PIM para PSM). Para isso, é necessário percorrer o(s) ficheiro(s) XML gerado(s) e implementar a lógica associada à linguagem fonte pretendida. Ao desenhar a arquitetura do SDK foi pensada a possibilidade de, no futuro, a linguagem pretendida para a geração ser diferente da atual (C#) e nos impactos que essa mudança pode trazer para o bom funcionamento do mesmo. Devido a esse facto, no package Code Generator existe a implementação do padrão comportamental Strategy.
O padrão Strategy (Figura 48) define uma família de algoritmos e encapsula cada um deles numa classe (ConcreteStrategy), ou seja, permite que uma classe (Strategy) tenha vários
Vortal Development Software Kit
comportamentos e se adapte a diferentes contextos. Este encapsulamento garante que os algoritmos possam ser escolhidos em tempo de execução e garante a escalabilidade da solução pela facilidade de acrescentar novos comportamentos sem afetar os já existentes [37] [38].
Figura 48 – Diagrama geral do padrão Strategy [37]
Na Figura 49, a classe Generator é uma interface com dois métodos (GenerateXML() e GenerateSourceCode()) que podem ter diferentes implementações dependendo da linguagem fonte pretendida (p.e. implementação Java é diferente da implementação C#). Para isso, existem as diferentes especializações da interface (C#Generator, JavaGenerator, etc.) onde as considerações necessárias para cada linguagem são tidas em conta de forma a atingir geração