Trabalho de Projeto de Software engenharia de Software

1 Escopo do sistema a O sistema compreende um servidor web responsável por receber mensagens encaminhadas por aplicativos terceirizados cabe ao módulo Engine através de configurações registrar plugins que podem enviar as mensagens decidir se a mensagem será encaminhada ao módulo NLU ou ao módulo Atendimento humano Dentro do módulo NLU é possível configurar as mensagens que serão enviadas como respostas às mensagens dos usuários Também é possível para o usuário dentro do módulo NLU solicitar o encaminhamento das mensagens para o módulo Atendimento humano Dentro do módulo Atendimento humano agentes serão designados em filas para realizar os atendimentos solicitados pelos usuários Os atendimentos serão capturados por agentes que podem seguir com o atendimento até a finalização ou transferir o atendimento para outra fila ou outro agente 2 Requisitos arquiteturais a Modularidade Cada módulo é responsável por suas determinadas funções garantindo manutenibilidade e escalabilidade b Escalabilidade O sistema deve ser capaz de suportar múltiplos usuários enviando mensagens simultaneamente sem perda de performance c Confiabilidade O sistema deve garantir alta disponibilidade 24 horas por dia com tolerância a falhas e capacidade de recuperação automática em caso de estabilidade d Integridade O sistema deve guardar as mensagens enviadas por usuários e agentes para visualização do histórico 3 Padrões arquiteturais a Arquitetura Orientada a Serviços Cada módulo da aplicação é um serviço independente dos demais com funcionalidades específicas e definidas 4 Justificativa a A escolha do padrão de arquitetura orientada a serviços se deu pela modularidade manutenibilidade escalabilidade e a flexibilidade do padrão 5 Diagrama de casos de uso 6 Modelo conceitual 7 Diagramas de sequencia Trabalho Prático O grupo deverá aplicar os conceitos aprendidos na disciplina Projeto de Software em um sistema cujo tema é de livre escolha Esse sistema pode ser o Projeto de Aplicação de algum membro do grupo algum sistema legado do estágio de um dos membros do grupo ou qualquer outro sistema que não tenha documentação de análise e projeto acessível aos membros do grupo A professora deverá ser consultada previamente para analisar o grau de dificuldade e a aderência no escopo da disciplina Projeto de Software O trabalho consiste em durante o decorrer do curso utilizar as técnicas aprendidas para projetar o sistema em questão e produzir os diagramas da fase de projeto para esse sistema Entregas Serão realizadas duas entregas Entrega 1 Peso 50 Documentação parcial da arquitetura conforme os modelos e exemplos anexados a atividade do Google Classroom Este documento deve conter ao menos Descrição do escopo do sistema Descrição dos requisitos arquiteturais objetivos e restrições da arquitetura Definição dos padrões arquiteturais adotados Justificativa das decisões arquiteturais adotadas com base nos atributos de qualidade do sistema Descrição de como a arquitetura de software contribui para os atributos de qualidade importantes do sistema Documentação das visões arquiteturais Ao menos diagramas de casos de usos modelo conceitual e diagramas de sequência do sistema Se o sistema for grande não precisa fazer os DSS dos CRUDs Mínimo 1 DSS por integrante da equipe Diagrama com a visão geral de arquitetura do sistema organização incluindo os estilos arquiteturais utilizados e justificativas de uso Diagramas de interação Pelo menos um diagrama por caso de uso Escolher a operação do DSS mais complexa Obs Descrever o contrato da operação escolhida Mínimo 1 diagrama por integrante da equipe Diagramas de estado ou atividades quando achar necessário Diagramas de classe detalhado Entrega final Peso 5 Documentação final da arquitetura e implementação do sistema A documentação da arquitetura deve ser evoluída considerando Deve ser descrito como os princípios SOLID e padrões GRASP foram seguidos Para tanto devem ser usados exemplos de elementos de modelo que foram refatorados devido à identificação de violações desses princípios Devem ser adotados pelo menos um padrão GoF para cada membro do grupo Considere a evolução do seu projeto para uma LPS Projete o modelo de características listando as características mandatórias opcionais e alternativas Código do sistema Não é necessário implementar todas as funcionalidades do sistema O requisito mínimo exigido é a implementação das interfaces dos principais elementos arquiteturais além dos seguintes casos de uso i um cadastro CRUD por membro da equipe ii dois casos de uso que descrevem funcionalidades transacionais e iii um caso de uso relativo a uma listagem do sistema relatório Implemente o seu sistema observando os seguintes aspectos e tendo as seguintes diretivas em mente Obedeça aos princípios de projeto OO apresentados no curso ou justifique caso seja necessário relaxar algum princípio Identifique os domínios a que pertencem às classes do sistema e evite classes mistas Procure desenvolver seu sistema prevendo possíveis extensões e mudanças Explique os mecanismos arquiteturais que estão sendo utilizados para este fim Desenvolva uma interface gráfica simples para o sistema cuidando para não haver acoplamento com o domínio do negócio Implemente a persistência do sistema usando JDBC ou um framework de persistência como Hibernate JPA ou qualquer outro equivalente Em caso de uso de JDBC utilize um padrão apropriado para lidar com acesso aos dados na base de dados Opcional Se usar outra tecnologia explicite os padrãoões de projeto que estáão sendo usados para acesso a dados OU implemente o backend do seu sistema usando um framework OO Todos os artefatos deverão ser entregues no repositório httpsclassroomgithubcomaQH9z7FhU A entrega no Google Classroom deverá ser realizada por apenas um integrante do grupo que informará apenas o link do repositório do grupo Documentos de texto devem ser elaborados no Google Docs com todos os membros logados em suas contas de forma que seja possível visualizar a colaboração individual de cada integrante Os links para esses documentos devem estar disponíveis no arquivo README do repositório Avaliação Para solução serão avaliados o uso adequado dos conceitos de Projeto de Software a Artefatos produzidos com base na sua completude corretude e capacidade de argumentação em relação às decisões tomadas b Resultados e colaboração individual no trabalho Serão considerados participação em sala no desenvolvimento do trabalho colaboração no GitHub e descrição das responsabilidades do aluno c Apresentação e corretude das respostas individuas durante a apresentação final do trabalho Regras O trabalho deve ser feito em grupos de 4 pessoas As responsabilidades de cada aluno deve ser documentada e registrada a Todos os alunos devem apresentar o trabalho final no prazo definido O não cumprimento do prazo invalida o trabalho Alunos que não participarem da apresentação ficarão sem nota do trabalho Cronograma a Formação dos grupos e definição do tema 05042024 b Entrega 1 19052025 c Entrega e apresentação final do trabalho07072025 Considerações a Os membros da equipe serão avaliados pelo resultado final e pelos resultados individuais alcançados Assim numa mesma equipe um membro pode ficar com nota 90 e outro com nota 50 por exemplo b Será considerado o nível de dificuldade do projeto na composição da nota final Importante consultar a professora para adequação