Domínio

O domínio de uma aplicação consiste na definição de todos os conceitos e entidades relaci-onados com o problema que está a ser resolvido. Para que as novas alterações se possam refletir na solução a desenvolver, é importante remodelar o diagrama de domínio. Utilizando novamente a linguagem UML, é possível desenvolver um diagrama de componentes que represente o domínio do novo editor de formulários.

O diagrama de domínio proposto na figura 5.1 é bastante similar ao diagrama apresentado na figura 2.3 da Secção 2.4 com algumas exceções. A entidade Formulário/LandingPage foi separada em duas entidades independentes, com opções próprias. Ambas as novas entidades, Formulario e LandingPage estão ligadas à entidade Utilizador, uma vez que este pode criar vários formulários ou váriaslanding pages. As entidades estão também interligadas entre si, visto que umalanding page continua a poder conter um formulário. A funcionalidade não é eliminada mas deixa de ser obrigatório que uma página tenha um formulário. Outra alteração que se pode constatar é o desaparecimento da entidade Publicacao. Como referido no na Secção 2.4, esta funcionalidade deixa de ter sentido uma vez que existem tipos quer de formulários quer delanding pages. Por exemplo, ao criar um formulário do tipoembedded deixa de ser necessária uma publicação, o tipo de publicação é definido quando é feita a escolha do tipo de formulário.

As alterações efetuadas resolvem o problema identificado na Secção 1.3 relativo ao acopla-mento da funcionalidade de formulários e da funcionalidade de landing pages. Com estas alterações ao modelo de domínio, é possível iniciar o desenvolvimento do novo sistema cor-rigindo e melhorando os aspetos menos positivos detetados no editor EasyForms.

Figura 5.1: Diagrama de Domínio do Novo Editor de Formulários

5.2. Arquitetura 63

5.2 Arquitetura

Da mesma forma que é indispensável fazer uma planta para construir um edifício, é indis-pensável fazer arquitetura de um software para o desenvolver. Através desta analogia, é possível perceber que a arquitetura em engenharia desoftware tem como objetivo desenhar a estrutura do software sem qualquer tipo de preocupação relativa a limitações de imple-mentação ou tecnologias, focando apenas no comportamento dos diversos componentes.

Para desenvolver este artefacto, foi usada, novamente, a linguagem UML, desta vez com um diagrama de componentes.

Figura 5.2: Diagrama de Componentes do Novo Editor de Formulários

A arquitetura proposta na figura 2.4 traz algumas alterações que resolvem os problemas identificados na Secção 1.3 relativos à manutenção e escalabilidade do sistema. Através da arquitetura proposta, é possível perceber que o componente EasyForms deixa de existir, sendo retirado do componente BackOffice e dividido entre dois componentes: o novo com-ponente Forms-Builder e o comcom-ponente Services. Na arquitetura, toda a lógica de interface e visualização do editor de formulários passa a estar presente no componente Forms-Builder, desenvolvido em Angular (apresentado na Secção 3.2.2. Este componente contém a imple-mentação do editor e dauser interface que permite desenvolver formulários. Toda a lógica de negócio associada ao novo editor de formulários passa a estar contida no componente Services, tendo sido acrescentados todos os métodos necessários para as diferentes funções do editor de formulários.

A remoção da funcionalidade de formulários do componente BackOffice corrobora o esforço da empresa para a divisão do monólito em funcionalidades independentes, como é descrito na Secção 2.4. A arquitetura garante escalabilidade, aumentando as instâncias dos com-ponentes Forms-Builder e Services consoante as necessidades e a utilização do editor. A manutenção do sistema fica também facilitada uma vez que o editor está repartido por diversos componentes, sendo mais fácil acrescentar funcionalidades assim como manter as funcionalidades existentes, quer a nível de interface quer a nível de servidor. Estas alterações colmatam o problema identificado na Secção 1.3 relativos a escalabilidade e manutenção.

Todos os componentes não mencionados nesta secção mantém-se inalterados relativamente ao diagrama de componentes apresentado na figura 5.2 da Secção 2.4.

5.3 Implantação

A implantação de um projeto de software consiste na instalação do mesmo nas máquinas de modo a disponibilizar o sistema aos utilizadores. Esta é um passo bastante importante para as organizações, uma vez que as máquinas utilizadas para a instalação do software consistem em custos para as empresas e organizações. Para apresentar o artefacto que define a implantação do sistema, foi usada, novamente, a linguagem UML, desta vez com um diagrama de implantação.

Figura 5.3: Diagrama de Implantação do Novo Editor de Formulários

A gestão das máquinas a serem utilizadas e o número de instâncias dos diferentes componen-tes em cada máquina é um ponto bastante importante para garantir que não são utilizados recursos desnecessários. A nova implantação resolve os problemas identificados removendo a funcionalidade do editor (EasyForms) do componente BackOffice, criando o componente Forms-Builder que estende o componente Builder e é independente de qualquer outro com-ponente. Desta forma, é possível ter uma máquina dedicada ao componente Forms-Builder, sendo possível escalar o número de instâncias consoante a necessidade.

5.4 Serviços

Para que as alterações que um utilizador produz na interface de um sistema sejam persistidas, é necessário efetuar uma ligação entre a interface e o servidor que contém toda a lógica de negócio e a persistência de dados. Como apresentado na Secção 5.1, o componente Services contém serviços que comunicam com a base de dados do produto E-goi e disponibiliza endpointsestabelecer conexão com os serviços. A funcionalidade do editor de formulários já existe e, consequentemente, os serviços necessários para a funcionalidade também já estão implementados, no entanto, para que o novo editor funcionasse, foi necessário fazer algumas alterações aos serviços existentes.