Elaboração do DAS

[lucasfs1007]

Com a definição da ata do dia 14/06, disponível no link https://unbarqdsw2023-1.github.io/2023.1_G5_ProjetoRiHappy/#/0.planejamento/atas/ata_14_06_2023, foi definida que essas duas duplas estarão responsáveis pela modelagem de padrões de projeto.

Visões do DAS

• [x] Lógico - Lucas Felipe e Josué
• [x] Implementação - Maria Abritta, Josué e João Pedro
• [x] Processo - Lucas Gomes, Luiza e Maria Abritta
• [x] Implantação - Lucas Felipe e Nicolas
• [x] Dados - Lucas Felipe e Nicolas

[lucasfs1007]

Em um primeiro momento, criei os espaços adequados em nosso Pages para armazenar tanto a documentação geral quanto a documentação específica do subgrupo responsável pela reutilização de código. Tomei o cuidado de padronizar nosso documento conforme o formato disponibilizado no template do Moodle.

Inicialmente, decidimos realizar correções e melhorias em tudo que foi modelado até o momento, a fim de possibilitar a seleção dos padrões que iremos utilizar. Aguardamos a reunião prevista para hoje para definirmos as próximas etapas.

[lucasfs1007]

Criei uma branch denominada DAS, onde subi a última versão do diagrama de classes bem qual as visualizações dos pacotes que possuimos nas mesmas até então. Com as devidas revisões e formatções das mesmas teremos uma base da visão lógica

[nszchagas]

Bom dia pessoal!

Ontem antes da reunião a @MariaAbritta estudou dois padrões arquiteturais e fez um resuminho bem bacana pra gente, vou trazer aqui na issue pra podermos discutir sobre o assunto.

---

Padrões arquiteturais

Tipo - Padrão MVC

• O Padrão Arquitetural Modelo-Visão-Controlador (MVC) é um dos padrões mais conhecidos e amplamente utilizados no desenvolvimento de software. Ele tem como objetivo separar as responsabilidades em três componentes principais: Modelo, Visão e Controlador.
  1. Modelo (Model): O Modelo é responsável por representar os dados e a lógica de negócio do sistema. No contexto do RiHappy, o Modelo pode incluir classes que representam os objetos do domínio, como produtos, clientes, pedidos e outros conceitos relevantes para o negócio. Além disso, pode incluir a lógica para acessar, atualizar e manipular esses dados.
  2. Visão (View): A Visão é responsável pela apresentação e interface com o usuário. No projeto RiHappy, a Visão pode ser composta por arquivos HTML, CSS. Esses arquivos e componentes são responsáveis por exibir os dados do Modelo ao usuário final.
  3. Controlador (Controller): O Controlador atua como intermediário entre o Modelo e a Visão. Ele é responsável por receber as entradas do usuário, processá-las e atualizar o Modelo ou a Visão conforme necessário. No contexto do RiHappy, o Controlador pode ser implementado usando JavaScript, por exemplo, para lidar com eventos do usuário, como cliques em botões, envio de formulários, etc., e acionar as ações adequadas no Modelo e na Visão.

To-do:

1. Identificar as funcionalidades relacionadas ao Modelo, à Visão e ao Controlador no código existente. a. Documentar e entender as responsabilidades atuais de cada componente.

2. Organizar o código: a. Criar uma estrutura de diretórios para separar claramente as camadas do MVC.

3. Implementar o Modelo: a. Identificar as classes e componentes que representam os objetos de negócio. b. Implementar as classes do Modelo com as regras e lógica de negócio adequadas. c. Testar e validar o funcionamento correto do Modelo.

4. Desenvolver a Visão: a. Criar arquivos HTML, CSS e outros recursos necessários para a interface do usuário. b. Exibir os dados do Modelo na Visão. c. Implementar a interação do usuário com a Visão.

5. Implementar o Controlador: a. Identificar as interações do usuário que requerem ações no Modelo e na Visão. b. Implementar a lógica de fluxo do sistema e as funções de manipulação de eventos. c. Conectar o Controlador ao Modelo e à Visão.

6. Estabelecer as conexões entre os componentes: a. Definir mecanismos para que o Controlador acesse e atualize o Modelo. b. Implementar a atualização da Visão em resposta às mudanças no Modelo. c. Verificar se as interações entre os componentes estão corretas e funcionais.

7. Testar os componentes individualmente: a. Desenvolver testes unitários para o Modelo, a Visão e o Controlador. b. Verificar se cada componente funciona corretamente e atende às expectativas.

8. Testar o sistema como um todo: a. Realizar testes de integração para verificar a interação correta entre os componentes. b. Testar o fluxo de dados e a atualização da Visão em resposta às mudanças do Modelo.

9. Garantir a testabilidade contínua: a. Implementar testes para garantir que as alterações futuras não quebrem o sistema. b. Manter uma cobertura de testes adequada para todos os componentes.

10. Realizar ajustes e melhorias: a. Identificar possíveis melhorias no código e na arquitetura do sistema. b. Refatorar o código conforme necessário para melhorar sua qualidade e manutenibilidade. c. Iterar sobre as etapas anteriores, se necessário, para aprimorar o padrão MVC.

Tipo - Padrão Arquitetural Pipes and Filters

• O Padrão Arquitetural Pipes and Filters (Tubos e Filtros) é um padrão que visa separar e combinar componentes independentes para processar e transformar dados. Ele consiste em uma sequência de etapas (filtros) conectadas por canais (tubos), onde os dados fluem de um filtro para o próximo.
  1. Filtros (Filters): Os filtros são componentes independentes responsáveis por processar e transformar os dados. No contexto do RiHappy, esses filtros poderiam ser implementados como funções ou classes que executam operações específicas, como validação de dados, formatação, cálculos, filtragem de resultados do feedback dos brinquedos, entre outros. Cada filtro receberia uma entrada, processaria os dados e produziria uma saída que seria passada para o próximo filtro na sequência.
  2. Tubos (Pipes): Os tubos são canais que conectam os filtros, permitindo o fluxo de dados entre eles. No projeto RiHappy, os tubos podem ser implementados como estruturas ou mecanismos que permitem a passagem dos dados de um filtro para o próximo. Isso pode ser alcançado por meio de invocações diretas entre os filtros, uso de eventos ou até mesmo em estruturas de dados compartilhadas.
  3. Sequência de Etapas: O fluxo de dados ocorre através da sequência de filtros conectados pelos tubos. Cada filtro realiza uma tarefa específica, e os dados fluem sequencialmente, passando de um filtro para o próximo até alcançar a etapa final do processamento.

     ---

A partir dessa leitura podemos elencar alguns pontos positivos e negativos de cada padrão em relação ao nosso projeto, e assim tomar uma decisão sobre qual utilizaremos. Existe também a possibilidade de utilizar elementos dos dois, sem manter uma rigidez de padrão.

Comparativo entre os padrões

	Pontos positivos	Pontos negativos
MVC	- Maior organização das camadas, o que facilita a alta coesão e baixo acoplamento
Pipes & Filters	- Padronização do fluxo de dados (dados de avaliação, cálculos e inserção no banco)

[lucasfs1007]

Estou sob uma etapa de revisão do diagrama de classes em conjunto com o @zjosuez, acreditamos que na atual modelagem será necessário fazer pequenas alterações quanto a nossa model e nossa controller apenas. Mas, mesmo com essas alterações não estamos caminhando em um caminho diferente do padrão MVC

[zjosuez]

Com o intuito de revisar e melhorar o diagrama de classes para a implementação do DAS, foram feitas algumas alterações, principalmente na view. Uma das principais modificações foi na classe "Listagem", que agora recebe o "EventManager" como atributo. Além disso, o método de 'atualizar' foi removido das classes de listagem, uma vez que as classes observadas não precisam atualizar nada, mas sim adicionar um evento para a classe "EventManager".

Os métodos da classe "EventManager" estavam listados como métodos privados, o que não fazia muito sentido. Portanto, alterei todos os métodos da classe para públicos.

[lucasfs1007]

No momento sigo com as últimas revisões e modificações acerca do diagrama de classes para que possa ser feita uma documentação oficial da visão lógica. Ademais, pretendo trazer um pouco da óptica do diagrama de pacotes que já foi implementado em um momento anterior para reforçar ainda mais esse tipo de visão.

[MariaAbritta]

Com a conversa com a professora em sala, acho que DEVEMOS falar sobre cliente-servidor, já que é uma base de granularidade alta que podemos ir afunilando com outro tipo de PA (Padrão Arquitetural) Vou começar a escrever certas coisas interessantes de acordo com os slides dela no aprender 3 Como eu disse em sala, as coisas ainda estão muito abstratas mas acho que seria muito legal a gente começar daí!

[MariaAbritta]

Bom dia pessoal!

Ontem antes da reunião a @MariaAbritta estudou dois padrões arquiteturais e fez um resuminho bem bacana pra gente, vou trazer aqui na issue pra podermos discutir sobre o assunto.

Padrões arquiteturais

Tipo - Padrão MVC

• O Padrão Arquitetural Modelo-Visão-Controlador (MVC) é um dos padrões mais conhecidos e amplamente utilizados no desenvolvimento de software. Ele tem como objetivo separar as responsabilidades em três componentes principais: Modelo, Visão e Controlador.

  1. Modelo (Model): O Modelo é responsável por representar os dados e a lógica de negócio do sistema. No contexto do RiHappy, o Modelo pode incluir classes que representam os objetos do domínio, como produtos, clientes, pedidos e outros conceitos relevantes para o negócio. Além disso, pode incluir a lógica para acessar, atualizar e manipular esses dados.
  2. Visão (View): A Visão é responsável pela apresentação e interface com o usuário. No projeto RiHappy, a Visão pode ser composta por arquivos HTML, CSS. Esses arquivos e componentes são responsáveis por exibir os dados do Modelo ao usuário final.
  3. Controlador (Controller): O Controlador atua como intermediário entre o Modelo e a Visão. Ele é responsável por receber as entradas do usuário, processá-las e atualizar o Modelo ou a Visão conforme necessário. No contexto do RiHappy, o Controlador pode ser implementado usando JavaScript, por exemplo, para lidar com eventos do usuário, como cliques em botões, envio de formulários, etc., e acionar as ações adequadas no Modelo e na Visão.

To-do:

1. Identificar as funcionalidades relacionadas ao Modelo, à Visão e ao Controlador no código existente. a. Documentar e entender as responsabilidades atuais de cada componente.
2. Organizar o código: a. Criar uma estrutura de diretórios para separar claramente as camadas do MVC.
3. Implementar o Modelo: a. Identificar as classes e componentes que representam os objetos de negócio. b. Implementar as classes do Modelo com as regras e lógica de negócio adequadas. c. Testar e validar o funcionamento correto do Modelo.
4. Desenvolver a Visão: a. Criar arquivos HTML, CSS e outros recursos necessários para a interface do usuário. b. Exibir os dados do Modelo na Visão. c. Implementar a interação do usuário com a Visão.
5. Implementar o Controlador: a. Identificar as interações do usuário que requerem ações no Modelo e na Visão. b. Implementar a lógica de fluxo do sistema e as funções de manipulação de eventos. c. Conectar o Controlador ao Modelo e à Visão.
6. Estabelecer as conexões entre os componentes: a. Definir mecanismos para que o Controlador acesse e atualize o Modelo. b. Implementar a atualização da Visão em resposta às mudanças no Modelo. c. Verificar se as interações entre os componentes estão corretas e funcionais.
7. Testar os componentes individualmente: a. Desenvolver testes unitários para o Modelo, a Visão e o Controlador. b. Verificar se cada componente funciona corretamente e atende às expectativas.
8. Testar o sistema como um todo: a. Realizar testes de integração para verificar a interação correta entre os componentes. b. Testar o fluxo de dados e a atualização da Visão em resposta às mudanças do Modelo.
9. Garantir a testabilidade contínua: a. Implementar testes para garantir que as alterações futuras não quebrem o sistema. b. Manter uma cobertura de testes adequada para todos os componentes.
10. Realizar ajustes e melhorias: a. Identificar possíveis melhorias no código e na arquitetura do sistema. b. Refatorar o código conforme necessário para melhorar sua qualidade e manutenibilidade. c. Iterar sobre as etapas anteriores, se necessário, para aprimorar o padrão MVC.

Tipo - Padrão Arquitetural Pipes and Filters

• O Padrão Arquitetural Pipes and Filters (Tubos e Filtros) é um padrão que visa separar e combinar componentes independentes para processar e transformar dados. Ele consiste em uma sequência de etapas (filtros) conectadas por canais (tubos), onde os dados fluem de um filtro para o próximo.

  1. Filtros (Filters): Os filtros são componentes independentes responsáveis por processar e transformar os dados. No contexto do RiHappy, esses filtros poderiam ser implementados como funções ou classes que executam operações específicas, como validação de dados, formatação, cálculos, filtragem de resultados do feedback dos brinquedos, entre outros. Cada filtro receberia uma entrada, processaria os dados e produziria uma saída que seria passada para o próximo filtro na sequência.
  2. Tubos (Pipes): Os tubos são canais que conectam os filtros, permitindo o fluxo de dados entre eles. No projeto RiHappy, os tubos podem ser implementados como estruturas ou mecanismos que permitem a passagem dos dados de um filtro para o próximo. Isso pode ser alcançado por meio de invocações diretas entre os filtros, uso de eventos ou até mesmo em estruturas de dados compartilhadas.
  3. Sequência de Etapas: O fluxo de dados ocorre através da sequência de filtros conectados pelos tubos. Cada filtro realiza uma tarefa específica, e os dados fluem sequencialmente, passando de um filtro para o próximo até alcançar a etapa final do processamento.

A partir dessa leitura podemos elencar alguns pontos positivos e negativos de cada padrão em relação ao nosso projeto, e assim tomar uma decisão sobre qual utilizaremos. Existe também a possibilidade de utilizar elementos dos dois, sem manter uma rigidez de padrão.

Comparativo entre os padrões

Pontos positivos Pontos negativos MVC - Maior organização das camadas, o que facilita a alta coesão e baixo acoplamento
Pipes & Filters - Padronização do fluxo de dados (dados de avaliação, cálculos e inserção no banco)

Bom dia pessoal!

Meu comparativo entre os padrões

	Pontos positivos	Pontos negativos
MVC	- Maior organização das camadas, o que facilita a alta coesão e baixo acoplamento	- Entendi que pode gerar complexidade adicional quando são projetos muito pequenos, por terem um nível de complexidade menor, pode aumentar a quantidade de código desnecessariamente
	- Dá para reutilizar os códigos - "a separação de responsabilidades proporcionada pelo MVC permite reutilizar o código de forma eficiente, pois cada parte do padrão é projetada para desempenhar funções específicas e independentes"	- Por poder reutilizar os códigos, precisa de um esforço inicial maior para definir a estrutura do MVC de forma mais exata e sem erros possível, pois se não vira uma "Bola de neve"
Pipes & Filters	- Padronização do fluxo de dados (dados de avaliação, cálculos e inserção no banco)	- Dependendo, pode ser difícil de entender e de fazer a manutenção em pipelines muito complexos. Pipeline - "Uma sequência de etapas (filtros) conectadas, onde cada etapa processa os dados de entrada e os encaminha para a próxima etapa.". Com isso, vejo uns problemas de dependência de muitas coisas em um único pipeline, na nossa parte de feedback, em filtragem
	- Pelo que vi, da para fazer a "composição modular de funcionalidades", significa que da para ter diferentes funcionalidades combinadas de uma forma flexível para ter um sistema mais complexo/completo. Ao que eu entendi, da para reutilizar códigos, ter uma manutenções/melhorias simplificadas e por isso tem uma flexibilidade maior	?

[lucasfs1007]

Após a finalização da aula de hoje, foi feito uma conversa com a professora acerca do escopo da entrega. Com isso, verificamos que além dos diagramas de classes e pacotes podemos também trazer um pouco de outras modelagens em mais alto nível para contemplarmos mais a fundo a visão lógica. Ademais, reforço a enorme participação do @zjosuez na confecção do artefato apesar do maior número de commits na mesma estar sob minha autoria

[lucasfs1007]

Dando início as modelagens de diagramas de relacionamento, o que nos diz respeito as visões de implantação ou dados. criei uma base bem crua para que possamos começar a pensar em como se darão esses relacionamentos. Essas entidades criadas foram muito inspiradas no componente de models, modelado em nosso diagrama de classes. tal diagrama está disponível no seguinte link: https://lucid.app/lucidchart/1085c101-b1bd-406c-abe2-46743b521dbb/edit?viewport_loc=-849%2C-536%2C3330%2C1437%2C0_0&invitationId=inv_2423b561-f425-4665-aa59-0eda39831e76

[luiza-esteves]

Estou estudando sobre a visão arquitetural de processo e vou deixar o link do resumo que montei disponível https://docs.google.com/document/d/1VybnocUZFljuD_gCF2j8gb3dA9jAldfsSPARjM2smnY/edit?usp=sharing

[luiza-esteves]

Estou estudando sobre a visão arquitetural de processo e vou deixar o link do resumo que montei disponível https://docs.google.com/document/d/1VybnocUZFljuD_gCF2j8gb3dA9jAldfsSPARjM2smnY/edit?usp=sharing

Acredito ser interessante revisarmos o diagrama de atividades já elaborado e elaborar o de sequência

[lucasgcaldas]

Pessoal, completei o estudo da Luiza acima com uma visão geral sobre a parte de Processos.

Em resumo, dentro das visões do “Modelo de Visão 4+1” da arquitetura de software, a Visão de Processo concentra-se na alocação de processos ou threads em um sistema distribuído, mostrando como os componentes do sistema são mapeados para os recursos de hardware disponíveis, abordando questões relacionadas ao desempenho, à escalabilidade e à distribuição dos componentes.

[lucasgcaldas]

Acredito que essa parte de visão de processo remete muito aos conhecimentos adquiridos em FSO, pra gente não sobrecarregar o sistema, é interessante modelar como ficam os processos, quando é necessário utilizar threads, principalmente em sites que possuem diversos acessos ao mesmo tempo.

[nszchagas]

@lucasgcaldas e @luiza-esteves um possível gargalo de threads na nossa aplicação é a questão do acesso de dados, o singleton que foi implementado visa resolver esse problema, e uma possibilidade para a modelagem de processos seria incluir essa parte do sistema na modelagem, para demonstrar como o singleton pode contibuir para a solução, demonstrando que para cada thread criada haverá apenas uma instância da classe conectora com o banco de dados, evitando um gigantesco número de instâncias, que seriam criadas para cada conexão, sem o singleton.

[nszchagas]

@lucasfs1007 fiz alguns ajustes no DER, nesse tipo de diagrama não é possível ter um relacionamento com mais do que uma entidade, além desse ajuste coloquei a direção dos relacionamentos e um nome mais significativo, para nos ajudar na análise das cardinalidades. A partir desse ponto acho melhor utilizarmos uma ferramenta própria para esse tipo de diagramas, o brmodelo, por ele será mais fácil inserir os atributos e indicar chaves primárias.

[luiza-esteves]

@lucasgcaldas e @MariaAbritta criei um documento para iniciarmos o diagrama de sequência que faz parte da visão arquitetural de processo que ficamos responsáveis

Link do diagrama: https://lucid.app/lucidchart/8c097791-e017-436d-acdb-6dcaba1ee345/edit?view_items=PuB-ygDifPys&invitationId=inv_085d5737-e8fe-4585-a16f-025a59a959ed

[nszchagas]

Visão de Dados finalizada, se alguém quiser dar uma olhada as alterações estão no PR #88

[lucasfs1007]

Visão de Dados finalizada, se alguém quiser dar uma olhada as alterações estão no PR #88

Por sinal, optamos também por fazer a modelagem da visão de implantação para que possamos trazer uma riqueza ainda maior quanto todas as visões

[nszchagas]

Diagrama de implantação em baixa fidelidade.

[zjosuez]

Iniciei a parte do diagrama de componentes para começar a criação da visão de implementação. Link do diagrama

[lucasgcaldas]

boa noite, pessoal. A @luiza-esteves e eu finalizamos a primeira versão do diagrama de sequencia. Por favor, verifiquem se está tudo ok para que possamos melhorar.

[pedroblome]

Dei continuidade no diagrama de componentes que o Josue tinha criado, link para diagrama: link

[zjosuez]

A seguir se encontra a atual versão final do diagrama de componentes. Foi modelado os relacionamenos e as dependências entre os componentes e também as portas referênte a cada componente no diagrama. Também foi adicionado mais um subsistema pai chamado sistema de pagamento

[MariaAbritta]

Finalizei o documento de implementação, mesclando o que eu tinha feito com o que o João Pedro já tinha feito, dando mais ênfase nas explicações dos componentes criados no diagrama que o Josué criou.