Skip to content

Projeto Detalhado (Mobile)

Gustavo Matozinho Lima edited this page Mar 28, 2017 · 11 revisions

Definição da arquitetura de software

Diagramas para exemplificar a solução

Diagrama de Projeto de Domínio

Diagrama de projeto

À nível de projeto, surgem mais algumas classes no nosso sistema:

  • Usuário: é uma classe abstrata que define que um objeto possui a capacidade de fazer login no sistema;
  • Imagem: tomamos a decisão de projeto de separar a imagem de cada usuário em uma tabela separada, por motivos de clareza e facilidade de uso.

Apesar da exclusividade de acesso de cada sistema (participantes só acessam mobile, NAC's só acessam web), o diagrama de projeto não se altera:

  • No sistema web, os NAC's buscam informações sobre os participantes, logo estes estão presentes;
  • No sistema mobile, os participantes se associam à campus. Na implementação, como temos uma relação de 1:1 entre NAC e Campus, estas duas entidades são reunidas numa única tabela. Logo, as informações do NAC acabam sendo levadas conjuntamente para o sistema mobile.

Diagrama de Projeto de Visão

Diagrama 1 - Participante com Perfil cadastrado

aluno_c/perfil

Diagrama 2 - Participante sem Perfil cadastrado

aluno_s/perfil

Diagrama 3 - NAC cadastrado

nac_cadastrado

Diagrama 4 - Combinações de Alunos

match

Diagrama 5 - Relação de NACs

relação_nacs

Descrição das tecnologias utilizadas

  • Visual Studio 2015 - é um ambiente de desenvolvimento Microsoft, que trabalha muito bem em .NET e oferece suporte a diversos frameworks.
  • Xamarin - é um conjunto de ferramentas integrado ao Visual Studio, utilizado para desenvolvimento de aplicações mobile em C#.
  • C# - é uma linguagem de programação desenvolvida para criar aplicações que rodam na plataforma .NET. C# é simples, type-safe e orientada a objetos.
  • Git - é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos.
  • AppVeyor - é um sistema de CI focado em desenvolvimento para .NET, tornando a criação e manutenção de um servidor de builds uma ação simples.
  • Slack - é um sistema de notificação que utilizamos em conjunto com uma ferramenta de CI para obtermos notificações sobre builds do projeto.
  • SQL Server Express 2012 - é um sistema de Bancos de Dados gratuito, ideal para utilização em aplicações pequenas com até 10GB de armazenamento.
  • Entity Framework - é um framework de mapeamento Objeto-relacional de código aberto que visa facilitar o trabalho com Bancos de dados em serviços que se utilizam do paradigma orientado a objetos.
  • Astah - Astah é uma ferramenta de design de software livre que suporta diagramas UML.
  • .NET - .NET é parte integrante de vários aplicativos em execução no Windows e fornece a funcionalidade comum para esses aplicativos sejam executados. Para desenvolvedores, o .NET Framework fornece um modelo de programação abrangente e consistente para a criação de aplicativos que têm visualmente impressionantes experiências de usuário e uma comunicação direta e segura.

Telas do sistema

Todas as telas do sistema se encontram no link abaixo, pois queremos representar toda a evolução das telas do aplicativo, e inserir todas essas imagens neste tópico iria polui-lo, portanto optamos por criar outro tópico direcionado para este objetivo.

Telas Mobile

Modelo do banco de dados

Mais informações com relação ao banco de dados se encontram no link a seguir: Banco de Dados

Descrição dos padrões de projeto utilizados

Padrão: Builder

Onde foi utilizado: Projeto MimAcher.GeradorDados: gerador de dados utilizado para testes.

Justificativa: Temos diversos componentes independentes que juntos formam objetos do tipo item e participante. Utilizando o padrão builder com um diretor, os builders formam os objetos Item e Participante, cada um chamando os seus respectivos geradores. Além disso, os dois builders foram centralizados num diretor (que funciona com uma Fachada), de forma que a criação desses objetos fica centralizada.

Padrão: Fábrica

Onde foi utilizado: Projeto MimAcher.CursorBDLocal: montador de comandos para carga de dados no banco local.

Justificativa: escolhemos utilizar o padrão fábrica nesta parte pelo fato de que todas as requisições ao banco são feitas através de procedures. Cada procedure possui diversos parâmetros, que possuem as mesmas etapas de configuração mas com valores diferentes (string, date, etc). Então, foram utilizadas fábricas para cada um dos tipos de parâmetro, e as requisições de criação desses vários tipos foram centralizadas numa fábrica abstrata estática (que mais uma vez funciona como uma Fachada).

Onde foi utilizado: Projeto MimAcher.Mobile: projeto contendo o código do aplicativo mobile.

Justificativa: Como todas as telas possuem métodos em comum, foi decidido usar uma interface IFabricaTelas, contendo os métodos dessas telas, e algumas classe Fabrica implementando esses métodos com base na funcionalidade desejada para cada uma telas do sistema, sendo herdada então em outro momento pela classe responsável por determinada tela.

Padrão: Cadeia de Responsabilidade

Onde foi utilizado: Projeto MimAcher.Mobile: projeto contendo o código do aplicativo mobile.

Justificativa: Foi utilizado em dois momentos, uma cadeia de responsabilidade para o validador de informações inseridas, e em outro momento para o checador de conexões, já que em ambos momentos eu possuo classes com certa responsabilidade, e desejo interromper a execução de acordo com o resultado dessa tarefa.

Padrão: Decorator

Onde foi utilizado: Projeto MimAcher.Mobile: projeto contendo o código do aplicativo mobile.

Justificativa: Foi utilizado praticamente em todas as controller de interface (activitys), pois grande parte delas possui funcionalidades especificas(métodos específicos) o que é oriundo do fato de terem sua implementação separada.

Padrão: Comando

Onde foi utilizado: Projeto MimAcher.Mobile: projeto contendo o código do aplicativo mobile.

Justificativa: Foi utilizado durante todo o projeto, pois nossos eventos (clique, inserção) são comandos que desencadeiam alguma funcionalidade do sistema, portanto esse padrão está bem presente, com exceção de armazenar uma lista com os comandos executados(como apresentado em aula).