Sistema Gerenciador de Bibliotecas

Este sistema é resultado de um trabalho prático aplicado na disciplina de Arquitetura de Softwares. A disciplina faz parte da grade curricular do curso de Ciência da Computação, do Centro de Universitário de Belo Horizonte, lecionada pelo professor Flávio Henrique Batista de Souza.

1. Detalhes do planejamento

Para este trabalho optamos por usar o próprio sistema de Projetos do GitHub.

2. Contribuindo com o projeto

Se você faz parte do time de desenvolvimento, comece lendo a Wiki. Se você já está familiarizado com o Git e GitHub, nem precisa ler as páginas sobre ambos. Pode só configurar o projeto.

2. Sobre o trabalho

2.1. Regras

1. Cada grupo deve ser composto de no máximo 5 pessoas. O grupo deve possuir apenas 1 (um) Arquiteto de Software.
2. O grupo pode escolher ou criar um projeto do zero, ou escolher um projeto já existente. O tema é livre.
3. Todos os padrões ensinados na disciplina são válidos (Padrões GoF, MVC, MVVC, Dependency Injection, etc.).

2.2. Forma de apresentação

1. O Arquiteto deve se apresentar, descrever a aplicação, sua funcionalidade, o tipo de dados que são tratados e os resultados que o software gerencia.
2. Em uma análise via diagramas, devem demonstrar os pontos em que o Arquiteto identificou a demanda de adequação a um dos padrões disponíveis. Neste momento, o Arquiteto deve demonstrar:

• A demanda identificada;
• O padrão que ele identifica como plausível para otimização;
• Explicar o padrão usado com base na teoria;
• O membro da equipe que foi designado para otimização (explique: data, horário, prazo estipulado);
• O que o Arquiteto espera obter de otimização ou padronização com o processo;

3. Devem ser identificados pelo menos 8 otimizações/adequações baseadas em padrões. Cada elemento do grupo deve implementar pelo menos duas.
4. Cada membro precisa ser completamente capaz de explicar suas implementações. Isso incluir dizer quais padrões implementou, quais os ganhos desses padrões e quais os custos identificados.

3. Observações

3.1. Os padrões podem ter uma implementação mais simplista

Como o projeto é pequeno e o seu maior intuito é permitir que o grupo inteiro aprenda mais sobre Design Patterns, as implementações podem não ser completamente fiéis ou até mesmo não serem as mais ideais para cada problema. Para melhorar o aprendizado da equipe, primeiro fizemos as implementações com vários bad smells. Os padrões foram implementados em seguida.

Usamos esse raciocínio porque antes de entender uma solução, o seu time precisa viver o problema. Sentir na pele. Só então as soluções passam a fazer sentido.

4. Resultado final

4.1. Nota final

O trabalho recebeu nota máxima, 20 pontos. Um agradecimento especial aos desenvolvedores envolvidos, Jefferson Gomes, Marcos e Paulo Trindade. Dedicaram-se à aprender os padrões e deram o seu melhor. 🌟

4.2. Sobre o histórico do desenvolvimento

Caso tenha interesse em visualizar o histórico do desenvolvimento, consulte a seção de Issues e Pull Requests. Lembre-se também de checar a aba Closed, pois muitos deles foram fechados após serem finalizados.