efrei m1 jakartaee projet
1.0.0
O torneio Rolland Garos é um torneio internacional de tênis.
Desenvolva uma gestão da Web de partidas no torneio Rolland Garos.
Papel funcional do projeto O aplicativo deve possibilitar planejar as correspondências e planejar de quais jogadores participarão, nos quais o árbitro o supervisionará. Em seguida, você deve poder informar os resultados da partida (as pontuações de cada equipe). Os visitantes devem poder consultar os resultados das partidas acabadas.
Ao realizar nosso projeto, fizemos várias suposições sobre a operação que imaginamos para nossa aplicação e, a fim de garantir a consistência deste último:
Hipótese 1:
Um organizador se define se as partidas duplas forem femininas, femininas ou mistas quando ele marcou os jogadores em uma partida. Ou seja, se ele marcou em uma partida dupla de um homem e uma mulher no mesmo time, a partida será misturada. Para correspondências simples, não é possível que um homem enfrente uma mulher, mas ele não é proibido por duplas que uma equipe de dois homens enfrente uma equipe de duas mulheres.
Hipótese 2:
Temos apenas um aplicativo para jornalistas e organizadores e não duas aplicações separadas. Portanto, temos uma página inicial e uma página que permite ver as correspondências terminadas e as outras ações (como adicionar jogadores, correspondências de planejamento etc.) são acessíveis apenas após uma conexão (para saber mais sobre a segurança usada, consulte a parte de segurança do relatório).
Hipótese 3:
Nossa hipótese foi de que as partidas poderiam durar no máximo 4 horas. Adicionamos um recurso que verifica se um curso é gratuito antes de podermos selecioná -lo para uma nova correspondência. Portanto, podemos garantir que dois jogos diferentes não possam ser jogados ao mesmo tempo no mesmo curso. A duração máxima de 4 horas nos permite colocar um limite para poder selecionar um curso, mesmo que uma correspondência seja planejada, mas ainda não terminou 4 horas antes do início da nova partida.
Para realizar este projeto, nos organizamos usando o método ágil.
No início do projeto, escrevemos contas de usuário do seguinte aplicativo:
Isso corresponde ao seguinte diagrama de casos de uso:
Em seguida, dividimos essas histórias de usuário em tarefas de desenvolvimento.
Cada sessão correspondia a um sprint: fizemos uma reunião no início da sessão para determinar quais tarefas deveriam fazer parte do projeto. Para facilitar a tarefa, usamos as ferramentas de gerenciamento de projetos integradas ao Github: os pontos de venda, o suéter de solicitação e a tabela Kanban.
As tarefas foram representadas pelo resultado, que pode ser atribuído a um colaborador. O progresso das tarefas foi seguido por ter os pontos de venda na mesa Kanban. Quando um funcionário terminou uma tarefa, eles criaram um suéter de solicitação associado e o enviaram para uma revisão do código.
O fluxo de trabalho foi o seguinte:
JSTL: Um componente da plataforma JEE para estender a especificação JSP adicionando uma biblioteca de beacons para tarefas atuais, como trabalho em liberdade condicional, loops e internacionalização.
MariaDB : Implémentation Open Source du Système de Gestion de
Base de Données Relationnel MySQL.
JAKARTAEE: Especificação de código aberto de Java EE. Usamos o JSP em particular, os recipientes de servlet, o EJB e o JPA.
Bootstrap est un framework CSS permettant de facilement implémenter des styles
prédéfinis
Wildfly (anteriormente JBoss) é um servidor de aplicativos de código aberto que implementa a especificação Java EE / Jakarta EE.
EJB / Enterprise JavaBeans est une API de composants logiciels coté serveur
permettant d’encapsuler la logique métier des applications d’entreprise.
JPA (especificação) / hibernato (implementação) é um ORM que permite serializar e dearializar objetos Java (entidade EJB) em um sistema de gerenciamento de banco de dados relacional.
Utilizamos a arquitetura de “arquitetura limpa” tão chamada também chamada de arquitetura “cebola”, composta de diferentes camadas, dissociada entre si por contratos de serviço descritos pelas interfaces. Quando uma solicitação chega, ele é processado pela primeira vez pelo controlador, para criar objetos a partir dos dados, ele passa pela camada de serviço que contém a lógica de negócios. A camada de serviço exige a camada restante que contém interações com o banco de dados. A camada restante usa as classes das entidades do modelo de dados.
Em nosso aplicativo nosso, cada camada corresponde aos seguintes componentes:
Utilizamos a programação da interface, bem como o mecanismo de injeção de dependências permitido pelas empresas Java Beans, a fim de ter um baixo acoplamento entre os componentes do aplicativo.
Tivemos cuidado para não armazenar senhas de usuário em Clear no banco de dados. Assim, se este fosse invadido, os atacantes não teriam acesso a senhas. Optamos para cortar senhas com o algoritmo de hash salgado BCRYPT, porque é o padrão no assunto. Para fazer isso, importamos a biblioteca JBCrypt em nosso projeto (via Maven), que implementa o algoritmo em Java.
No aplicativo, a maioria das estradas deve estar acessível apenas por um usuário autenticado. Portanto, configuramos uma página de autenticação para autenticar o usuário. Usamos a sessão HTTP para armazenar o perfil de usuário autenticado.
Para permitir que um usuário nas estradas protegidas, configuramos um filtro HTTP de autorização, que verifica se a sessão HTTP atual contém um perfil de usuário autenticado. Nesse caso, o filtro permite o usuário, caso contrário, ele o redireciona para a página de conexão.
Iniciamos a implementação do projeto criando as classes de negócios (entidades do nosso pacote de projetos), pois as definimos durante a modelagem. Em seguida, criamos as classes e as interfaces, permitindo acessar o banco de dados (pacotes Restitários). Por fim, implementamos a possibilidade de identificar com nosso aplicativo juntos, a fim de concordar com certos acordos para manter nosso projeto coerente. Depois que essas etapas foram concluídas, dividimos o trabalho, dando a todos um certo número de histórias de usuários, o trabalho foi feito até que todas as histórias de usuários sejam realizadas.
A maioria das histórias de usuários foi feita facilmente, exceto a história do usuário: prepare uma correspondência. Durante nossa modelagem inicial de aplicativos, representamos mal os links de “muitos a muitos” conectando os jogadores às partidas, não somos fascinados por uma classe representando as equipes (aulas de participação em nosso projeto). Então, quando tentamos adicionar jogadores aos jogos durante a fase de preparação, foi lançada uma exceção e a preparação da partida não foi feita. Depois de procurar mais detalhes o funcionamento dos relacionamentos "muitos para muitos", percebemos que era impossível fazer dois relacionamentos desse tipo entre as mesmas duas classes (aqui dois relacionamentos conectando os jogadores aos jogos, porque sempre há duas equipes) sem passar por uma classe intermediária (aqui participação) para poder associar adequadamente os jogadores à fósforos. Portanto, tivemos que modificar nosso diagrama de classes para poder modelar adequadamente nossa nova implementação, além de modificar as classes de negócios da partida e dos jogadores e adicionar a aula de participação para fazer com que nosso aplicativo funcione perfeitamente.
A segunda dificuldade encontrada não dizia respeito a uma história do usuário em particular, mas um problema de codificação de dados. Depois de terminar todas as nossas histórias de usuários, durante nossos vários testes e durante nossas melhorias, notamos que os sotaques, normalmente suportados pelo UTF8, não eram devidamente armazenados no banco de dados. De fato, todos os caracteres de destaque na base foram substituídos em outro formato. Depois de olhar para a Internet, entendemos que o problema veio de Wildfly e, para resolvê -lo, simplesmente tivemos que alterar a codificação do contêiner de servlet na configuração Wildfly. Para fazer isso, apenas tivemos que ir à configuração Wildfly e modificar as configurações de codificação padrão do contêiner do servlet pelo UTF-8.
Também encontramos problemas com o gerenciamento do formato das datas. Usamos a LocalDate Type (API de data mais recente em Java) em nossa classe executiva, para armazenar a data programada de uma correspondência, por exemplo. Agora, o JSTL não tem uma função para formatar esse tipo de datas, porque ainda usa a antiga API de data java. Portanto, tivemos que realizar uma formatação manual nas páginas JSP que exibiam datas (você pode ver essa formatação na página consultMatches.jsp, por exemplo).
Depois que essas dificuldades foram superadas, fomos capazes de focar em melhorar nossa aplicação e ajustar pequenos bugs.
Durante este projeto, fomos apresentados ao desenvolvimento de aplicativos de negócios com Jacarta EE. Embora alguns deles já tivessem experiência no servidor no lado do servidor, este projeto foi para a ocasião para nos apropriar dos padrões de desenvolvimento da plataforma
Conseguimos criar habilidades na tecnologia ORM JPA, que oferece uma API muito rica é poderosa. Certos mecanismos, como os "muitos para muitos", nos deram dificuldades, mas temos que superá -los.
Finalmente, o aspecto colaborativo deste projeto é um de seus pontos fortes. De fato, a motivação mútua é um mecanismo poderoso que permite superar qualquer tipo de dificuldade. Isso também nos deu a oportunidade de aplicar habilidades ágeis de gerenciamento de projetos adquiridas em outros módulos, a fim de colaborar da maneira mais eficiente possível.
