Este capítulo tem como objetivo principal descrever a solução desenhada para o desenvol-vimento de um sistema inteligente capaz de prever o preço de um determinado automóvel. Primeiramente serão descritos todos os requisitos funcionais e não funcionais dos sistema, juntamente com os diagramas de casos de uso. Por fim, será descrita a arquitetura do sistema, todas as ferramentas utilizadas no seu desenvolvimento e os riscos.
5.1 Requisitos
Nesta secção, serão descritos todos os requisitos funcionais e não funcionais referentes a este projeto.
Um requisito é uma necessidade física, funcional ou não funcional documentada de um pro-jeto ou produto que deverá ser satisfeito. É usado formalmente em propro-jetos de engenharia, incluindo, por exemplo, engenharia de sistemas e engenharia de software. É um conceito amplo que descreve qualquer função, atributo, capacidade, característica ou qualidade ne-cessária de um sistema para que ele tenha valor e utilidade para um cliente, organização, utilizador interno ou outra parte interessada.[46]
Todos os requisitos descritos posteriormente terão a sua prioridade definida através do método MoSCoW que consiste num método de prioridade utilizado em desenvolvimento de software e é usado para ajudar as principais partes interessadas a entender a importância de cada um dos requisitos [47].
O método classifica os requisitos em quatro prioridades [47]:
• Must have: é obrigatório ser concluído pela equipa de desenvolvimento. A sua não implementação gera impacto no bom funcionamento do produto.
• Should have: são importantes para o produto, mas não são vitais. Se não for concluído, o produto ainda funciona. No entanto, se incluídos, eles agregam valor significativo.
• Could have: poderiam estar presentes no produto final, porém, não são necessárias para a função principal do mesmo. Agregam um baixo valor ao produto.
Capítulo 5
5.1.1 Requisitos Funcionais
Os requisitos funcionais descrevem explicitamente as funcionalidades e serviços que o sis-tema tem de cumprir e documenta como o sissis-tema deve reagir a entradas específicas, como se deve comportar em determinadas situações e o que não deve fazer.
O levantamento de requisitos resultou da análise de um documento de User stories forne-cido pelo dono do produto.
Em seguida serão enumerados todos os requisitos do sistema, sendo possível visualizar uma breve descrição e a prioridade de cada requisito. De modo a visualizar os requisitos em detalhe, é possível consultar o apêndice A.1 onde estão descritos todos os requisitos.
5.1.1.1 Autenticação
Na tabela 5.1 estão descritos os requisitos funcionais relativos ao sistema de autenticação da aplicação. Nela é possível visualizar que todos os requisitos são ”Must have” devido à importância de um sistema de autenticação para o controlo de acesso à aplicação.
Descrição Prioridade
Fazer Login Must Have
Fazer Logout Must Have
Recuperar Password Must Have
Alterar Password Must Have
Alterar Configurações Pessoais Must Have
Tabela 5.1: Requisitos-Autenticação.
5.1.1.2 Manipulação de Dados
Na tabela 5.2 estão descritos todos os requisitos funcionais relativos à manipulação de dados. Estes requisitos descrevem funções de carregamento, limpeza, tratamento, edição de dados e por fim, a opção de apagar parte dos dados armazenados.
Descrição Prioridade
Carregar Dados de Marcas, Preços e Peças de Automóveis Must Have
Carregar Histórico Sobre um Automóvel Específico Should have
Feedback Sobre o Processo de Carregamento de Dados Must Have
Limpar Dados Carregados Must Have
Normalizar dados Must Have
Tratar Dados Repetidos Must Have
Armazenar as Marcas, Preços e Peças Carregadas na Base de Dados Must Have
Armazenar o Histórico de Automóveis na Ledger Database Should have
Atualizar Marcas, Preços e Peças de Automóveis Must Have
Apagar Marcas, Preços e Peças de Automóveis Must Have
Tabela 5.2: Requisitos-Manipulação de dados.
Ao analisar a tabela 5.2 podemos verificar que todos os requisitos relacionados a histórico de automóveis são de prioridade ”Should have” devido a prioridade definida em 1.2.
Especificação do Problema
5.1.1.3 Aprendizagem Computacional
Na tabela 5.3 é possível encontrar todos os requisitos relacionados a aprendizagem compu-tacional, como por exemplo a análise dos dados e o treino dos algoritmos para a previsão de preço e fiabilidade de um automóvel.
Descrição Prioridade
Treinar Modelos de Aprendizagem Computacional Must Have
Selecionar as Características Mais Influentes no Preço Must Have
Prever Preço Atual de um Automóvel Must Have
Prever Preço de um Automóvel ao Longo do Tempo Must Have
Selecionar as Características Mais Influentes na Fiabilidade Will not have
Prever Fiabilidade de um Automóvel Will not have
Tabela 5.3: Requisitos-Aprendizagem computacional.
Devido à prioridade definida em 1.2, é possível visualizar na tabela 5.3 que os requisitos ”Will not have” são relacionados à fiabilidade de um automóvel, devido ao facto destas funcionalidades terem sido descartadas da primeira versão da plataforma.
5.1.1.4 Visualização de Dados
Na tabela 5.4 estão enumerados os requisitos funcionais relativos à visualização de dados armazenados e visualização da previsão de preço e fiabilidade de um automóvel.
Descrição Prioridade
Visualizar Marcas, Preços, Peças e Histórico de Automóveis Must Have
Visualizar Detalhes de Marcas, Preços e Peças de Automóveis Must Have
Visualizar Histórico de um Automóvel em Específico Will not have
Visualizar Dados Estatísticos Por Marca e Modelo Must Have
Visualizar Previsão de Preço Para uma Dada Configuração Automóvel Must Have
Visualizar Previsão de Preço Para um Determinado Automóvel Armaze-nado no Histórico Automóvel
Will not have
Visualizar Previsão de Preço ao Longo do Tempo Must Have
Visualizar Previsão de Fiabilidade Para uma Dada Configuração Will not have
Visualizar Previsão de Fiabilidade Para um Determinado Automóvel Ar-mazenado no Histórico Automóvel
Will not have
Tabela 5.4: Requisitos-Visualização de dados.
Como já referido anteriormente, todos os requisitos relacionados ao histórico de um auto-móvel tem prioridade ”Should have”. Já os requisitos relacionados com a fiabilidade são de prioridade ”Will not have”.
5.1.2 Requisitos não Funcionais
Os requisitos não funcionais especificam como um sistema se deve comportar e o que não pode ser uma restrição ao bom comportamento do mesmo. Também podem ser conside-rados atributos de qualidade de um sistema [48].
Capítulo 5
5.1.2.1 Usabilidade
A usabilidade é um requisito crucial num sistema interativo, ou seja, num sistema onde ocorre interação entre este e o ser humano. O sistema tem de ser desenhado para que seja fácil de usar por qualquer utilizador [48].
Posto isto, o utilizador do sistema deve ser capaz de fazer operações como iniciar sessão e navegar pela aplicação sem dificuldades. Deve também ser capaz de entender o funciona-mento da aplicação em menos de dois minutos.
Para cumprir tais objetivos, o Design do sistema é da responsabilidade do Designer da empresa, dada a sua experiência e capacidade para desenhar um sistema intuitivo e de fácil utilização.
Por fim, serão feitos testes de usabilidade para verificar a facilidade que o site possui de ser compreendido e manipulado pelo utilizador.
5.1.2.2 Desempenho
O desempenho consiste na rapidez e fluidez com que a aplicação web retorna as respostas ao utilizador durante a sua utilização [48].
De forma a manter um bom desempenho da aplicação, a mesma deve conseguir tempos de resposta inferiores a dois segundos em 90% dos pedidos feitos ao servidor.
De forma a medir esses valores, serão usadas ferramentas para medir o tempo de resposta ao navegar pelo sistema.
5.1.2.3 Segurança
Sendo um sistema que contém dados pessoais dos utilizadores, é de extrema importância manter esses mesmos dados em segurança bloqueando acessos não autorizados. É também necessário garantir que só utilizadores devidamente autenticados são autorizados a alterar os dados armazenados na base de dados [48].
Para garantir tal requisito, será utilizado um serviço da Amazon Web Services (AWS) denominado de Cognito, que permite armazenar os dados dos utilizadores em segurança, e permite também gerir a autenticação dos mesmos.
Será também utilizado o protocolo HTTPS na comunicação entre o cliente e servidor, de forma a proteger a comunicação entre eles.
De forma a verificar a segurança do sistema, será utilizado o OWASP Top Ten [49]. Consiste num documento de conscientização padrão para segurança de aplicações web. Representa um amplo consenso sobre os riscos de segurança mais críticos para as aplicações Web.
5.2 Diagramas de Casos de Uso
Nesta secção irão ser apresentados e explicados todos os diagramas de casos de uso do sistema assim como os seus respectivos atores. Os diagramas foram desenhado com base em todos os requisitos defendidos para o sistema, incluindo os requisitos Will not have.
Especificação do Problema
5.2.1 Atores
Em alto nível, a aplicação possui dois atores, entre eles o utilizador e o administrador.
Figura 5.1: Atores do sistema.
Na figura 5.1 estão representados os dois atores do sistema. Nela é possível verificar
que o administrador herda as funcionalidades do utilizador, isto é, têm permissão e a possibilidade de fazer as mesmas operações que o utilizador. Isto deve-se ao facto de somente o administrador necessitar de autenticação para ter acesso a determinadas páginas do sistema.
5.2.2 Utilizador
Na figura 5.2 está representado o diagrama de casos de uso referente ao utilizador.
Figura 5.2: Diagrama de casos de uso do utilizador: Alto nível.
O utilizador tem a possibilidade de visualizar as diferentes previsões de preços e fiabili-dade de um automóvel, e tem acesso ao histórico de automóveis através de pesquisas pelo Vehicle Identification Number (VIN) do automóvel que pretende visualizar. Tem ainda a possibilidade de visualizar diversos dados estatísticos por marca e modelo.
Para uma visualização mais detalhada de cada funcionalidade presente na figura 5.2, é possível consultar a figura B.1 presente no apêndice B.
Capítulo 5
5.2.3 Administrador
Na figura 5.3 está representado o diagrama de casos de uso de alto nível do administrador do sistema. Inversamente ao utilizador, o administrador necessita de autenticação para aceder à plataforma.
Figura 5.3: Diagrama de casos de uso do Administrador: Alto nível.
De modo a controlar o acesso ao sistema, o administrador necessita de um sistema de autenticação de modo a fazer Login na aplicação web e recuperar a password. Após o login executado com sucesso, o administrador pode ainda alterar os seus dados pessoais, password e terminar sessão.
Por fim, o administrador tem como principal funcionalidade a gestão dos dados do sistema. De modo a facilitar a compreensão dessa funcionalidade, é possível consultar a figura B.2 no apêndice B para visualizar um diagrama mais detalhado relativo à funcionalidade de gestão de dados.
Na figura B.2 estão representadas as quatro funcionalidades disponíveis para o administra-dor relativas à gestão de dados do sistema, sendo elas o carregamento, edição, eliminação e visualização de dados. Todas as funcionalidades estão disponíveis para dados relativos a preços, histórico de assistências, marcas e peças de automóveis, à exceção da função de apagar e editar, que não são possíveis para o histórico de assistências.
5.3 Arquitetura do Sistema
Esta secção tem como principal objetivo a descrição da arquitetura do sistema e também a descrição da função de cada um dos seus componentes.
De modo a facilitar a visualização da arquitetura do sistema, foi utilizado o modelo C4 [50]. Este modelo baseia-se em 4 níveis de granularidade, sendo o nível 1 o diagrama de
Especificação do Problema contexto, seguido do diagrama de containers, passando pelo diagrama de componentes e, por fim, no último nível é feito zoom em cada componente presente no nível 3 e é mostrado a sua implementação em código. Este último nível pode ser mostrado através da utilização de diagramas de classes UML, diagramas de relacionamento de entidades, ou similar.
Figura 5.4: Diagrama de contexto.
Na figura 5.4 está representado o diagrama de contexto do sistema. Nela é possível observar dois tipos de pessoas que podem aceder ao sistema (Curtur).
A primeira pessoa com acesso ao sistema é o utilizador, que não necessita de autenticação e pode aceder a duas páginas da plataforma web. A primeira página a que o utilizador tem acesso é a página de estatística, onde é possível a visualização de vários dados estatísticos, como os automóveis que mais desvalorizam/valorizam ao longo do tempo e também o preço e quilometragem média ao longo da idade de um automóvel de uma dada marca e modelo. O utilizador tem também acesso a uma página responsável por mostrar o preço atual e ao longo do tempo de um automóvel dado por ele.
O administrador tem acesso a um número de páginas relativamente maior quando com-parado com o utilizador. De modo geral, o administrador tem acesso a todas as páginas responsáveis pela gestão dos dados do sistema, como o carregamento de novos dados, edi-ção, e exclusão dos mesmos. Tem também acesso às páginas responsáveis pela edição dos seus dados pessoais e password. No caso do administrador não conseguir prosseguir com a autenticação devido ao esquecimento da password, a mesma pode ser recuperada por ele através do acesso a uma página específica.
Na figura 5.5 está representado o diagrama de containers do sistema. Como já referido anteriormente, a aplicação tem como objetivo suportar dois tipos de utilizador, sendo o primeiro um utilizador comum que não necessita de autenticação e um administrador, que necessita da devida autenticação para aceder a determinadas páginas da aplicação. Através de pedidos HTTPS os utilizadores podem aceder à aplicação web, que por sua vez
Capítulo 5
Figura 5.5: Diagrama de containers.
comunica com a API por pedidos HTTP. Dependendo do pedido que o utilizador faz, a API é responsável por inicializar containers capazes de resolver o mesmo.
Os containers serão responsáveis por todo o poder de processamento do sistema, desde tarefas rápidas de pesquisa nos diversos locais de armazenamento, mas também tarefas mais complexas como o tratamento e armazenamento dos dados carregados no Data Lake nos seus formatos originais.
O primeiro local de armazenamento de dados é uma NoSQL Database, onde podem ser armazenadas todas as informações relativas a marcas e modelos de carros, informações relativas aos preços de automóveis, peças, dados estatísticos, metadata, entre outros. No caso do administrador necessitar de importar novos dados, os mesmos são carregados através da aplicação web e enviados diretamente para um Data Lake, onde podem ser ar-mazenados no seu formato original, como por exemplo em formato csv. A utilização do Data Lake permite também o armazenamento dos modelos de aprendizagem computaci-onal já treinados, de modo a poderem ser carregados quando um utilizador necessitar da
Especificação do Problema avaliação de um automóvel.
Para armazenar os dados históricos de cada automóvel registado na aplicação é necessário uma Ledger Database. A utilização desta base de dados tem como objetivo o armazena-mento de todas as alterações feitas a um determinado automóvel e garantir que as mesmas não podem ser modificadas ou apagadas.
Por fim, para o armazenamento seguro de todos os dados relativos aos utilizadores da aplicação é necessário a utilização de uma User Pool.
Figura 5.6: Diagrama de componentes.
Na figura 5.6 está representado o diagrama de componentes da API do sistema. Nela é possível visualizar com mais detalhe as funcionalidades do sistema.
Os dois componentes localizados na parte inferior da figura 5.6 delineados com a cor verde são relativos às funcionalidades do utilizador comum. O componente de estatística é res-ponsável por fazer pesquisas na base de dados e retornar diversas informações relativas a um determinado modelo automóvel do interesse do utilizador. O componente de previsão tem como principal função retornar ao utilizador a avaliação de um determinado automóvel fornecido por ele. Para a elaboração desta função, o componente necessita aceder ao Data
Capítulo 5
Lake para obter o modelo treinado responsável pela avaliação. Necessita também do acesso à base de dados para obter diversos dados estatísticos utilizados na previsão do preço do automóvel.
O primeiro componente desenvolvido para o administrador é o de autenticação, dado a sua obrigatoriedade para aceder a praticamente todas as páginas. No caso da autenticação falhar por falta da password, a existência de um componente responsável pelo processo de reset da password possibilita ao administrador a recuperação da sua conta. Ambos estes componentes estão diretamente conectados com o User Pool.
Seguidamente, o componente de definições de conta possibilitam ao administrador edi-tar os seus dados pessoais, como o nome, sobrenome e password. Este componente está diretamente ligado ao User Pool de modo a poder atualizar os dados alterados.
O componente com maior complexidade de todo o sistema é o de carregamento de dados. Quando o administrador necessita de carregar novos dados, este componente começa por proceder ao envio dos mesmos para um Data Lake no seu formato original. Terminada esta fase, o componente tem a responsabilidade de ler o ficheiro carregado anteriormente e armazenar o seu conteúdo na base de dados no caso de ser um ficheiro com preços, peças ou marcas automóveis, ou na Leader Database no caso de ser um ficheiro com dados históricos de um automóvel. Posto isto, o componente faz a atualização dos dados estatísticos no caso do ficheiro carregado conter dados de preços automóveis. Ao longo deste processo, é também da responsabilidade do componente manter a tabela de metadata atualizada com o estado atual de carreamento de cada ficheiro carregado.
Após o carregamento de dados, é importante fornecer ao administrador uma forma de visualização dos mesmos. Essa função é da responsabilidade do componente de visualização de dados, que têm acesso à base de dados e à Ledger Database de modo a poder realizar pesquisas e fornecer os dados armazenados ao administrador.
Por fim, com os componentes de edição e de exclusão de dados, o administrador é capaz de fazer a gestão dos mesmos. Este componente, diferente do que acontece no componente de visualização, tem acesso somente à base de dados, pelo facto de que os dados armazenados na Ledger Database serem imutáveis.
5.4 Tecnologias e Ferramentas
Nesta secção, irão ser enumeradas todas as tecnologias e ferramentas que serão utilizadas no desenvolvimento deste projeto. Inicialmente, serão descritas todas as tecnologias e ferramentas utilizadas no desenvolvimento do back end, passando a descrever as tecnologias utilizadas no desenvolvimento do front end, e por fim, a descrição das tecnologias utilizadas no desenvolvimento dos modelos de aprendizagem computacional.
5.4.1 Back end
Esta subsecção tem como objetivo descrever todas as tecnologias e ferramentas utilizadas para o desenvolvimento do back end. Será também descrita a relação entre as diferentes tecnologias.
Na figura 5.7 estão representados os dois tipos de utilizador, bem como todas as tecnologias utilizadas no desenvolvimento do servidor. A seguinte enumeração descreve os artefatos visíveis no diagrama:
Especificação do Problema
Figura 5.7: Ligação entre as diferentes tecnologias AWS.
1. O Administrador tem como principal função o carregamento de novos dados e a sua manutenção. Posto isto, é fundamental que somente pessoas autorizadas possam ter acesso às páginas responsáveis por tais tarefas. De modo a controlar o acesso dos administradores é utilizado o Cognito.
2. Os Utilizadores podem estar espalhados por todo o globo. De modo a diminuir a latência na utilização da plataforma, o utilizador tem acesso ao conteúdo estático pelo CloudFront. Já o conteúdo dinâmico é acedido pela API Gateway.
3. O Cognito [51] permite o armazenamento seguro dos dados dos utilizadores, e tam-bém o controlo de acesso dos administradores à aplicação.
4. O CloudFront [52] é um serviço que entrega conteúdo a clientes em todo o mundo com segurança, baixa latência e altas velocidades de transferência. Posto isso, será responsável para distribuição de todo o conteúdo estático que o utilizador necessita para uma correta utilização da aplicação web.
5. O Amazon S3 [53] é um Data Lake capaz de armazenar diversos tipos de dados. Será responsável por hospedar os ativos estáticos da aplicação web, todos os ficheiros carregados pelos administradores e também responsável pelo armazenamento dos modelos de aprendizagem computacional já treinados.
6. Contrariamente ao conteúdo estático fornecido pelo Amazon S3 que é descarregado pelo cliente, em muitos cenários, o conteúdo dinâmico precisa ser enviado/recebido pela aplicação. Nesse sentido, a Amazon API Gateway [54] serve como ponto de extremidade seguro para essas chamadas, de forma a retornar respostas que serão mostradas na aplicação web.
Capítulo 5
7. As Lambda Functions [55] permitem a execução de pequenas funções, como por exemplo a criação, leitura, atualização e exclusão (CRUD) dos dados existentes nos diferentes locais de armazenamento. São utilizadas essencialmente para a execução de tarefas com tempos de respostas pequenos.
8. A Amazon DynamoDB [56] é uma base de dados NoSQL e possibilita o