Merge pull request #139 from UnBArqDsw2023-2/modificacoes-finais

Modificacoes finais

docs/Entregas/Tres/Interna.md

@@ -18,7 +18,7 @@ software](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Doi
 a ser desenvolvido com base na etapa anterior, e assim, desenvolveu o software
 da disciplina utilizando padrões de projeto e uma [arquitetura
 MVC](https://github.com/UnBArqDsw2023-2/2023.2_G1_ProjetoAmazon/blob/main/docs/ArquiteturaReutilizacao/reutilizacao/Arquitetura.md).
-Assim, este documento sumariza todos esses processos. 
+Assim, este documento sumariza todos esses processos.
 
 ## Processo
 
@@ -53,7 +53,7 @@ no qual foi
 [validado](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Um/EntrevistaValidacao.html)
 dias após.
 
-### Modelagem
+## Padrões de Projeto
 
 Na segunda entrega, foi desenvolvido duas classes de diagramas, os
 estáticos(classes, pacotes, componentes e implantação) e os
@@ -66,45 +66,51 @@ Dando um enfoque maior no
 [diagrama de classes](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Dois/DiagramaDeClasses/DiagramaDeClasses.html),
 podemos listar alguns casos de possíveis reutilizações do software.
 
-1 - Proxy: na imagem 1, podemos ver que a classe carrinho tem uma relação
-simples com uma conta de usuário,sendo assim , para a aplicação é importante
-que o usuário só tenha acesso a este recurso caso ele esteja autenticado no
-sistema, caso não, ele deve ser barrado ao tentar acessar este recurso, assim,
-o padrão de projeto proxy é o ideal para esta situação.
+### 1 - **Proxy**: 
+
+No diagrama 1 podemos observar a implementação de um Proxy que
+checa se o usuário está autenticado antes de realizar qualquer operação. Isso é
+importante para garantir que somente usuários autenticados possam fazer
+operações que modificam o carrinho, já que não existe carrinho que não é
+associado a um usuário já existente.
+
+<center>
+    <img src="assets/Proxy.png"/>
+    <p> Diagrama 1 (Fonte: Autor, 2023).</p>
+</center>
+
+### 1.1- Implementação **Proxy**: 
+A implementação desse padrão está evidenciada na imagem 1:
 
 <center>
-    <img src="assets/proxy.PNG"/>
+    <img src="assets/proxy-example.png"/>
     <p> Imagem 1 (Fonte: Autor, 2023).</p>
 </center>
 
-2 - Strategy: na imagem 2, pode-se encontrar a classe concreta pagamento e 3
-classes que herdam dela: pix, boleto e cartão. No contexto da aplicação, é
+O proxy faz o controle de acesso por meio do método `has_acess`, e possui uma
+instância da classe concreta `CartService`. Ambas implementam o protocol
+`CartServiceProtocol`.
+
+### 2 - **Strategy**: 
+No diagrama 2, pode-se encontrar a classe concreta pagamento e 3
+classes que herdam dela: pix, boleto ou outras. No contexto da aplicação, é
 importante que o usuário autenticado possa escolher qual o método de pagamento
 que ele irá utilizar para obter o produto, sendo assim, o padrão strategy se
 encaixa nessa situação.
 
 <center>
     <img src="assets/strategy.png"/>
-    <p> Imagem 2 (Fonte: Autor, 2023).</p>
+    <p> Diagrama 2 (Fonte: Autor, 2023).</p>
 </center>
 
-Vale lembrar que durante o diagrama de classes podemos encontrar exemplos de
-GRASPs como polimorfismo afim de garantir um baixo acoplamento e alta coesão.
-Um exemplo claro já foi descrito na imagem 1 que é o de uma herança das classes
-pix, boleto e cartão com a classe pagamento.
-
-### Padrões de Projeto
-
-Por fim, os padrões de projeto são uma concretização da reutilização de
-software. A seguir, podemos ver como foram implementadas os padrões de projeto
-descritos na seção anterior deste documento:
-
-1- Strategy: No momento da produção deste artefato, o padrão ainda não está
-totalmente concluido. A implementação desse padrão está evidenciada na imagem 3:
+### 2.2- Implementação **Strategy**: 
+A implementação do padrão Strategy está descrita na imagem 2.
+Esse padrão permite o alto desacoplamento da funcionalidade relacionada ao
+pagamento utilizando diversos métodos de pagamento diferentes.
 
 <center>
-    <img src="assets/strategyExample.png"/>
-    <p> Imagem 3 (Fonte: Autor, 2023).</p>
+    <img src="assets/strategy-example.png"/>
+    <p> Imagem 2 (Fonte: Autor, 2023).</p>
 </center>
 
 Como em python não temos explicitamente classes abstratas ou interfaces, a
@@ -120,20 +126,82 @@ permite que um serviço opere usando somente a noção abstrata de um método de
 pagamento, mas ainda assim conseguindo acessar seus respectivos dados. Isso é
 útil em situações onde não é preciso saber o método de pagamento específico.
 
-2- Proxy: A implementação desse padrão está evidenciada na imagem 4:
+Vale lembrar que durante o diagrama de classes podemos encontrar exemplos de
+GRASPs como polimorfismo afim de garantir um baixo acoplamento e alta coesão.
+Um exemplo claro já foi descrito na imagem 2 que é o de uma herança das classes
+pix, boleto e outras com a classe pagamento.
+
+
+## Considerações finais
+
+A implementação dos padrões de projeto Proxy e Strategy, aplicados ao escopo da disciplina, pode ser conferida no [repositório da disciplina](https://github.com/UnBArqDsw2023-2/2023.2_G1_ProjetoAmazon/tree/main/src). 
+
+### Modelagem e Reutilização
 
+**[Proxy](#padrões-de-projeto)**: Foi implementado um Proxy para verificar a autenticação do usuário antes de permitir operações no carrinho. Isso garante que apenas usuários autenticados possam modificar o carrinho.
+
+**[Strategy](#padrões-de-projeto)**: A implementação do padrão Strategy foi evidenciada no contexto de métodos de pagamento. A classe concreta de pagamento permitiu a criação de subclasses como PIX, boleto, entre outras, proporcionando flexibilidade na escolha do método de pagamento.
+
+**Flyweight, Builder, Observer (Não Implementados dentro do projeto)**: Reconhecemos a oportunidade de explorar os padrões Flyweight, Builder e Observer para aprimorar a arquitetura do software. No contexto do perfil do comprador na Amazon, esses padrões poderiam ser aplicados da seguinte forma:
+
+- `Flyweight`: Neste padrão de projeto, temos como objetivo colocar mais objetos na quantidade de RAM disponível ao compartilhar partes comuns de estado entre múltiplos objetos ao invés de manter todos os dados em cada objeto. Neste caso, fizemos uma simplificação da classe endereço que estava contida dentro da classe contaDoUsuario, nele nos abstraimosa classe pesada e deixamos apenas atributos essenciais, ja na classe EnderecoCompleto temos atributos que são derivados daqueles atributos que estão na classe endereço.
+<details>
+  <summary>Diagrama e Código - Flyweight</summary>
+  <center>
+    <img src="assets/fly_diagram.png"/>
+    <p> Diagrama 4 (Fonte: Autor, 2023).</p>
+</center>
+  <center>
+      <img src="assets/Fly.png"/>
+      <p> Imagem 3 (Fonte: Autor, 2023).</p>
+  </center>
+</details>
+
+
+- `Builder`: Para melhorar a velocidade de criação do usuário, há a necessidade de cria-lo utilizando o padrão builder, tal padrão se utiliza de uma interface que define oe metodos que serão implementados no builder concreto. O builder concreto é justamente a classe UsuarioBuilder, na qual implementa todos os métodos da interface. Alguns métodos notáveis que podemos destacar são :
+
+    - Inicializador: Inicia com um reset e atribuindo um carrinho para o usuário, já que não há a necessidade de um processo maior para a construição do mesmo.
+    - Reset: Realiza a instânciação de um novo usuário.
+    - Get Usuário: retorna o usuário
+    - Demais metodos: implementam lentamente o usuário
+<details>
+  <summary>Diagrama e Código - Builder</summary>
 <center>
-    <img src="assets/proxyExample.PNG"/>
+    <img src="assets/builder_diagram.png"/>
+    <p> Diagrama 4 (Fonte: Autor, 2023).</p>
+</center>
+  <center>
+    <img src="assets/builder.png"/>
     <p> Imagem 4 (Fonte: Autor, 2023).</p>
 </center>
+</details>
+
+
+- `Observer`: O usuário necessita saber a situação do seu pedido, sendo assim, há a necessidade de implementar o padrão observer. No exemplo acima, foi criado uma interface chamada observador, no qual irá observar determinada classe. A classe observada é Pedido no qual tem um método que notifica todas as classes que desejam observa-la, assim, a classe ContaDoUsuario é notificada e atualiza seu status.
+
+<details>
+  <summary>Diagrama e Código - Observer</summary>
+<center>
+    <img src="assets/observer_diagram.png"/>
+    <p> Diagrama 5 (Fonte: Autor, 2023).</p>
+</center>
+  <center>
+    <img src="assets/observer.png"/>
+    <p> Imagem 5 (Fonte: Autor, 2023).</p>
+</center>
+</details>
+
+
+Embora tenhamos aplicado com sucesso os padrões Strategy e Proxy, reconhecemos que outros padrões como Flyweight, Builder e Observer poderiam ser explorados para aprimorar ainda mais a arquitetura do software. 
+
+Além disso, é importante resaltar que foi utilizado módulos prontos do Django, como autenticação, renderização, entre outros, foram utilizados, evidenciando a importância da reutilização de software não apenas a nível de código, mas também de frameworks e bibliotecas.
 
-Na classe de service, temos o método "has_access" no qual verifica se o usuário
-está autenticado, senão, ele retorna uma excessão, se sim, retorna o usuário.
-Na sequência, temos os métodos que atuam como a operação que desejamos guardar.
 
 ## Referências
 ‌
 >[1]  SILVEIRA, Samara. A reutilização de software e suas aplicações. Disponível em: &#60;https://blog.casadodesenvolvedor.com.br/reutilizacao-de-software/&#62;. Acesso em: 29 nov 2023. 
+>[2] PlantUML Web Server. Disponível em: <https://www.plantuml.com>. Acesso em: 1 dez. 2023.
+
 
 ## Histórico de versão
 
@@ -142,3 +210,7 @@ Na sequência, temos os métodos que atuam como a operação que desejamos guard
 | `1.0`  | 29/11/2023 | Iniciando o documento            | Kauã      | Ana         |
 | `1.1`  | 30/11/2023 | Adicionando informações          | Kauã      | Ana         |
 | `1.2`  | 30/11/2023 | Informações sobre especialização | Guilherme | Arthur      |
+| `1.3`  | 01/12/2023 | Alterações no documento          | Kauã e Ana| Beatriz     |
+| `1.4`  | 01/12/2023 | Melhoria dos Diagramas           | Guilherme | Arthur      |
+| `1.5`  | 01/12/2023 | Adição dos padrões e diagramas   | Ana e Kauã| Beatriz     |
+

docs/Entregas/Tres/VisaoLogica.md

@@ -8,7 +8,18 @@ Visão Lógica apresenta a oragnização do software de modo mais estrutural, on
 
 ## Metodologia
 
-Para a confecção da visão lógica da arquitetura, os membros responsáveis decidiram trazer uma visão por meio dos pacotes. Com base no diagrama de pacotes foi elaborado a visão lógica, elucidando pontos que foram consirados importantes na arquitetura de acordo com os autores. Foi utilizado o webapp [Lucidchart](https://www.lucidchart.com/pages/) para a confecção do artefato. Por fim, foi publicado o diagrama para os membros do grupo ficarem cientes do processo.
+Para a confecção da visão lógica da arquitetura, os membros responsáveis decidiram trazer uma visão por meio dos pacotes e Sequência. Com base no diagrama de pacotes e Sequência foi elaborado a visão lógica, elucidando pontos que foram consirados importantes na arquitetura de acordo com os autores. Foi utilizado o webapp [Lucidchart](https://www.lucidchart.com/pages/) para a confecção do artefato. Por fim, foi publicado o diagrama para os membros do grupo ficarem cientes do processo.
+
+## Diagrama de Sequência
+
+O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação.
+
+![Diagrama de Sequência](Diag_De_Sequencia_V2.0.png)
+<center>
+<p> Diagrama de Sequência: Versão 2.0 (Fonte: Autores, 2023).</a></p> 
+</center>
+
+## Diagrama de Pacotes
 
 ### Primeira versão
 
@@ -29,10 +40,11 @@ Segunda versão criada em 30/11/2023.
 </center>
 
 
-
 ## Referências
 
 > [1] SLIDE AULA - Arquitetura e Desenho de Software - Aula Arquitetura e DAS - Parte II. Profa. Milene Serrano . Disponivel em: [aprender3](https://aprender3.unb.br/pluginfile.php/2649469/mod_label/intro/Arquitetura%20e%20Desenho%20de%20Software%20-%20Aula%20Arquitetura%20e%20DAS%20-%20Parte%20II%20-%20Profa.%20Milene.pdf). Acesso em 27 de nov. de 2023.
+>
+> [2] Diagrama de Seqüência. Disponivel em: [profs.ic.uff](http://profs.ic.uff.br/~viviane.silva/es1/util/aula8.pdf). Acesso em 4 de out. de 2023.
 
 
 ## Histórico de versão
@@ -41,4 +53,5 @@ Segunda versão criada em 30/11/2023.
 | :----: | :--------: | :--------------------------------------: | :-----------: | :-----------: |
 | `1.1`  | 28/11/2023 |Criação do documento e adição da imagem inicial |   Samuel Sato  |    Augusto D. Camargo   |
 |`1.2`|30/11/2023|Adição do diagrama mais detalhado, sendo essa a sua versão final|Augusto D. Camargo| Samuel Sato|
+|`1.3`|01/12/2023|Adição do diagrama de Sequencia|Beatriz| Samuel Sato|
 

docs/Entregas/Tres/participacoes.md

@@ -20,6 +20,7 @@ Para a realização do trabalho em grupo foram utilizados os aplicativos Discord
 | [DAS de implementação](                                                   )                                                                               | Ana e Mylena      | Beatriz      |
 | [DAS de processo](                                                        )                                                                               | Beatriz e Gabriel | Mylena e Ana |
 | [Data view](                                                        )                                                                                     | Augusto           | Guilherme    |
+| [DAS Logica](                                                        )                      | Samuel Sato , Augusto, Beatriz  | Augusto, Beatriz,Samuel   |
 
 <div style="text-align: center"> Tabela 1. Contribuição dos membros para a entrega de diagramas estáticos. Fonte: Autores.</div>
 

docs/Entregas/Tres/processos.md

@@ -8,15 +8,17 @@ Essa visão pode abranger os fluxos de trabalho, que representam a ordem lógica
 
 ## Metodologia
 
-Durante a fase de modelagem, nossa equipe desenvolveu tanto o diagrama de sequência quanto o diagrama de atividades. Ao criar a documentação da visão de processos, utilizamos esses diagramas como base, mas fizemos algumas modificações e aprimoramentos para melhor atender às nossas necessidades e proporcionar uma representação mais clara e eficaz.
+Durante a fase de modelagem, nossa equipe desenvolveu tanto o diagrama de sequência quanto o diagrama de atividades. Ao criar a documentação da visão de processos, utilizamos esses diagramas como base.
+
+O **diagrama de processos**, ultimo diagrama do documento, foi feito levando em consideração diagrama de atividades e sequência.
 
 Para a criação dos diagramas, foi utilizado o site [LucidChart](https://www.lucidchart.com/), que é uma ferramenta online para criação de diagramas.
 
 ## Diagramas
 
-### Diagrama de Sequência
+## Diagrama de Sequência
 
-O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação. [4]
+O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação.
 
 ![Diagrama de Sequência](Diag_De_Sequencia_V2.0.png)
 <center>
@@ -48,6 +50,12 @@ Afim de especificar melhor os processos de gestão do grupo, cadastro de usuario
 <p> Diagrama de Atividades - Compra: Versão 2.0 (Fonte: Autores, 2023).</a></p> 
 </center>
 
+## Diagrama de Processo - Principal
+
+![Diagrama de Processos](VisaodeprocessosVF.png)
+<center>
+<p> Diagrama de Processos(Fonte: Autores, 2023).</a></p> 
+
 ## Bibliografia
 
 > [1] AULA - ARQUITETURA & DAS – PARTE II. Serrano, Milene. Disponível em: [Aprender3](https://aprender3.unb.br/pluginfile.php/2649469/mod_label/intro/Arquitetura%20e%20Desenho%20de%20Software%20-%20Aula%20Arquitetura%20e%20DAS%20-%20Parte%20II%20-%20Profa.%20Milene.pdf). Acesso em: 25 nov 2023.
@@ -77,5 +85,6 @@ Model of Software Architecture. Disponível em: [cs.ubc.ca](https://www.cs.ubc.c
 | `1.0`  | 25/11/2023 |           Criação do documento            | Beatriz e Gabriel | Mylena e Ana |
 | `1.1`  | 25/11/2023 |  Adição da V.2 do Diagrama de Sequência   | Beatriz e Gabriel | Mylena e Ana |
 | `1.2`  | 25/11/2023 | Adição da V.2 dos Diagramas de Atividades | Beatriz e Gabriel | Mylena e Ana |
+| `1.3`  | 01/12/2023 | Adição do Diagrama de Processos | Beatriz | Ana |