sexta-feira, 31 de março de 2017

REST API - 31/03/2017



O sistema StLocator tem a proposta de oferecer seus serviços em forma  de API, supondo um eventual crescimento da aplicação e ou integração com outros sistemas que estendam e ou agreguem de alguma forma à solução para restituição de bens perdidos, portanto o nosso servidor utilizará o modelo de arquitetura REST.

Transferência de Estado Representacional, em inglês, Representation State Transfer, ou REST, é um termo datado de 2000 na tese de doutorado de Roy Fielding, um dos principais autores das especificações do protocolo HTTP e co-fundador do projeto Apache Web Server. A própria rede mundial de computadores é um exemplo de aplicação funcionando em REST. Essa tecnologia aproveita o protocolo mais utilizado e seus métodos para realizar transações stateless. Também conhecidos como HTTP verbs, pode-se citar entre os mais comuns: GET, POST, PUT, DELETE.  O paradigma “sem estado” dessas transações de requisição entre cliente e  servidor torna cada um delas únicas, poupando o lado do cliente de tratar comunicação com banco de dados, logs, cache, etc., e da mesma forma o lado servidor não lida com interface, experiência de usuário, logo tal divisão permite liberdade de evolução distinta para os ambientes. A partir desse princípio o modelo de serviço converge com o estrutural da aplicação, que a princípio considerou-se tratar de um MVC, quando na prática acaba se tornando um MVW, Model View Whatever,  o tanto faz é uma bem humorada definição sugerida pela equipe do Angular JS que significa utilizar  o que for mais adequado para aplicação, seja MVC, MVVM ou o MVP. Neste momento utilizaremos o MVC, contudo outras abordagens poderão ser analisadas durante o desenvolvimento.

Nosso servidor REST terá diversos tipos de respostas de acordo com as  requisições clientes, pois disponibilizaremos respostas em JSON, XML, HTML e CSV, o que permite uma integração com aplicações Web e Mobile.

quarta-feira, 29 de março de 2017

Framework PHP - 29/03/2017

Resultado de imagem para codeigniter
O desenvolvimento de um sistema de forma “from scratch”, ou seja do zero, é custosa e requer muita experiência do desenvolvedor e domínio da tecnologia empregada para uma conclusão bem sucedida. Esse é o motivo para a popularidade do uso de frameworks, toolkits, engines, etc., que tornam o processo de construção de um sistema drasticamente mais fácil, por exemplo, em desenvolvimento de jogos, onde há uma enorme gama de ferramentas facilitadoras utilizadas tanto por amadores quanto pela indústria digital. A partir dessa premissa a equipe São Longuinho, optou por utilizar uma framework para a criação do lado servidor da aplicação, à tal escolha pesou dois pontos fundamentais que são a facilidade de uso e ou aprendizado e poder da ferramenta, para tanto foram avaliados diversas frameworks e chegou-se ao Cakephp e CodeIgniter, ambas as duas mais populares e gratuitas. Tal popularidade é resultado do poder de ambas, que são muito bem documentadas, contêm bibliotecas repletas de funcionalidades e facilidades, mas o ponto de desempate foi a facilidade de manipulação e adaptação aos interesses do nosso servidor como descrito no escopo do projeto, uma API Rest. 

A framework escolhida foi o CodeIgniter cuja arquitetura é a MVC (Utilizaremos o MVW, mas trataremos desse tema na próxima postagem), que será utilizado junto com o CRUDgniter para uma implementação do tipo database first e uma extensão para o REST server. Essa decisão nos exonera da árdua tarefa de construir funcionalidades complexas, como as relacionadas à segurança de acesso à diretórios, roteamento, arquivos de configurações, etc., portanto permite que a equipe tenha foco principal em desenvolver o negócio da aplicação.

terça-feira, 21 de março de 2017

PHP - POO - 21/03/2017

A linguagem escolhida para o back-end da aplicação é o PHP (PHP Hypertext Preprocessor), uma linguagem de programação interpretada escolhida pelos seguintes atrativos: ser a mais utilizada no lado servidor, por ser de código aberto, de fácil aprendizado, multi-plataforma, de baixo custo de manutenção e consumo, e principalmente por suportar o paradigma de orientação à objetos. A arquitetura do sistema seguirá o MVC (model, view, controller), implementando classes de ORM (Object Relational Model) na camada mais importante a Model, através de desgin patterns como Factory, Composite e Repository e técnicas de programação PDO (PHP data object) para acesso padrão aos diversos bancos de dados relacionais suportados por essa linguagem, de forma a tornar a aplicação o mais flexível possível, por exemplo, usaremos o banco PostgreSQL, mas através de um arquivos .ini é possível mudar para qualquer outro, como o sqlite, mysql, oracle, etc. A versão utilizada será a 7.0, tomando como material principal de referência o livro php Programando Orientado a Objetos do graduado analista e mestre em engenharia de software Pablo Dall’Oglio.



    O servidor funcionará como uma API, permitindo que seja usada por fontes externas através de REST, portanto em comandos de HTTP semântico, como GET, PUT, DELETE, UPDATE, etc, retornando objetos JSON (JavaScript Object Notation) menos verbosos que o XML, seguindo uma tendência tecnológica para aplicações em microservices, o que facilita a integração com outros sistemas.

segunda-feira, 13 de março de 2017

Reunião Sobre Ressalvas - 12/03/2017

Na aula para orientação, do dia 08/03, demonstramos para o professor os requisitos funcionais e não funcionais do sistema, o que gerou ressalvas do professor Ivan, e as ressalvas foram nossos principais assuntos na reunião semanal do dia 12/03, feita via Skype.

Com as ressalvas, definimos que teríamos que alterar o MER e o DER que já estavam prontos, com as principais mudanças de:

  • Flag de controle para saber quais são as ocorrências que irão passar na próxima verificação, para evitar várias leituras simultâneas na tabela.
  • Tabela de log de alteração para manter histórico das ocorrências, mantendo trilha das alterações realizadas pelo usuário.
Além das alterações no modelo e diagrama, alteramos a ideia de excluir dados antigos de ocorrências já correspondidas e criaremos uma tabela de histórico, visando a performance para análises de correspondências das ocorrências.

Definimos na reunião que utilizaríamos SHA_2 para o armazenamento das senhas dos usuários que optarem por criação da conta diretamente no site e para as empresas que se interessarem pelo serviço.

Os próximos passos, deixamos para fechar 100% o MER e o DER, para iniciarmos a implantação e fase de testes do modelo, além de definir as demais análises, fechando os assuntos até o final do mês, para o início do desenvolvimento e estruturação do documento.

quarta-feira, 8 de março de 2017

Desenvolvimento da Análise - 06/03/2017


No dia 06/03/2017 a equipe São Longuinho se reuniu no Shopping D a fim de conversar sobre o Sprint definido no dia 01/03/2017. A ideia era basicamente ver a evolução de cada uma das tarefas elencadas, bem como dificuldades e viabilidades para melhor execução.

Os principais pontos abordados foram: 
  • Demonstração do ambiente previamente preparado
  • Modelo Entidade-Relacionamento
  • Diagrama Entidade-Relacionamento
  • Casos de Uso
  • Diagrama de Caso de Uso
  • Requisitos Funcionais
  • Requisitos Não Funcionais

Todas as tarefas elencadas para o Sprint desta semana fluíram bem, sem atrasos. A maior dificuldade se deu na construção do MER e do DER, uma vez que a equipe não estava conseguindo abstrair todos os conceitos dos requisitos funcionais e não funcionais. Mesmo assim, a ideia é chegar na aula de quarta-feira (08/03/2017) com estes pontos definidos, para que os professores possam nos orientar.

domingo, 5 de março de 2017

Preparação do ambiente Amazon AWS - 03/03/2017

A fim de entender e estudar a arquitetura dos serviços da Amazon, esse fim de semana corremos atrás de estudar as configurações necessárias para que o sistema funcione perfeitamente. 

Conseguimos configurar uma máquina virtual Linux com o EC2, conectar via SSH utilizando o cliente PuTTY no Windows e realizar a instalação dos pacotes que iremos precisar para a utilização do sistema (Servidor web, PHP e PostgreSQL+Postgis). Com bastante leitura da documentação da Amazon AWS (disponível em https://aws.amazon.com/documentation/), conseguimos utilizar o Amazon Route 53 (serviço de DNS da Amazon) e direcionar nosso domínio (http://stlocator.com.br). 



Optamos por entender a infraestrutura do nosso ambiente para evitar problemas ao final do projeto (dica dada por alunos de semestres anteriores da disciplina), tendo assim, uma experiência fluída e tranquila ao disponibilizar nossa aplicação. 

Boa semana a todos, e não esqueça de acompanhar também a equipe São Longuinho no YouTube (o primeiro vídeo já foi enviado!).

Reunião para acertos - 25/02/2017

No dia 25/02, a equipe São Longuinho se reuniu no Starbucks da Avenida Paulista - Consolação a fim de discutir alguns assuntos definidos previamente. O foco principal da reunião era debater sobre as ressalvas e orientações dos professores após a nossa primeira apresentação para estes e para os colegas de sala de aula.

A reunião foi muito produtiva e conseguimos sair de lá com definições que foram além da pauta da reunião.

Primeiramente discutimos os pontos levantados pelo professores após a apresentação inicial do projeto. A primeira ressalva foi com relação à internacionalização do aplicativo: nós aceitamos a sugestão dos professores, de criar um aplicativo pensando em sua utilização global. Para isso, utilizaremos os padrões do i18n. Em seguida, discutimos sobre a possibilidade da utilização de um servidor AWS RDS junto com um servidor AWS EC2. A princípio esta será a infra estrutura do sistema. Posteriormente, falamos ainda da figura de um administrador do sistema, algo que não estava em nossos planos inicialmente. Este foi um ponto muito importante levantado pelos professores e decidimos que iremos criar esta entidade para administrar alguns parâmetros do sistema.

Partimos então para a definição do nome do sistema. De início, ele iria se chamar São Longuinho. Contudo, após a sugestão de internacionalização, pensamos em criar um nome que fosse facil de se pronunciar e que pudesse ser usado em qualquer lugar do mundo. A escolha foi: Saint Locator, ou em abreviação, St.Locator. Dessa forma, podemos manter a ideia de um "Santo Localizador" que poderá ser usado em qualquer lugar do globo. Logo após a definição do nome do projeto, registramos o domínio "stlocator.com.br".

Começamos a discutir os casos de uso do sistema e esboçar o diagrama de casos de uso. Em paralelo, iniciamos a descrição também dos requisitos funcionais e não funcionais.

O último assunto abordado na reunião foi o Sprint para a próxima semana.

A reunião foi muito produtiva e a equipe São Longuinho irá continuar nesta tocada, até o fim do projeto.

O próximo passo agora é seguir à risca o Sprint discutido e entregar tudo que combinamos neste reunião.