Racheiros

Escopo

Aplicação web gratuita voltada para organização de eventos de qualquer natureza, como reuniões, festas, rachas, treinos, etc.

• Um usuário cadastrado poderá criar o evento e enviar convites para pessoas cadastradas ou não, que deverão responder ao convite, e assim o criador do evento poderá controlar e administrar o mesmo;
• Fornecedores de produtos ou serviços, como por exemplo distribuidoras de bebidas e alimentos, locadores de espaços próprios para a prática em questão, etc., poderão se cadastrar com um perfil de prestador de serviços, que poderá ser pesquisado e contatado pelos administradores de eventos a fim de estabelecer um canal de comunicação efetivo e simplificado entre eles e registro de suas tarefas;
• Promoções poderão ser ofertadas para usuários de acordo com suas práticas registradas.

Cronograma

• Modelagem do Sistema
  • Definição do escopo
  • Especificação dos requisitos
  • Diagrama de Classes
  • Diagrama de Casos de Uso
  • Detalhamento dos Casos de Uso
• Implemenação do Banco de Dados
  • Desenho do Banco de Dados
  • Escolha do SGBD
  • Implementação do Banco de Dados
• Implantação da Infraestrutura
  • Definição do ambiente
  • Aquisição do endereço
  • Deploying da aplicação
• Desenvolvimento da aplicação
  • Criação de interface básica
  • Implemenação do Controle de Versões
  • Desenvolvimento dos casos de uso

5W2H

• What?
  • Qual o nome da solução?
    • http://www.racheiros.com.br/ (Sujeito a alteração)
  • Qual o objetivo, a finalidade?
    • Desenvolver um site que ajude o usuário a organizar eventos, simplificando tarefas como como marcar horários, cotar preços, escolher locais, estimar a quantidade de presentes, convidar pessoas, controlar pagamentos e qualquer outra tarefa que se deve preocupar a realizar um determinado evento. Além de auxiliar usuários fornecedores de serviços e ou produtos a divulgar e controlar suas atividades, como por exemplo, proprietários de locais à reservar horários e gerenciar o uso de seu estabelecimento. Desta forma, sendo um atrativo meio de comunicação para fabricantes e lojas que poderão lançar seus produtos e promoções para usuários que possam se interessar, de acordo com suas práticas.
  • O que é a aplicação?
    • Um portal web com interface gráfica intuitiva para facilitar a comunicação entre os usuários e com buscas de informações, tais como dados dos usuários, grupos, locais e horários livres, serviços interessantes para o tipo de evento e consulta de preços.
  • Qual o diferencial deste serviço?
    • Simplificar as atividades na organização de eventos, colocando tudo que é essencial a fácil acesso do usuário.

• Why?
  • Porque desenvolver esta solução?
    • Inúmeros eventos acontecem diariamente, e muitas vezes os organizadores não tem tempo o bastante para procurar serviços ou produtos como gostariam, gastam bastante tempo tentando contatar os convidados e até acabam esquecendo de pessoas que deveriam ser convidadas, e esta aplicação será de grande utilidade para resolver ou minimizar estes problemas. Por outro lado, os fornecedores de serviço ou produtos encontrarão uma maneira simples e efetiva de divulgar suas atividades.
  • Porquê alguém investiria neste negócio?
    • Pois as pessoas estão constantemente se reunindo e o tempo fica cada vez mais escasso nos dias atuais, então facilitar estas práticas se torna bastante interessante, ainda mais por ser gratuita, porém com bastante potencial para publicidade efetiva, como por exemplo, uma loja de artigos esportivos lançar suas ofertas a todos os usuários que compareceram a eventos de caráter esportivo.

• Where?
  • Onde poderá ser instalada?
    • A proposta inicial é que esta aplicação seja instalada num servidor Web comercial e que os administradores e membros possam acessá-la facilmente, simplesmente autenticando com usuário e senha.
  • Onde poderá ser usada?
    • Em qualquer dispositivo que suporte HTML e tenha conexão com a internet.
  • Onde poderá ser testada?
    • Em clubes, quadras, ginásios, estúdios, locais de eventos que aderirem ao projeto experimentalmente para que seja divulgado aos usuários, principalmente, esportistas os horários disponíveis dos locais agendados.

• When?
  • Qual a previsão de lançamento da solução?
    • É interessante que se tenha ao menos uma interface básica com as principais funcionalidades até Julho/2015.
  • Cronograma disponibilizado anteriormente.

• Who?
  • Quem pode usar?
    • Qualquer usuário que deseja organizar um evento, de pequeno ou grande porte, público ou privado. E também fornecedores de serviços ou produtos que estejam interessados em disponibilizar suas especialidades e preços para pesquisa e contato dos organizadores de eventos.
  • Quem pode desenvolver?
    • Qualquer programador com a infra estrutura necessária e tempo disponível.
  • Quem poderá fazer publicidade para os usuários?
    • Empresários que assinarem algum tipo de contrato ou plano poderão enviar suas ofertas para os usuários que participaram de eventos com o perfil de seu ramo de negócio por e-mail (futuramente por SMS ou URA).

• How Much?
  • Quanto custará o produto para o usuário?
    • A aplicação será gratuita para usuários de qualquer perfil.
  • Quanto custará todo o desenvolvimento e manutenção?
    • Este valor envolverá todo o custo com a aplicação, seja de mão de obra ou equipamentos, e deverá ser cotado.
  • Qual o custo para a divulgação de propagandas?
    • Valor deverá ser calculado de acordo com a oferta e quantidade de usuários que a receberão.

• How?
  • Como desenvolver?
    • Utilizar a linguagem Java com banco de dados SQL para armazenamento das informações do site.
  • Como utilizar?
    • Acessando a aplicação em qualquer dispositivo com internet e autenticando com e-mail/nome de usuário e senha.

Requisitos

Funcionais

• Cadastro de usuários com opção de importar dados de redes sociais (Facebook, Twitter, Google+...);
• Cadastro de prestadores de serviço que deverão classificar sua natureza com tags;
• Recuperação de senha;
• Usuário poderá criar e gerenciar grupos;
• Destacar aniversários dos membros de cada grupo;
• Usuário poderá criar e administrar eventos únicos ou períodicos, e que necessitam ou não pagamento;
• Possibilitar o controle de quem quitou ou não o débito para eventos que requerem pagamento;
• Fornecer informações para transferência bancária e anexo de comprovantes de pagamento do evento por parte dos participantes;
• Cadastro de local para o evento (Possibilitar que o cadastro do local seja completado pelo fornecedor de serviço de locação);
• Envio de convites com confirmação de presença pelos administradores dos eventos para os convidados que poderão ou não ser cadastrados à aplicação;
• Manter histórico de eventos;
• Usuário poderá repetir um evento criado pelo mesmo;
• Usuário poderá agendar eventos;
• Atualização e cálculo da presença individual de cada convidado;
• Administrador criador do evento poderá adicionar usuários cadastrados e confirmados como administradores do evento;
• Administradores poderão pesquisar e contatar prestadores de serviços cadastrados;
• Visualização do evento para qualquer convidado;
• Relatórios estatísticos sobre frequência e reputação de usuários cadastrados;
• Permitir qualificação do evento por parte dos convidados presentes;
• Publicidade para usuários de acordo com suas práticas recentes.

A aplicação poderá, posteriormente:

• Permitir controle financeiro e pagamentos online aos fornecedores e organizadores de eventos com pagamento;
• Permitir a inclusão de vídeos, fotos e textos nos eventos;
• Permitir relatorios de personalizados (campos a escolha do usuário);
• Permitir funcionalidades específicas para as práticas mais realizadas, como por exemplo a votação do Bola Cheia e do Bola Murcha ou montagem de times randômicos para esportes praticados em equipe, etc.;
• Envio de SMS ou URA para confirmação de presença;
• Permitir qualificação do site pelos usuários.

Não-funcionais

• Autenticação do usuário por email/nome de usuário e senha (ou contas de redes sociais);
• Interagir com usuários por e-mail;
• Seguir uma arquitetura orientada a serviços, facilitando integrações com outros sistemas;
• Ser disponibilizado na web;
• Possuir interface adequada para acesso em diferentes dispositivos e plataformas;
• Estabelecer vínculo com o calendário do Google;
• Utilizar https para login e páginas de gerenciamento, e http para o restante.

Objetos

Diagrama de Classes

Erro ao criar miniatura: Arquivo não encontrado

Casos de Uso

Detalhamento

Caso de Uso: Cadastrar

Ator: Usuário

Pré-condições: Usuário deve acessar a aplicação web.

SEQUÊNCIA DE EVENTOS:
1. Usuário entra com e-mail para cadastro.
2. Sistema busca pelo para o e-mail colocado.
3. Sistema acha o registro e verifica se possui cadastro completo ou não por meio do campo de controle de cadastro.
4. Sistema insere o e-mail e cria ID de usuário.
5. Formulário é aberto para o preenchimento das informações necessárias para o tipo de usuário selecionado.
6. Usuário é cadastrado no banco e o campo de controle é atualizado.
SEQUÊNCIA ALTERNATIVA
4b. Sistema encontra ID de usuário para o e-mail informado.
5b. Formulário é aberto para o preenchimento das informações necessárias para completar o cadastro.
6b. Usuário é atualizado no banco e o campo de controle de cadastro é atualizado.
7b. Informações anteriores para o ID de usuário, como eventos que compareceu são carregadas.

Pós-condições: Usuário é atualizado no banco de dados.

Caso de Uso: Autenticar

Ator: Usuário

Pré-condições: Usuário deve ser cadastrado.

SEQUÊNCIA DE EVENTOS:
1. Usuário entra com e-mail/login e senha.
2. Sistema busca pelo registro do usuário e verifica se possui cadastro para o e-mail ou login colocados.
3. Sistema acha o registro e verifica a senha para o usuário.
4. Verificação do tipo do usuário cadastrado, se pessoa física ou jurídica.
5. Usuário é autenticado.
SEQUÊNCIA ALTERNATIVA
2b. Caso o funcionário entre com a senha incorreta é informado que a senha não é compatível para o e-mail/login informado.
2c. Se não existe registro do e-mail/login inseridos é exibida informação para o usuário que não possui registro no banco para informação dada e que deve prosseguir com cadastro.

Pós-condições: Usuário é autenticado e consegue acessar as opções adequadas para o seu tipo de cadastro.

Caso de Uso: Criar evento

Ator: Usuário

Pré-condições: Usuário deve ser autenticado e cadastrado como pessoa física.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção para criação de eventos.
2. Usuário preenche as informações essenciais do evento como data e horário, duração, tipo do evento, local do evento, se é ou não cobrado valor,
descrição e outras informações pertinentes não obrigatórias.
3. Usuário salva o evento.
4. Evento é adicionado na agenda do usuário.
SEQUÊNCIA ALTERNATIVA
2b. Usuário seleciona opção para busca de local, onde poderá pesquisar por usuários cadastrados como pessoas jurídicas prestadoras de serviço de locação como, por exemplo, “Chácara do Seu José”.
3b. Seleciona e confirma a opção desejada, e as informações do local são preenchidas com os dados salvos do prestador de serviço de locação selecionado.
4b. Usuário preenche as opções restantes.
5b. Usuário salva o evento.
6b. Evento é adicionado na agenda do usuário e também na do usuário locatário selecionado.

Pós-condições: Evento é criado e adicionado ao banco de dados com o usuário criador do evento como administrador do mesmo. 

Caso de Uso: Convidar

Ator: Usuário

Pré-condições: Usuário deve ter criado o evento ou ter sido privilegiado com permissão de administrador do evento por outro administrador.

SEQUÊNCIA DE EVENTOS:
1. Administrador seleciona opção para enviar convites do evento.
2. Administrador preenche o e-mail do convidado.
3. Sistema verifica se e-mail é cadastrado no banco de dados.
4. E-mail é inserido no banco e criado um identificador para o usuário, porém um indicador é marcado para usuário sem cadastro.
5. Convite é enviado ao e-mail preenchido, com informações do evento e link para visualização do mesmo (se evento for pago, deve-se colocar o valor a ser cobrado do convidado).
6. Evento é adicionado na agenda do usuário convidado.
SEQUÊNCIA ALTERNATIVA
2b. Administrador seleciona convidados em seus grupos.
3b. Convite é enviado ao e-mail cadastrado pelos usuários selecionados, com informações do evento e link para visualização do mesmo.
4b. Evento é adicionado na agenda dos usuários convidados.

4c. Verifica indicador de cadastro para o e-mail informado já com registro no banco, marcado como usuário sem cadastro.
5c. Convite é enviado ao e-mail preenchido, com informações do evento e link para visualização do mesmo.
6c. Evento é adicionado na agenda do usuário convidado.

4d. Verifica indicador de cadastro para o e-mail informado já com registro no banco, marcado como usuário cadastrado.
5d. Perfil do usuário cadastrado no e-mail informado é exibido, com opção para adicionar a grupo.
6d. Convite é enviado ao e-mail preenchido, com informações do evento e link para visualização do mesmo.
7d. Evento é adicionado na agenda do usuário convidado.

Pós-condições: Convite é enviado. 

Caso de Uso: Gerenciar evento

Ator: Usuário

Pré-condições: Usuário deve ter criado o evento ou ter sido privilegiado com permissão de administrador do evento por outro administrador.

SEQUÊNCIA DE EVENTOS:
1. Administrador seleciona opção para gerenciar evento.
2. Lista de convidados é exibida com status da confirmação de presença do usuário e opções do gerenciamento, como conceder permissão de administrador e enviar solicitação de resposta do convite são mostradas e também opções para editar informações básicas do evento.
SEQUÊNCIA ALTERNATIVA
3b. Administrador concede permissão de administrador de evento a usuário com status da confirmação de presença “confirmado”.
4b. Usuário recebe privilégio de administrador do evento.

3c. Administrador seleciona opção para solicitação de resposta do convite ao convidado.
4c. E-mail é enviado solicitando resposta ao convite.

3d. Administrador altera informações do evento.
4d. Novas informações são salvas na base de dados.

Pós-condições: Lista de convidados e informações do evento são exibidas com opções de gerenciamento.

Caso de Uso: Visualizar evento

Ator: Usuário

Pré-condições: Usuário deve ter sido convidado ao evento.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona link correspondente ao evento.
2. Página do evento é mostrada, com todas as informações salvas para o mesmo e também a lista dos convidados.

Pós-condições: Evento é exibido.

Caso de Uso: Responder convite

Ator: Usuário

Pré-condições: Usuário deve ter sido convidado ao evento.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona o link para envio de resposta ao convite do evento.
2. Opções de status da presença são exibidas para escolha do usuário.
3. Resposta do usuário é alterada no banco de dados.
4. E-mail é enviado aos administradores do evento com a resposta do convite.
SEQUÊNCIA ALTERNATIVA:
1b. Usuário autenticado seleciona o evento na agenda ou em área para visualização dos próximos compromissos.
2b. Evento é exibido mostrando a situação do convite do usuário, que pode alterar a o status da presença dentre as opções que são exibidas para escolha do usuário.
3b. Resposta do usuário é alterada no banco de dados.
4b. E-mail é enviado aos administradores do evento com a resposta do convite.

Pós-condições: Resposta ao convite é alterada.

Caso de Uso: Visualizar agenda

Ator: Usuário

Pré-condições: Usuário deve possuir link para visualização da agenda ou estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona link correspondente a sua agenda.
2. Agenda do usuário é carregada, com histórico de eventos para o qual foi convidado ou que possui ligação ao evento, no caso de locadores dos locais
para a realização do mesmo, com opções como busca por datas específicas, exibir mensalmente, semanalmente ou apenas os eventos.
SEQUÊNCIA ALTERNATIVA:
1b. Usuário autenticado seleciona opção correspondente a sua agenda.
2b. Agenda do usuário é carregada, com histórico de eventos para o qual foi convidado ou que possui ligação ao evento, no caso de locadores dos locais para a realização do mesmo, com opções como busca por datas específicas, exibir mensalmente, semanalmente ou apenas os eventos.

Pós-condições: Agenda é exibida.

Caso de Uso: Criar grupo

Ator: Usuário

Pré-condições: Usuário deve estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção para visualizar seus grupos, que listará os grupos já criados pelo usuário e terá ícone para criar novo grupo, que deverá ser selecionado.
2. Formulário com dados do grupo é exibido para preenchimento.
3. Usuário salva as informações, que são armazenadas e o novo grupo estará visível na lista de grupos do usuário.

Pós-condições: Grupo é armazenado no banco.

Caso de Uso: Gerenciar grupo

Ator: Usuário

Pré-condições: Usuário deve estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção para visualizar seus grupos, que listará os grupos já criados pelo mesmo.
2. Usuário seleciona o grupo.
3. Informações do grupo são exibidas, com opções para alteração e desativação do grupo, adicionar ou remover participantes, que não precisam aceitar solicitações e não possuem acesso ao grupo.
SEQUÊNCIA ALTERNATIVA:
4b. Se houver alteração nos dados do grupo ou na lista de participantes, grupo atualizado é exibido.

Pós-condições: Grupo é exibido e pode ser alterado no banco.

Caso de Uso: Pesquisar

Ator: Usuário

Pré-condições: Usuário deve estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção para pesquisa e deverá inserir o conteúdo a ser buscado.
2. Lista é exibida contendo quaisquer informações para o conteúdo inserido, podendo ser de perfis de usuários ou eventos para qual foi convidado.
3. Usuário poderá selecionar a opção desejada, que será exibida de acordo com sua natureza (Exibir perfil ou Visualizar evento).

Pós-condições: Conteúdo buscado é disponibilizado ao usuário.

Caso de Uso: Exibir perfil

Ator: Usuário

Pré-condições: Informações requeridas na pesquisa, lista de participantes de grupos, lista de convidados de eventos ou exibição do próprio perfil na área de usuário autenticado.

SEQUÊNCIA DE EVENTOS:
1. Perfil selecionado é buscado no banco de dados.
2. Informações do usuário são exibidas com opção para convidar a evento futuro, iniciar conversas ou lista de serviços ou produtos ofertados no caso de usuários cadastrados como pessoas jurídicas.
SEQUÊNCIA ALTERNATIVA:
3b. Se o usuário estiver visualizando seu próprio perfil, opção para Gerenciamento do perfil é exibida.

Pós-condições: Perfil é exibido.

Caso de Uso: Gerenciar perfil

Ator: Usuário

Pré-condições: Usuário deve estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Informações do usuário são exibidas em perfil com opções para alteração.
2. Informações são atualizadas no banco de dados.

Pós-condições: Perfil é atualizado.

Caso de Uso: Conversar

Ator: Usuário

Pré-condições: Usuários devem ser cadastrados, e estar autenticado para enviar mensagem.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção de Conversa em perfil de outro usuário.
2. Sistema busca informações de conversa entre os usuários no banco.
3. Histórico de mensagem é exibido
4. Novas mensagens são armazenadas no banco.
SEQUÊNCIA ALTERNATIVA:
3b. Nova conversa é iniciada e armazenada no banco.

1c. Usuário seleciona opção para exibir suas conversas em sua página inicial.
2c. Sistema busca informações de conversa do usuário no banco.
3c. São exibidos os usuários com que o usuário já conversou, juntamente com o conteúdo da última mensagem.
4c. Novas mensagens são armazenadas no banco.

Pós-condições: Conversa é atualizada.

Caso de Uso: Alterar localização

Ator: Usuário

Pré-condições: Usuário deve estar autenticado.

SEQUÊNCIA DE EVENTOS:
1. Usuário seleciona opção de sua localização.
2. Sistema busca informação da localização do usuário.
3. Usuário seleciona se deseja ou não armazenar informação de localização, que será exibida em seu perfil.
4. Localização é inativada e opção é armazenada.
SEQUÊNCIA ALTERNATIVA:
4b. Localização é ativada, e mapa é aberto (“Google Maps”) para selecionar o local, com a ajuda da obtenção da localização do dispositivo.
5b. Informações são armazenadas no banco e ficam disponíveis para exibição no perfil do usuário.

Pós-condições: Informações de localização são atualizadas.

Caso de Uso: Associar tags

Ator: Usuário

Pré-condições: Usuário deve estar autenticado e ser cadastrado como pessoa jurídica.

SEQUÊNCIA DE EVENTOS:
1. Opção de “Palavras chave” exibida no perfil do usuário cadastrado como pessoa jurídica, com objetivo de caracterizar seus serviços ou produtos ofertados para facilitar buscas, é selecionada.
2. São listadas todas as associações já feitas, com opção para nova associação.
3. Lista de tags armazenadas é exibida para seleção.
4. Sistema associa tag selecionada ao perfil do usuário.
SEQUÊNCIA ALTERNATIVA:
4b. Tag nova é inserida pelo usuário e armazenada na lista de tags existente.
5b. Sistema associa nova tag ao perfil do usuário.

Pós-condições: “Palavras chave” são associadas ao usuário.

Caso de Uso: Cadastrar serviços

Ator: Usuário

Pré-condições: Usuário deve estar autenticado e ser cadastrado como pessoa jurídica.

SEQUÊNCIA DE EVENTOS:
1. Opção “Cadastrar serviços”, exibida na página inicial do usuário cadastrado como pessoa jurídica, é selecionada.
2. São listados os serviços já cadastrados, com opção para remoção ou alteração dos mesmos, e também novos serviços.
3. Formulário com informações do serviço a ser ofertado são exibidas.
4. Informações são armazenadas e ficam disponíveis para exibição no perfil do usuário.

Pós-condições: Lista de serviços ofertados pelo usuário é atualizada (Número máximo de opções por usuário a ser definido).

Caso de Uso: Cadastrar produtos

Ator: Usuário

Pré-condições: Usuário deve estar autenticado e ser cadastrado como pessoa jurídica.

SEQUÊNCIA DE EVENTOS:
1. Opção “Cadastrar produtos”, exibida na página inicial do usuário cadastrado como pessoa jurídica, é selecionada.
2. São listados os produtos já cadastrados, com opção para remoção ou alteração dos mesmos, e também novos produtos.
3. Formulário com informações dos produtos a ser ofertado são exibidas.
4. Informações são armazenadas e ficam disponíveis para exibição no perfil do usuário.

Pós-condições: Lista de produtos ofertados pelo usuário é atualizada (Número máximo de opções por usuário a ser definido).

Banco de Dados

Diagrama entidade relacionamento

SGBD - PostgreSQL

• Introdução
  • O PostgreSQL é considerado o banco de dados livre mais avançado do mundo, sendo exemplo para a especificação SQL por ser extremamente aderente a esse padrão. O projeto atual deste SGBD surgiu em 1995, com os estudantes Andrew Yu e Jolly Chen, que adicionaram um interpretador SQL para substituir a linguagem QUEL, desenvolvida para o projeto Ingres da Universidade de Berkeley na Califórnia em meados da década de 70, e divulgaram o código pela internet.

• Funcionalidades
  • O PostgreSQL possui funcionalidades sofisticadas como o controle de concorrência multiversionado (MVCC, em inglês), recuperação em um ponto no tempo (PITR em inglês), tablespaces, replicação assíncrona, transações agrupadas (savepoints), cópias de segurança a quente (online/hot backup), um sofisticado planejador de consultas (otimizador) e registrador de transações sequencial (WAL) para tolerância a falhas.

• Benefícios
  • Além da grande vantagem de ser open source, o que permite gerenciar o banco de dados com baixo custo, garantindo que não deverá pagar licenças, o PostgreSQL tem uma alta performance, recursos como consultas complexas, chaves estrangeiras, integridade transacional, controle de concorrência multi-versão, suporte ao modelo híbrido objeto-relacional, gatilhos, visões, indexação por textos, além de ter facilidade de acesso, é multiplataforma e é altamente escalável, tanto na quantidade enorme de dados que pode gerenciar, quanto no número de usuários concorrentes que pode acomodar.

• Custos
  • O PostgreSQL é uma ferramenta open source.

• Fornecedor
  • http://www.postgresql.org/

• Sistema Operacional
  • Roda em todos os grandes sistemas operacionais, incluindo GNU/Linux, Unix (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), e MS Windows.

• Tutoriais
  • http://www.postgresql.org/docs/manuals/
  • http://www.postgresqltutorial.com/

Versão anterior

Escopo 1a. versão

• Desenvolver uma solução web para acesso gratuito onde:
  • Administradores de grupo possam organizar seus eventos (rachas, ensaios, treinos, encontros, ...)
  • Atletas, artistas, músicos, etc, possam utilizar de um portal para atualização de informações e integração com seus pares
  • Empresas de aluguel de quadras, associações ou clubes possam manter um registro dos responsáveis por cada evento e ainda manter um canal de comunicação efetivo com eles
  • Empresas de compra em lote possam oferecer promoções de produtos alinhados com o uso dos membros dos grupos

Cronograma

• Modelagem do Sistema - 09/03 - 03/04
  • Definição do escopo
  • Especificação dos requisitos
  • Diagrama de Classes
  • Diagrama de Casos de Uso
  • Detalhamento dos Casos de Uso
• Implemenação do Banco de Dados - 06/04 - 17/04
  • Desenho do Banco de Dados
  • Escolha do SGBD
  • Implementação do Banco de Dados
• Implantação da Infraestrutura - 20/04 - 01/05
  • Definição do ambiente
  • Aquisição do endereço
  • Deploying da aplicação
• Desenvolvimento da aplicação - 04/05 - 20/07
  • Criação de interface básica
  • Implemenação do Controle de Versões
  • Desenvolvimento dos casos de uso

5W2H

• What?
  • Qual o nome da solução?
    • http://www.racheiros.com.br/
  • Qual o objetivo, a finalidade?
    • Construir um site que ajude os praticantes de esportes ou eventos em geral e organizadores destes a reunir com seus parceiros para marcarem horários em quadras, estúdios ou locais específicos e ajude empresários proprietários destes locais à reservar horários e gerenciar o uso de seu estabelecimento. Desta forma, sendo um atrativo meio de comunicação para fabricantes e lojas de equipamentos que por sua vez poderão lançar seus produtos e promoções.
  • O que é a aplicação?
    • Um portal web com interface gráfica intuitiva para facilitar a comunicação entre os usários e com buscas de informações, tais como dados dos usuários, grupos, locais e horários livres.
  • Qual o diferencial deste serviço?
    • A utilização de uma comunicação por SMS com os usuários para a confirmação de presença e confirmação de eventos, a possibilidade de agendar horários nos locais pela internet, o gerenciamento da utilização destes locais, divulgação de promoções, lojas e lançamento de produtos.
  • Resumo:
    • Um sistema Web que permite a criação de grupos de usuários referentes a determinada necessidade com funções interessantes como agendar compromissos, convidar por e-mail, controlar frequencia, permitir interação pelo site e uma série de serviços adicionais.

• Why?
  • O porquê de se desenvolver essa solução?
    • O caso mais comum é o inúmeros organizadores de “rachas” que gastam muito dinheiro e tempo toda semana entrando em contato com outros “racheiros” e quadras para que possam agendar e confirmar os “rachas”. Por outro lado os donos de quadras podem gerenciar melhor seu negócio facilitando novas locações, automatizando e documentando os dados de seu estabelecimento.
  • Qual o motivo?
    • Porque o mercado de aluguéis de campos, quadras, locais de eventos têm crescido nos últimos anos e o número de locais também.
  • Porquê alguém investiria neste negócio?
    • Porque as pessoas estão constantemente se encontrando, seja para uma finalidade esportiva, seja um grupo musical ou ainda uma comunidade qualquer. Efetivamente, todos querem comunicar aos demais sobre compromissos e muitas vezes controlar estas reuniões seja pelo simples cálculo da assiduidade ou ainda vinculando a pontuações, como no caso de premiação pela fidelidade
    • Com base nessa prática tão comum, ter um sistema que facilite a vida do administrador e também de todos os membros do grupo passa a ser interessante para todos. Se puder adicionar a participação de outras entidades que possam fazer uso do banco de dados de pessoas e gerar benefícios mais viável fica ainda o desenvolvimento de uma aplicação. Se for gratuita então, aí poderá ser bastante utilizada.

• Where?
  • Onde encontro solução similar? (Sistema igual ou próximo do que pretendo fazer)
    • www.peladeiro.com.br,
  • Onde poderá ser instalada?
    • A proposta inicial é que esta aplicação seja instalada num servidor Web comercial e que os administradores e membros possam acessá-la facilmente, simplesmente recebendo um usuário e senha.
  • Onde pode ser desenvolvida?
    • O desenvolvimento será feito na incubadora do UFU - Universidade Federal de Uberlândia
  • Onde poderá ser usada?
    • Em qualquer dispositivo que suporte HTML e tenha conexão com a internet. Disponível para usuários em qualquer lugar do mundo. Isto inclui dispositivos móveis como tablets e celulares
  • Onde poderá ser testada?
    • Em clubes, quadras, ginásios, estúdios, locais de eventos que aderirem ao projeto experimentalmente para que seja divulgado aos usuários, principalmente, esportistas os horários disponíveis dos locais agendados.

• When?
  • Quando começar a desenvolver?
    • O projeto está previsto para ser desenvolvido a partir do 3o. bimestre
  • Qual a previsão de lançamento da 1a. fase?
    • No 5o. bimestre, correspondendo a 10 meses de desenvolvimento, testes e disponibilização para o público.
  • Este projeto tem o seguinte cronograma:
    • 1o. bimestre: Projeto
    • 2o. bimestre: Modelagem
    • 3o. bimestre: Protótipo
    • 4o. bimestre: Desenvolvimento Fase I
    • 5o. bimestre: Teste e entrega Fase I
    • 6o. bimestre: Desenvolvimento Fase II e Manutenção Fase I

• Who?
  • Quem pode usar?
    • Organizadores de “rachas”, “racheiros”, (não se limitará apenas à futebol), donos de campos ou quadras esportivas, lojas e fabricante de equipamentos esportivos.
  • Quem pode desenvolver?
    • Qualquer programador com a infra estrutura necessária e tempo disponivel.
  • Quem poderá colocar o conteúdo?
    • As lojas e fabricantes de equipamento poderão fazer campanhas publicitárias de mercadorias e donos de quadras poderão também convidar grupos de esportistas à conhecerem suas quadras.
  • Detalhamento:
    • X Patrocinadores
    • 1 Integrador por 3 meses
    • 1 Projetista por 2 meses
    • 1 Arquiteto do ambiente por 4 meses
    • 1 Arquiteto do software por 5 meses
    • 1 DBA x 5 meses
    • 2 Desenvolvedor Junior por 4 meses
    • 1 Desenvolvedora Senior por 4 meses
    • 2 Web Designer por 3 meses
    • 1 Advogado por 1 contrato
    • 1 Analista de Mkt por 3 meses
    • 1 Analista de suporte por 6 meses

• How Much?
  • Quando custará o produto para o usuário final?
    • O preço para os racheiros é ZERO
  • Quanto custo todo o desenvolvimento?
    • O investimento total para desenvolvimento da solução envolvendo pessoal, equipamentos e demais custos estará em torno de R$ 200.000,00
  • Quanto é o custo para o provedor de conteúdo?
    • Para os estabecimentos esportivos o custo será de R$100,00 mensais. Para os patrocinadores o custo dependerá do tipo de campanha ele desejará fazer (SMS, e-mail ou banner).
  • Detalhamento de custos:
    • Hospedagem: 90 Euros/ano
    • Servidores: 2 x R$ 15.000,00
    • Notebooks: 4 x R$ 3.000,00
    • Dispositivos móveis:
      • Celulares: 5 x R$ 500,00
      • Tablets: 3 x R$ 1.200,00
    • Ads do Google: R$ 5.000,00 a cada trimestre
    • Registro da marca: R$ 10.000,00
    • Brindes para 1o.s cadastros: 50 x R$ 50,00

• How?
  • Como desenvolver?
  • Utilizar a linguaguem Java com banco de dados SQL para armazenamento das informações do site
  • Como testar?
    • Distribuir versões gratuitas para quadras e clubes para gerenciar seus horários de funcionamento e agendamento de locações.
  • Como adquirir?
    • Os estabelecimentos que desejam adquirir a ferramenta devem pagar uma mensalidade de manutenção e hospedagem das informações de suas quadras no site. Os patrocinanores devem fechar contratos para utilizarem os diversos meios de comunicação com os “racheiros”, tais como SMS, e-mail e banners no site.
  • Detalhamento:
    • Projeto: DotProject para acompanhamento de projeto
    • Modelagem: UML usando software Entreprise Architect
    • Desenvolvimento: Linguagem Java
    • Versões: SVN
    • Documentação: MediaWiki
    • Framework: Eclipse
    • Testes: JUnit
    • Ambientes:
      • Servidor:
      • Cliente: Firefox, Chrome e IE
      • Móvel: Android, Iphone e Nokia

Requisitos

Funcionais

• A aplicação deve (1a. Fase):

1. permitir a criação de grupos gerenciados por um administrador
2. criar uma forma simples de agendar os eventos
3. disponibilizar uma forma de configuração (parametrização) de funcionalidades
4. convidar os membros para os eventos programados
5. possibilitar a atualização e o cálculo da presença individual de cada membro
6. emitir relatórios estatísticos sobre frequência e pontuação
7. manter um histórico dos eventos passados
8. destacar os aniversários dos membros de cada grupo
9. Permitir a votação do Bola Cheia e do Bola Murcha
10. Permitir a pesquisa de grupos, e seus membros, inclusive sem login
11. Permitir recuperação de senha por email.
12. Cadastrar local.
13. permitir edição de grupo pelo administrador de grupo
14. permitir montagem de times randômicos dentro de eventos agendados

• A aplicação deve (2a. Fase):

1. facilitar a inclusão de vídeos, fotos e textos
2. Permitir controle financeiro e pagamento de racha por paypal ou pagseguro
3. Permitir importação de do outolook ou gmail para usuários (o administrador do racha pode criar varios usuários, e o sistema mandar os dados de acesso para cada um)
4. Permitir relatorios de personalizados (varios campos a escolha do usuário)
5. Mandar SMS de confirmação de presença
6. Mandar URA de confirmação de presença
7. Permitir a qualificação do site por parte dos usuários
8. Disponibilizar um mapa da onde a pessa esta, até a quadra (com o GPS, (Ex. IGO))
9. Montar um mapa geografico da casa dos integrantes do grupo, e sugerir a melhor quadra.
10. Possibilitar aos usuários opinar e dando idéias para implementação de novos recursos e funcionalidades.

Não-funcionais

O sistema deve:

1. ser disponibilizado na web
2. ter interface adequada para acesso por PCs, tablets, Ipads e celulares
3. interagir com os usuários por email
4. garantir autenticação do usuário pelo email e senha (com contas gmail, orkut, twitter, facebook, etc)
5. integrar-se com redes sociais como Facebook, Twitter e outras
6. vincular ao Google Calendar
7. Ser https apenas no login, e http para todo o site. (obs. sem logar o usuário poderá ver todos os dados (para aparecer no google))
8. Seguir uma arquitetura orientada a serviços, para facilitar a criação de integrações com outros sistemas

Objetos

• Usuario
  • apelido
  • sexo
  • idade
  • email
  • nome
  • sobrenome
  • cep (#)
  • numero
  • dataDeNascimento
  • codTime
  • foneCelular
  • foneFixo
  • groupsList (lista de grupos aos quais pertence)
  • peso (o quão hábil é o jogador para determinada modalidade)

• GrupoDoJogador
  • modalidade
  • time (#)
  • nome
  • numeroDeIntegrantes
  • listadeIntegrantes (nomes)
  • dataCriação
  • melhorJogador (de todas as partidas participadas e a partida do dia)
  • piorJogador (de todas as partidas participadas e a partida do dia)
  • pontuacao
  • presencaUltimosJogos

• Time
  • codTime
  • nomeTime
  • estado

• Quadra
  • cep (#)
  • numero
  • nomeQuadra
  • nomeProprietario
  • modalidade
  • preco
  • referencia
  • telefones
  • nomeFantasia

• Cep
  • codCep
  • cidade
  • bairro
  • estado

• Equipe
  • nomeEquipe
  • quadra
  • horario

• Horario
  • codHorario
  • horario

• Racha (Evento)
  • horario (#)
  • quadra (#)
  • listaGrupos (GrupoDoJogador (#)) (times participantes do evento marcado)

• Empreendedor
  • nome
  • sobrenome
  • email
  • listaDeQuadras (quadra(#))

Casos de Uso

• 01 - Manipular dados de usuário

Subcaso de uso 1.1: cadastrar usuário.
Descrição: cadastra um usuário.
Evento iniciador: usuário clica em “cadastrar”.
Atores: usuário.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Usuário clica no botão cadastrar.
2. Sistema exibe formulário com dados (nome, sobrenome, data de nascimento, estado, cidade, idade, sexo, email, telefone, endereço, apelido) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: usuário devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 1.2: atualizar/editar usuário.
Descrição: altera dados de um usuário.
Evento iniciador: usuário clica em “atualizar dados cadastrais”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “atualizar dados cadastrais”.
2. Sistema exibe formulário contendo todos os dados cadastrais.
3. Usuário altera os dados de interesse e clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de alteração de cadastro efetuada com sucesso.
Pós-condição: alterações de cadastro devidamente registradas.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).
3. Usuário desiste da atualização e aperta em cancelar.

Subcaso de uso 1.3: excluir conta.
Descrição: remover usuário do sistema.
Evento iniciador: usuário clica em “excluir conta”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “excluir conta”.
2. Sistema pede confirmação de senha.
3. Confirmada a senha, sistema exibe uma tela contendo um campo “motivo” para preenchimento.
4. Usuário preenche o campo e clica em excluir.
5. Sistema remove os dados cadastrais.
6. Sistema exibe mensagem “conta excluída com sucesso”.

Pós-condição: dados cadastrais removidos do banco de dados.
Extensões:
1. Usuário desiste da exclusão de conta e aperta em cancelar.
2. Usuário erra a senha na confirmação e sistema informa a mensagem “senha incorreta” e exibe opções de tentar novamente ou cancelar.

• 02 - Fazer login
  

Descrição: usuário entra com nome de usuário e senha para logar no sistema.
Evento iniciador: usuário clica no botão “login”.
Atores: usuário.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Usuário preenche seus dados (nome de usuário e senha).
2. Usuário clica no botão “login”.
3. Sistema exibe mensagem “usuário autenticado”.

Pós-condição: usuário autenticado no sistema.
Extensões:
1. Usuário entra com alguma informação inválida (nome de usuário ou senha) e o sistema exibe mensagem “nome de usuário ou senha inválido”.

• 03 - Se inscrever em grupo

Subcaso de uso 3.1: Solicitar inclusão.
Descrição: Solicitar inscrição a grupo de jogadores de determinada modalidade.
Evento iniciador: usuário clica em “inscrever em grupo”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “inscrever em grupo”.
2. Sistema envia solicitação de inscrição ao administrador do grupo em questão.
3. Solicitação fica pendente até que o administrador do grupo avalie e aprove a solicitação.
4. Solicitação é aprovada e usuário se torna membro daquele grupo.
5. Lista de grupos a que o usuário pertence é atualizada (novo grupo inserido).

Subcaso de uso 3.2: Enviar solicitação.
Descrição: Sistema envia solicitação de inclusão do usuário ao administrador de grupo.
Atores: sistema.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Sistema envia solicitação de inclusão de usuário ao administrador de grupo.
Pós-condição: nenhuma.

Subcaso de uso 3.3: Aprovar solicitação.
Descrição: Administrador aprova solicitação de inclusão.
Evento iniciador: usuário clica em “inscrever em grupo”.
Atores: administrador de grupo.
Pré-condição: administrador de grupo autenticado.
Seqüência de eventos:
1. Usuário clica no botão “aprovar solicitação”.
2. Sistema inclui usuário à lista de integrantes do grupo.
Pós-condição: usuário é membro do grupo.
Extensões:
1. Administrador reprova solicitação.

04 – Criar grupo gerenciado

Descrição: criar um grupo de usuários.
Evento iniciador: usuário clica em “criar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “criar grupo”.
2. Sistema exibe formulário com dados (modalidade, nome do grupo, data de Criação (automático)) a serem preenchidos.
3. Usuário clica em concluído.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de criação efetuada com sucesso.
Pós-condição: grupo devidamente criado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 4.1: importar grupo.

Descrição: criar um grupo de usuários.
Evento iniciador: usuário clica em “criar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “criar grupo”.
2. Usuário clica no botão “importar grupo”.
3. Usuário seleciona o grupo de uma lista aonde o sistema apresenta todos os grupos existentes com filtro por localização geográfica (estado, cidade, bairro).
4. Sistema exibe formulário com dados previamente preenchidos (modalidade, data de Criação (automático)), passíveis de alteração caso usuário julgue necessário.
5. Usuário clica em concluído.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de criação efetuada com sucesso.
9. Sistema envia uma solicitação de confirmação a todos os usuários do grupo importado, exibindo a estes as informações do novo grupo criado.
Pós-condição: grupo devidamente criado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 4 (passo 5).
3. Sistema valida nome do grupo aonde este não deve ser o mesmo do grupo importado (passo 5).

05 - criar uma forma simples de agendar os eventos

Subcaso de uso 5.1: Criar um evento.
Descrição: cadastra um evento
Evento iniciador: usuário clica em “Cadastrar Evento”.
Atores: usuário.
Pré-condição: Estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar Evento”
2. Sistema exibe formulário com dados (nomeDoEvento, gruposParticipantes, contatoResponsavel (telefone / email), apelidoResponsavel, eventoStatus (ativo,desativo), eventoTipo (privado, publico), quantidadeMaximaPessoas ) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
7. Sistema envia convite para todos os usuários dos grupos convidados.
Pós-condição: Evento devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 5.2: Cadastrar datas/local evento.
Descrição: cadastra datas do evento e o local.
Evento iniciador: usuário clica em “Cadastrar data/local”.
Atores: usuário.
Pré-condição: evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar data/local”.
2. Usuário seleciona um item da lista de datas disponíveis para usuário selecionar (calendário com hora e minuto).
3. Usuário seleciona um item da lista de repetições disponíveis para o usuário selecionar (semanal, mensal, quinzenal, anual, diária ) (este campo não é obrigatório).
4. Usuário informa o local que o evento será realizado (campo text) 5. Usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Sistema informa ao usuário quais usuários tem evento conflitante.
8. Se as informações estão corretas, aperta no botão confirmar.
9. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Data do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

Subcaso de uso 5.3: Cadastrar Alerta Evento
Descrição: cadastra um alerta do evento
Evento iniciador: usuário clica em “Cadastrar Alerta” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar alerta”.
2. Sistema exibe lista de alertas disponíveis para usuário selecionar (e-mail, Sms, Ligação TextToSpeack).
3. Sistema exibe lista de períodos disponíveis para alerta (x meses, x semanas, x dias, x horas), o usuário poderá selecionar apenas 1. (ex. 1 hora, ou 2 semana, ou 3 dias).
4. Usuário coloca texto para alertar o evento (sistema traz texto pré formado).
5. Usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Alerta do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

Subcaso de uso 5.4: Cadastrar pontuação / punição.
Descrição: Cadastrar pontuação / punição.
Evento iniciador: Usuário clica em “Cadastrar pontuação / punição” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar pontuação / punição”.
2. Sistema exibe para o usuário um conjunto de campos contendo:

• Nome
  
• Ponto (-100 a +100)
  
• Quantidade de dias/eventos para expiração
  
• Flag de punição ou pontuação
  

3. Usuário informa todos os campos acima e clica no botão +.
4. Sistema acrescenta este cadastro na lista imediatamente abaixo dos campos.
5. Sistema limpa os campos de maneira que o usuário possa voltar ao passo 2.
5. Após a criação das punições/pontuações, o usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Alerta do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

06 – Parametrizar funcionalidades.

Descrição: disponibilizar uma forma de configuração (parametrização) de funcionalidades.
Evento iniciador: usuário clica em “configurações”.
Atores: usuário, sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “configurações”.
2. Sistema exibe uma tela de configurações (estado: inativo/ativo (ser notificado de eventos), bloco de tela pertinente às informações do usuário (nome, apelido, etc...)).
3. Usuário faz as alterações desejadas de seu perfil.
4. Usuário clica em “salvar definições”.
5. Sistema exibe tela de confirmação.
6. Usuário clica em “confirmar alterações”.
6. Sistema exibe mensagem de alterações efetuadas com sucesso.
Pós-condição: alterações devidamente salvas.
Extensões:

Subcaso de uso 6.1: (a definir: subcasos de configuração de parâmetros do perfil do usuário).

07 – Acompanhar jogo em andamento.

Descrição: possibilitar a atualização e o cálculo da presença individual de cada membro.
Evento iniciador: usuário clica em “atualizar dados do jogo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “atualizar dados do jogo”.
2. Sistema exibe tela com lista de todos os jogadores convocados (e confirmados) para o jogo aonde o administrador do evento seleciona no sistema todos os que compareceram. Pontua cada jogador de acordo com seu desempenho no jogo selecionando os campos (criados na criação do evento), (exemplo: quantidade de gols marcados, de faltas cometidas, dribles feitos, tomadas de bola, etc).
3. Usuário clica em concluído.
4. Sistema exibe tela de confirmação para encerrar evento.
5. Usuário confirma.
4. Sistema salva pontuação do evento.
Pós-condição: presença dos jogadores confirmada.
Extensões: nenhuma.

Casos de Uso A validar

Subcaso de uso 4.2: editar grupo.

Descrição: edita um grupo de usuários.
Evento iniciador: usuário clica em “editar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “editar grupo”.
2. Sistema exibe formulário com dados previamente preenchidos (modalidade, data de Criação (automático)), passíveis de alteração.
3. Usuário clica em concluído.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de alteração efetuada com sucesso.
Pós-condição: grupo devidamente alterado.
Extensões:
1. Campo(s) obrigatório(s) não podem ser alterados para vazio(s) e retorna o valor anterior.
2. Usuário verifica que alguma informação está incorreta e volta ao passo 4 (passo 5).

Subcaso de uso 5.5: Convidar membros.
Descrição: Convidar membros para o evento.
Evento iniciador: Usuário clica em “Convidar membros” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar membro”.
2. Sistema exibe para o usuário uma lista de usuarios.
3. Usuário seleciona os membros que deseja convidar.
4. Usuario clica em convidar.
5. Sistema envia um convite para participar a cada membro convidado.
6. Sistema exibe mensagem de todos membros convidados.
Pós-condição: Membros escolhidos devidamente convidados.
Extensões:
1. Membros convidados devem informar se comparecerão ou nao ao evento, sendo passivel de alteração.
2. Um membro nao pode ser convidado mais de uma vez.

Subcaso de uso 6.1:Cadastrar empreendedor .

Descrição:cadastra um empreendendor .
Evento iniciador:usuario clica em cadastrar novo empreendendor .
Atores:usuario .
Pré-condição:nenhuma.
Seqüência de eventos:
1. Usuario clica em cadastrar novo empreendendor.
2. Sistema exibe formulário com dados (nome, sobrenome, data de nascimento, email, telefone, #listas de quadras) a serem preenchidos..
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição:empreendedor devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 6.2:Cadastrar quadra .

Descrição:cadastra uma quadra .
Evento iniciador: usuario clica em nova quadra.
Atores:usuario .
Pré-condição: estar logado como empreendedor.
Seqüência de eventos:
1. Usuario clica em nova quadra.
2. Sistema exibe formulário com dados (estado, cidade, telefone, endereço, valor do aluguel ) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição:quadra devidamente cadastrada.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).
3. Verificar a veracidade dos dados

Infra-estrutura

Será usada a infra do Google para hospedagem inicial, pois é sem custo e permite o uso de java.
Para isto, todos os desenvolvedores devem saber como programar ja sobre as APIS do google.

Um passo inicial.

Ler todo o site abaixo (iniciando pela pagina que será aberta, e passando por todos os menus do lado esquerdo)

• https://developers.google.com/appengine/docs/whatisgoogleappengine?hl=pt-BR

Outras leituras:

• http://blog.globalcode.com.br/2010/10/google-app-engine-em-10-minutos-sem.html

• http://www.thiagovespa.com.br/blog/2010/10/03/comecando-com-google-app-engine/

Layout

Considerações gerais

• O layout deve:

1. Ser o mais "clean" possível, evitando o excesso de imagens e cores
2. Ser estruturado de forma que a largura mínima suportada seja de 1024 pixels, por ser a mais comum atualmente
3. Seguir a estrutura geral adotada pelas redes sociais mais populares

Estrutura

Haverão dois tipos de layouts: para quem estiver autenticado no sistema e para quem não estiver. Dentro de cada layout haverão variações, de acordo com a seção em que o usuário estiver

Para usuários não autenticados:

• Será constituído de 3 blocos: cabeçalho, conteúdo e rodapé.

1. Cabeçalho:
   1. Busca aberta ao público no topo;
   2. Campo de login/senha e link para recuperar senha;
2. Conteúdo: bloco de conteúdo, será diferente para cada página do site;

1. Rodapé:
   1. Links para as páginas com textos institucionais e informações de copyright;

Para usuários autenticados:

• Será constituído de 4 blocos: cabeçalho, menu lateral, conteúdo e rodapé.

1. Cabeçalho:
   1. Logotipo
   2. Informação de login do usuário
   3. Botão para logout
2. Menu lateral:
   1. Menu com atalho para as principais/mais usadas funções do sistema

Os layouts específicos de cada página serão descritos mais a frente.

Home

• O conteúdo se dividirá em duas colunas:

1. Primeira coluna: Informação sobre o serviço (sucintamente e chamativa, talvez uma imagem). Talvez uma observação pode ser colocada para usuários que desejem utilizar outros recursos (para donos de quadra, etc);
2. Segunda coluna: Formulário de cadastro (praticamente um pré-cadastro, ou seja, será requerido do usuário somente as informações essenciais para a utilização das funções básicas do sistema);

Exercícios

• 1o. Calculadora
  • Arquivo:Primeiro Exercicio.pdf

Estágio

• Engenharia de Software
  • Luthuli Akanni Paixão (luthuliakanni@hotmail.com)
• Atividades:
  • I - Estudar projeto
  • I -Definir Objetos do sistema
  • I -Desenhar Classes
  • I -Modelar usando software UML
  • II - Validar Diagrama de Casos de Uso
  • II - Concluir documentação dos Diagramas de Classes e Casos de Uso
  • III - Monitoria
  • III -Estudar Diagramas de Sequencia, Estado, Colaboração, etc (
  • III -Desenhar novos diagramas (para o projeto atual ou outro qualquer)
  • IV - Estudar SOA
  • IV - Aplicar SOA em algum projeto
  • V - Estudar novas tendências em ESOF

MVC

Model view controller (MVC), é um padrão de projeto (design pattern) o qual tem por finalidade separar as responsabilidades como visualização (view), modelo (model) e controle (controller) em uma arquitetura em camadas. Esta por sua vez é a chave para a independência entre os componentes e esta independência é que vai atingir os objetivos de eficiência , escalabilidade , reutilização e facilidade de manutenção.

Como dito antes, cada camada é responsável por uma parte na aplicação:

A camada de visão ou visualização:

é responsável unicamente por implementar as classes de interface com o usuário, ou seja, esta não possui nenhum código de processamento ou de persistência dos dados. Sua única responsabilidade é a apresentação da interface ao usuário onde se dá a interação dele com o aplicativo, não importando se esta camada é implementada usando JSF (para aplicações web), swing para aplicações desktop ou console (linha de comando) como ilustrado na figura acima. Isso mostra que se tivermos nossa aplicação cuja camada de visualização está implementada usando console, podemos simplesmente trocar para uma camada implementada em swing onde esta troca é totalmente transparente para o resto da aplicação, ou seja, as outras classes não "saberão" que a troca foi efetuada justamente pelo fato do aplicativo possuir uma arquitetura em camadas, demonstrando claramente a separação de responsabilidades.

A camada de controle:

como o próprio nome sugere, é a camada responsável pelo controle da aplicação. Esta é uma camada intermediária entre a lógica de negócio (camada de modelo)e a visualização. Este controle se dá no fluxo da apresentação de acordo com as ações do usuário. Assim, se o usuário toma determinada atitude, como por exemplo de salvar informações de cadastro num banco de dados, esta camada invocará métodos de outra camada (a camada de modelo), passando os parâmetros necessários para tal. Ou se o usuário deseja consultar informações que estão no banco, novamente esta camada invocará métodos da camada de modelo para tal. Resumindo, esta camada governa o fluxo da apresentação dos dados ao usuário.

A camada de modelo:

é a camada mais importante da aplicação, pois nela está o coração do sistema. É aqui que são processadas as informações, bem como o mapeamento ou modelagem dos dados. É responsável também pela persistência do mesmo num dado banco de dados. Esta camada concentra toda a lógica de negócio do sistema definindo assim, o comportamento do mesmo.

Concluindo, o uso do design pattern MVC é muito importante para favorecer a manutenibilidade, extensibilidade e a eficiência do código, promovendo a segregação de responsabilidades em camadas.

Membros

1. Luiz Cláudio Theodoro (Idealizador)
2. Joáo Paulo Cruz Araújo (Integrador)
3. Tiago Barros de Souza (Projetista)
4. Pedro Macedo Leite (Arquiteto do ambiente)
5. Thiago Vasconcelos Mundim (Arquiteto do software)
6. Lucas Pires de Oliveira (DBA)
7. Caio Augusto Araújo de Oliveira (Web Designer)
8. Ana Lúcia Soares (Desenvolvedora)
9. Elisabete Carvalho Oliveira (Desenvolvedora)
10. Vanessa Shiguemi Caetano de Oliveira (Desenvolvedora)
11. Hiago Araujo Silva (Desenvolvedor)
12. Luiz Felipe Guardieiro Rodrigues (Desenvolvedor)
13. Luthuli Akanni Paixao (Estagiario em ESOF)
14. Fábio Donisete Silva (Desenvolvedor)
15. Saulo Garcez Santos (Desenvolvedor)

• Rafaella Picolo Garcia (Desenvolvedora) (Solicitou dispensa)