Skip to content

Commit

Permalink
Merge pull request #74 from UnBArqDsw2023-2/docfixes
Browse files Browse the repository at this point in the history
quick fix
  • Loading branch information
gabrielm2q authored Dec 1, 2023
2 parents 2d262cb + 5b8b85a commit e60a978
Show file tree
Hide file tree
Showing 4 changed files with 15 additions and 36 deletions.
9 changes: 0 additions & 9 deletions docs/ArquiteturaReutilizacao/4.1.PadroesArquiteturais.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,3 @@

**Foco_01:** Arquitetura de Software

Entrega Mínima: Especificação de 2 Visões do DAS (ESCOPO: Lógica; Processo; Implementação; Implantação e/ou Dados).

OBS: A Visão de Caso de Uso, por ser uma visão já conhecida por vocês em outras disciplinas, não faz parte do escopo. Mas, pode ser explorada de forma adicional pelas equipes.

Apresentação (em sala) explicando o Documento de Arquitetura (DAS), com: (i) rastro claro aos membros participantes (MOSTRAR QUADRO DE PARTICIPAÇÕES & COMMITS); (ii) justificativas & senso crítico sobre esse artefato, em especial detalhando particularidades sobre estilos e padrões arquiteturais idealizados para a aplicação; (iii) breve apresentação da visão do DAS no escopo da aplicação, e (iv) comentários gerais sobre o trabalho em equipe. Tempo da Apresentação: +/- 10min. Recomendação: Apresentar diretamente via Wiki ou GitPages do Projeto.

A Wiki ou GitPages do Projeto deve conter um tópico dedicado ao Módulo Estilos e Padrões Arquiteturais, com Especificação da Visão do DAS, histórico de versões, referências, e demais detalhamentos gerados pela equipe nesse escopo.

Demais orientações disponíveis nas Diretrizes (vide Moodle).
8 changes: 0 additions & 8 deletions docs/ArquiteturaReutilizacao/4.2.ReutilizacaoDeSoftware.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,3 @@
# 4.2. Módulo Reutilização de Software

**Foco_02:** Reutilização de Software.

Entrega Mínima: Exemplo de Reutilização, evidenciando parte conceitual (se possível, com modelagem) e código. Além de outras situações, os Padrões de Projeto são candidatos a serem revelados aqui (problema, solução, modelagem e código, evidenciando aspectos de reutilização).

Apresentação (em sala) conferindo reflexões sobre reutilização de software no escopo da aplicação, com: (i) rastro claro aos membros participantes (MOSTRAR QUADRO DE PARTICIPAÇÕES & COMMITS); (ii) justificativas & senso crítico sobre reutilização de software; (iii) breve análise do exemplo (parte conceitual & código) no escopo da aplicação, e (iv) comentários gerais sobre o trabalho em equipe. Tempo da Apresentação: +/- 10min. Recomendação: Apresentar diretamente via Wiki ou GitPages do Projeto.

A Wiki ou GitPages do Projeto deve conter um tópico dedicado ao Módulo Reutilização de Software, com exemplo de reutilização de software (parte conceitual & código), histórico de versões, referências, e demais detalhamentos gerados pela equipe nesse escopo.

Demais orientações disponíveis nas Diretrizes (vide Moodle).
28 changes: 15 additions & 13 deletions docs/ArquiteturaReutilizacao/Artefatos/DAS.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,9 +80,7 @@ O diagrama de estados é mais um diagrama de modelagem dinâmica UML, ele consis

> <a id="FTF1Ref" href="#FTF1"></a> [Diagrama de Estados](Modelagem/Artefatos/Dinamicos/DiagramaDeEstados.md).
## 3. Objetivos e Restrições Arquiteturais

## 4. Visão de Casos de Uso
## 3. Visão de Casos de Uso

Casos de uso são uma técnica de modelagem usada para descrever a funcionalidade de um sistema de forma a demonstrar como ele interage com entidades externas, conhecidas como atores. Em essência, um caso de uso descreve quem pode fazer o quê com o sistema em questão. Esta abordagem é utilizada para capturar requisitos funcionais, fornecendo uma visão clara de como o sistema deve se comportar.

Expand Down Expand Up @@ -129,7 +127,7 @@ Com base nessa análise, decidimos sobre os casos de uso apresentados. Eles refl

</center>

## 5. Visão Lógica
## 4. Visão Lógica

A visão lógica busca tratar sobre a estruturação e a organização do sistema, destacando os pontos chaves do projeto como por exemplo as classes, pacotes, estados e afins.

Expand All @@ -149,7 +147,7 @@ O diagrama de estados busca evidenciar os fluxos que ocorrem quando um usuário

Ambos os diagramas foram desenvolvidos buscando analisar o escopo de avaliar um produto por parte de um usuário, escopo este definido no início do projeto.

## 6. Visão de Processo
## 5. Visão de Processo

A visão de processo, visa descrever os processos do sistema e suas comunicações de forma à explicitar e facilitar o entendimento das interações entre seus diferentes componentes.

Expand All @@ -164,29 +162,29 @@ Para o projeto, foram desenvolvidos dois diagramas de sequência que explicitam
*Figura X: Diagrama de Sequência do Fluxo de Troca de Pontos*


## 7. Visão de Implementação
## 6. Visão de Implementação

A visão arquitetural de implemetação tem como objetivo ser mais objetiva nas decisões sobre estruturamento de código, frameworks, reutilização de código, tecnologias, etc. Tendo essa visão em em mente, realizamos uma extensa série de estudos para aprofundar nossa compreensão sobre as nuances da visão arquitetural e da visão de implementação. Foi imperativo revisitar o módulo de UML para compreender como um diagrama de componentes opera.

Após a conclusão desses estudos, os alunos Eduardo, Pedro e Lorenzo elaboraram um diagrama de componente. Com o auxílio de Arthur, que revisou ambos os diagramas, chegamos à versão final combinada, consolidando os elementos mais eficazes de ambas as versões anteriores.

![Diagrama de Implementação](../../Assets/Modelagem/DiagramaDeCompoonente_v2.png)

## 8. Visão de Implantação
## 7. Visão de Implantação

Um diagrama de implantação é um tipo de diagrama UML (Unified Modeling Language) que representa a disposição física de elementos de um sistema em hardware. Ele mostra como os vários componentes de software, como aplicativos, servidores e dispositivos de armazenamento, estão distribuídos em diferentes nós de hardware, como computadores físicos ou máquinas virtuais.

Este documento apresenta a arquitetura de implantação de um sistema distribuído, focado em eficiência, segurança e escalabilidade. O sistema é estruturado em vários nós principais: Cliente, Proxy, Web Server e Database, cada um com componentes e entidades específicas.

![Diagrama de Implantação](../../Assets/Modelagem/DiagramaDeImplantacao.jpeg)

### 8.1 Nó Cliente
### 7.1 Nó Cliente
- Componentes:
- Browser: Interface de usuário para acesso ao sistema.
- Comunicação:
- Estabelece uma conexão TCP/IP com o nó Proxy.

### 8.2 Nó Proxy
### 7.2 Nó Proxy
- Componentes:
- Gerenciamento de Cache:
- Entidade Cache: Responsável por armazenar dados frequentemente acessados, melhorando a resposta do sistema.
Expand All @@ -197,34 +195,38 @@ Este documento apresenta a arquitetura de implantação de um sistema distribuí
- Comunicação:
- Conecta-se ao Web Server via HTTPS.

### 8.3 Nó Web Server
### 7.3 Nó Web Server
- Componentes:
- Amazon Server: Servidor de aplicação principal.
- Permissão de Usuário: Gerencia as permissões e acessos dos usuários.
- Federação de Usuário: Facilita a autenticação de usuários de diferentes domínios.
- Comunicação:
- Estabelece uma conexão HTTPS com outro nó Proxy.

### 8.4 Segundo Nó Proxy
### 7.4 Segundo Nó Proxy
- Componentes e Entidades: Mesmos do primeiro nó Proxy.
- Comunicação:
- Conecta-se ao nó Database via TCP/IP.

### 8.5 Nó Database
### 7.5 Nó Database
- Componentes:
- Amazon Database: Responsável pelo armazenamento e gerenciamento de dados.

### 8.6 Fluxo de Dados e Controle
### 7.6 Fluxo de Dados e Controle
1. Do Cliente ao Proxy: O tráfego inicia no Cliente, passa pelo Browser e é direcionado ao Proxy via TCP/IP.
2. Do Proxy ao Web Server: O Proxy processa as requisições, aplicando cache, segurança e privacidade, antes de enviar ao Web Server via HTTPS.
3. Do Web Server ao Database: Após processamento no Web Server, as requisições são encaminhadas através de um segundo Proxy para o Database para operações de dados.

### Conclusão
Este sistema apresenta uma arquitetura robusta e segura, com ênfase em eficiência de processamento, segurança da informação e privacidade do usuário. Cada nó e componente é estrategicamente posicionado para otimizar a performance, segurança e escalabilidade do sistema.


<!--
## 9. Tamanho e Performance
## 10. Qualidade
-->

## Referências

Expand Down
6 changes: 0 additions & 6 deletions docs/_sidebar.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,12 +47,6 @@
- [2.1.2.3. Diagrama de Estados](/Modelagem/Artefatos/Dinamicos/DiagramadeEstados.md)
- [2.2. Participações - Modelagem](/Modelagem/2.2.ParticipacoesModelagem.md)

<!--
- **Padrões de Projeto**
- [3. Desenho de Software (Padrões de Projeto)](/PadroesDeProjeto/3.PadroesDeProjeto.md)
- [Avaliado via Prova]
-->

- **Arquitetura de Software & Reutilização**
- [4. Desenho de Software (Arquitetura & Reutilização de Software)](/ArquiteturaReutilizacao/4.ArquiteturaReutilizacao.md)
- [4.1. Módulo Estilos e Padrões Arquiteturais](/ArquiteturaReutilizacao/4.1.PadroesArquiteturais.md)
Expand Down

0 comments on commit e60a978

Please sign in to comment.