DOCUMENTO DE ARQUITETURA DE SOFTWARE

O documento de arquitetura de software fornece uma visão geral de arquitetura abrangente do sistema de software. Serve como um meio de comunicação entre o arquiteto de software e outros membros de equipe de projeto, com relação a decisões arquiteturalmente significativas tomadas sobre o projeto.

O presente documento tem como objetivo descrever a arquitetura do projeto Cabeleleila Leila, uma aplicação web com o objetivo de facilitar e otimizar o sistema de agendamentos em um salão de beleza. Este documento oferece uma visão arquitetural geral do sistema, usando diversas visões, como visão de caso de uso, visão lógica, dentre outras, para representar diferentes aspectos do mesmo. O objetivo deste documento é capturar e comunicar as decisões arquiteturais significativas que foram tomadas no decorrer do processo de desenvolvimento.

Este documento apresenta uma visão arquitetural compreensiva e holística a respeito do sistema do salão da Leila. Diferentes visões arquiteturais estão presentes aqui para representar determinados aspectos do sistema. Assim, é esperado capturar e expressar as decisões de arquitetura significativas que foram tomadas para consolidar a construção do sistema para o salão da Leila.

Esse documento está estruturado da seguinte maneira: primeiro, uma introdução geral sobre o projeto de arquitetura e sobre o sistema em questão; em seguida, a representação arquitetural é explicada, bem como quais visões esse documento aborda; as metas e restrições de arquitetura, na sequência, abordam requisitos de software e outros objetivos importantes para a arquitetura, estratégias etc. Logo, uma série de tópicos representando cada visão utilizada nesse projeto; depois, uma descrição do tamanho e do desempenho desse software; por fim, características de qualidade que se aplicam ao projeto são discutidas.

O Salão da Cabeleleila Leila é uma aplicação que visa facilitar o gerenciamento de um salão de beleza por meio do cadastro de clientes e do agendamento dos serviços oferecidos pelo estabelecimento.

A aplicação permite que o cliente consulte os tipos de serviços prestados, seus respectivos preços, os horários de atendimento e agende um pedido. Mais ainda, o cliente pode acessar o perfil dos profissionais que atuam no local, avaliar pedidos etc.

Esse documento de arquitetura descreve como a aplicação funciona, quais são os requisitos para o funcionamento correto, quais são as restrições do sistema, caso existam, as tecnologias utilizadas, como o projeto está estruturado e organizado etc. Assim, esse é um dos principais documentos para o projeto do sistema do salão da Leila como um todo, sendo que ele afeta todos os interessados, desde o cliente do Salão aos desenvolvedores deste software.

A arquitetura de um software, segundo as normas da IEEE, é a “organização fundamental de um sistema, expressa em seus componentes, nos relacionamentos entre eles e com o ambiente, e nos princípios que governam seu projeto e sua evolução”. O aplicação web Cabeleleila Leila será representada seguindo as seguintes visões arquiteturais:

O padrão arquitetural utilizado no projeto é um padrão que pode ser entendido como um padrão MVC (Model-View Controller). Este padrão tem como benefício o isolamento das regras de negócios da lógica de apresentação, ou seja, a interface do usuário, uma vez que essa comunicação entre interface e usuário é definida através de um controlador (controller) que separa as camadas.

O modelo (model) tem a responsabilidade de gerenciar e controlar a forma como os dados se comportam por meio das funções, lógica e regras de negócios estabelecidas. É o detentor dos dados recebidos pela controller e aquele que envia as respostas mais adequadas; tanto a controller quanto a model são representadas com a utilização do framework Spring Boot utilizado no backend. A visão (view) também é responsável por apresentar as informações de forma visual ao usuário, representada neste projeto com a utilização do framework Angular.

Mais ainda, em relação ao backend, a parte de código que lida com mais proximidade e faz chamadas ao banco de dados representa uma view, pois faz a interface entre a requisição e os dados que ela busca. A informação é então retornada para a model, em seguida para a controller, então de volta ao frontend, o qual monta os dados recebidos e os exibe ao usuário (outra view, representando uma interface com o usuário).

O diagrama relacional representa a divisão da aplicação em microsserviços independentes referentes aos usuários, aos serviços oferecidos pelo salão e os agendamentos realizados.

O usuário da aplicação realiza o login e recebe um token de acesso que permanece por um período limitado de tempo. Este token é passado para o banco de dados no momento em que se pretende cadastrar ou agendar um serviço na aplicação para que haja permissão para execução da ação.

O Spring é um framework open source para a plataforma Java, um framework não intrusivo, baseado nos padrões de projeto inversão de controle e injeção de dependência. O Spring Boot facilita a criação de aplicativos autônomos baseados em Spring de nível de produção.

Angular é uma plataforma de desenvolvimento, construída em TypeScript. O Angular inclui uma estrutura baseada em componentes para a construção de aplicativos da web escalonáveis, uma coleção de bibliotecas bem integradas que cobrem uma ampla variedade de recursos, incluindo roteamento, gerenciamento de formulários e comunicação cliente-servidor.

Os objetivos arquiteturais dizem respeito às metas mais significativas impostas a um projeto, ou seja, é tudo aquilo que satisfaz as necessidades, expectativas e desejos dos Stakeholders. As restrições arquiteturais de um projeto referem-se aos fatores que limitam a execução da aplicação. Em outras palavras, as restrições podem ser definidas como condições impostas ao sistema, para que este funcione de acordo com o esperado pelos Stakeholders.

Definir as restrições de um projeto é importante porque assegura a viabilidade do empreendimento e a satisfação dos Stakeholders. Quando um projeto é restringido por fronteiras claras, através de regras bem formuladas, há uma delimitação no campo de atuação do gerente de projetos. Este tópico tem por finalidade descrever os objetivos e restrições cabíveis ao projeto Leila's.

• Escalabilidade: O software deve tornar possível sua evolução e manutenção.
• Segurança: A aplicação deve manter os dados dos usuários em total segurança através da utilização de ferramentas para a encriptação de dados.
• Linguagem: A aplicação deve conter uma linguagem comum e de fácil entendimento para os usuários.
• Portabilidade: A aplicação deve ser executada com desempenho igual ou similar nos navegadores Google Chrome e Mozila Firefox.
• Usabilidade: A aplicação deve ser construída seguindo regras de usabilidade para atender a maioria dos usuários.
• Manutenibilidade: A aplicação deve permitir manutenção e melhorias de maneira a não gerar custo e tempo muito acima do normal. Para isso ser possível, o sistema foi escrito com base em padrões de projetos já conhecidos por grande parte dos desenvolvedores Java.

• Tecnologias: A aplicação deverá ser desenvolvida utilizando as seguintes ferramentas e tecnologias:
• Spring Boot: Framework escrito em Java para o desenvolvimento do back-end da aplicação;
• Angular: Framework escrito em TypeScript para o desenvolvimento do front-end da aplicação Web. Possui fácil integração com o bootstrap e permite a utilização do HTML;
• Typescript: Super conjunto do JavaScript, utilizado juntamente ao framework Angular na construção do front- end;
• Bootstrap: Framework de CSS que torna fácil a criação de elementos em websites. Agiliza a criação de páginas esteticamente agradáveis, pois seus padrões de design seguem os princípios de usabilidade para interfaces;
• PostgreSQL: Banco de dados relacional que armazena os dados em tabelas. Utiliza a linguagem SQL para a manipulação dos dados;
• Github: Controle de versionamento da aplicação.
• Conectividade: A aplicação necessitará de conexão com a internet para funcionar.
• Prazo: A aplicação deverá ser finalizada na data estipulada para entrega final.
• Idioma: A aplicação deve ser voltada para a linguagem Português-Brasil.
• Público alvo: A aplicação deve atender usuários que desejam agendar serviços no salão Leila's.

O Caso de Uso tem como objetivo descrever como será o uso de uma funcionalidade de um sistema. Com base nisso, a visão de Caso de Uso exerce a função de listar casos de uso que representam alguma funcionalidade central e significativa no sistema final, ou seja, descreve cenários ou casos de uso consideráveis para o sistema.

A visão de caso de uso é um aspecto arquitetônico que ilustra os casos e cenários de uso que abrangem comportamento e/ou classes significativas do ponto de vista arquitetônico. Essa visão mostra um subconjunto arquitetonicamente significativo dos casos de uso e atores, que no projeto Leila's são: cliente, funcionário e administrador.

Os casos de uso levantados para o projeto estão listados abaixo. Aqueles que possuem um impacto mais significativo na arquitetura do projeto estão destacados em negrito, e serão descritos em detalhes posteriormente.

• UCD01 - Cadastrar usuários;
• UCD02 - Realizar login;
• UCD03 - Agendar horário;
• UCD04 - Recuperar senha;
• UCD05 - Gerenciar estabelecimento;
• UCD06 - Gerenciar perfil de usuário.

• UCD03 - Agendar horário: este caso de uso ocorre quando o usuário cliente solicita um serviço disponível no salão. Após selecionar o serviço desejado, será apresentado ao cliente uma lista de horários disponíveis, e basta que o cliente selecione o horário pretendido e confirme a solicitação do serviço. Este caso de uso é exclusivo para o perfil de cliente.
• UCD05 - Gerenciar estabelecimento: Caso de uso exclusivo para o perfil de administrador e ocorre quando o administrador deseja consultar serviços cadastrados no sistema, visualizar os agendamentos do salão, criar um usuário, modificar o tipo de permissão de um usuário cadastrado ou excluir um usuário cadastrado. Após fazer o que pretende no sistema, basta que o administrador confirme as alterações para que o sistema seja atualizado.

As visões de arquitetura podem ser consideradas abstrações ou simplificações dos modelos criados, em que se ressaltam as características importantes sem evidenciar os detalhes. A Visão Lógica é utilizada no fluxo de trabalho Análise e Design para fornecer uma base de compreensão da estrutura e da organização de design do sistema.

O diagrama de contexto é um gráfico, composto por um fluxo de dados que mostra as interfaces entre o projeto e a sua relação com o ambiente em que vai ser desenvolvido. O diagrama de contexto funciona como uma descrição dos processos sob a visão de mais alto nível.

O usuário faz suas interações com as interfaces criadas através do Framework Angular, cujos padrões de chamada são feitas via endpoint utilizando a tecnologia REST para web services. Essa integração de comunicação é feita do frontend para o backend, aqui desenvolvido utilizando o Framework Spring Boot.

Por fim, as informações são validadas e carregadas através da técnica ORM (Object-relational mapping) com o Hibernate, que relaciona propriedades de uma classe com colunas do banco de dados, e então são retornadas ao usuário de acordo com a necessidade do que foi solicitado.

Os arquivos existentes no diretório web/resources são aqueles que recebem as requisições advindas do frontend. Essas requisições são enviadas aos arquivos existentes no pacote de services, os quais utilizam métodos existentes nas interfaces do pacote repositories. Neste projeto, as interfaces utilizadas em repositories são "filhas" de uma interface pai denominada CrudRepository, sendo que essas são responsáveis em realizar a comunicação entre a aplicação e o banco de dados.

O objetivo da visão de processos é mostrar a organização do processo do sistema, descrevendo como o sistema de tempo-de-execução é estruturado na forma de um conjunto de elementos que têm interações e comportamento de tempo-de-execução. Esta visão deve mostrar como se dá a comunicação entre os processos do sistema.

A visão dos processos empregados no projeto, que ilustram os principais fluxos de comunicações do sistema, podem ser encontradas no diagrama de comunicação, que será apresentado a seguir, e no diagramas de sequências.

O diagrama acima representa como acontece a comunicação entre o usuário e a aplicação, genericamente.

A camada do cliente, a qual pode ser entendida como o frontend da Leila's, faz diversas requisições para suprir as necessidades do usuário por meio de uma interface com o backend. Cada requisição é recebida pela :GenericResource, a qual consegue entender e mapear a informação desejada. Assim, algum serviço (:GenericService) será acionado para responder aquela necessidade, sendo que, para efetivamente recuperar os dados requisitados, chama-se um :GenericRepository. Este interage de modo mais próximo ao banco de dados, recupera as informações e as envia de volta para o serviço que o chamou, e assim sucessivamente, até que a informação seja apresentada de volta ao usuário.

• createUsuario (): Esse processo é responsável pela criação de usuários do tipo cliente e funcionário, lembrando que o tipo administrador é criado diretamente no sistema;
• getServicos (): Busca os serviços cadastrados no sistema dependendo do objetivo da busca;
• gerenciarServicos (): Esse método edita os serviços nas características em que ele foi cadastrado ou mesmo exclusão/inclusão de serviços;

Esta seção descreve como o sistema é mapeado para o hardware. Os dados da aplicação Web ficam armazenados no banco de dados PostgreSQL de tal maneira que quando requisitado pelo Back-end, construído em Java, realiza os serviços enviados através da interface, no caso o Front-end, desenvolvido em Angular, que por sua vez, mostra todas as informações necessárias ao usuário.

A finalidade da visão de implementação é captar as decisões de arquitetura tomadas para a implementação. Esta seção descreve a estrutura geral do modelo de implementação, a decomposição do software em camadas e subsistemas no modelo de implementação, e quaisquer componentes arquitetonicamente significativos.

O projeto é dividido em duas camadas: Front-end e Back-end:.

• app: pode-se dizer que é o pacote principal, embora não atue sozinho. Toda a lógica da aplicação, projeto de páginas, rotas, componentes utilizados, arquivos auxiliares, funcionalidades etc estão presentes aqui;
• assets: aqui ficam os "ativos" utilizados nas interfaces com o usuário, os quais incluem diversas imagens, logos etc.;
• environments: representa um conjunto de configurações de ambiente para a aplicação, podendo incluir: variáveis; números de portas de serviços; URLs utilizadas etc.;
• shared: aqui encontra-se arquivos, variáveis, interfaces, constantes etc, compartilhadas para a aplicação como um todo.

• Config: nela está contida as configurações iniciais do MVC e da classe SpringFoxConfig;
• Domain: contém as entidades necessárias para o gerenciamento de usuários, tanto cliente quanto funcionário, sendo que o administrador já será setado automaticamente, e os serviços a serem oferecidos pelo estabelecimento;
• Exceptions: É a responsável pelo lançamento de exceções decorrentes de erros;
• Repositories: existe no contexto de executar requisições de método CRUD;
• Security: toda regra de serviço envolvendo questões de segurança estão implementadas nele;
• Service: no pacote service está contida a lógica que implementa a interface para o CRUD;
• Web: responsável basicamente pelo controle de validação de entidades. Um exemplo é a classe UserController, que impede a duplicidade de nomes de usuários.

Para a visão de dados, representamos aqui como o sistema da Leila's persiste nessas informações. O modelo de entidade-relacionamento (ME-R), bem como o diagrama entidade-relacionamento (DE-R), somado ao diagrama lógico de dados (DLD) foram utilizados. Por questões relacionadas ao tamanho deste documento, apresentamos abaixo somente o DE-R e o DLD.

O tamanho da aplicação, levando em consideração apenas o Back-end, foi estimado em 42.9Mb. Esse valor foi alcançado utilizando o comando “MVN install”, gerando um arquivo .jar, o que torna possível a execução do Back-end em qualquer sistema operacional que contenha Java.

Em relação à performance, o sistema foi desenvolvido com foco na otimização de resposta às requisições. Sendo assim, é esperado que o desempenho geral do sistema atenda às expectativas e à testes de Stress.

A qualidade da aplicação pode ser mensurada a partir da abordagem NFR. O NFR Framework é uma abordagem para representar e analisar Requisitos Não-Funcionais. Seu objetivo é ajudar desenvolvedores na implementação de soluções personalizadas, levando em consideração as características do domínio e do sistema em questão. Tais características incluem Requisitos Não-funcionais, Requisitos funcionais, prioridades e carga de trabalho. Esses fatores determinam a escolha de alternativas de desenvolvimento para um determinado sistema (CHUNG et al., 2000).

• Usabilidade: A interface do sistema é simples, clara e de fácil interação, seguindo uma padronização de cores e fontes, definidas no documento de identidade visual.
• Segurança: Quando o usuário acessa o sistema através de Login, um token temporário é criado, para realizar a autenticação do usuário e resgatar dados privativos do banco de dados.
• Manutenabilidade: Todo o projeto Leila´s foi documentado no repositório do grupo. Isso facilita a consulta da documentação, e apoia a manutenibilidade do código.
• Confiabilidade: o sistema foi desenvolvido para garantir que o mesmo se recupere em caso de falhas.
• Portabilidade: A utilização do Docker garante um ambiente estável, o que auxilia na criação de possíveis novos módulos.

O projeto ainda está em fase de desenvolvimento até o presente momento (maio de 2021), portanto algumas métricas não puderam ser obtidas.