# Arquitetura e desenho de software

Estilos de arquitetura, diagramas UML de classes e sequência, reutilização e desenho detalhado.

Página: https://resumos.rgo.pt/cadeiras/es/arquitetura-desenho/

A **arquitetura** decide a estrutura do sistema: que partes existem, que responsabilidades tem cada uma e como comunicam. O **desenho detalhado** decide como cada parte cumpre a sua responsabilidade: classes, métodos, estruturas de dados. Arquitetura errada significa reescrever; detalhe errado significa refatorar. Por isso a arquitetura decide-se cedo e com mais cerimónia.

## Estilos de arquitetura

Um estilo é uma forma recorrente de organizar as partes. Escolher é trocar vantagens por custos, por isso cada estilo traz a pergunta que o justifica.

**Em camadas.** Apresentação, lógica de negócio, dados. Cada camada só fala com a de baixo. Simples de perceber e de testar por camadas; a app do exemplo cabe aqui. Escolhe quando a simplicidade vale mais do que a escala.

**Cliente servidor.** A app pede, o servidor responde. Separa o que corre no dispositivo do que corre na infraestrutura e permite evoluir cada lado. Escolhe quando há um lado cliente e um lado servidor com ritmos de evolução diferentes.

**MVC.** Modelo (dados e regras), Vista (ecrã), Controlador (mediação). Mantém a interface separada da lógica para poderes mudar o ecrã sem tocar nas regras. Escolhe quando a interface muda muitas vezes e as regras não.

**Microsserviços.** Pequenos serviços independentes que comunicam pela rede. Escalam e evoluem em separado, mas pagam complexidade de operação e de consistência. Escolhe quando a escala e a independência das equipas justificam operar uma rede de serviços.

Numa pergunta de escolha, justifica com os requisitos não funcionais (escala esperada, equipa disponível, criticidade). Camadas simples podem virar monolitos rígidos; microsserviços escalam mas exigem operação séria.

## Diagramas de classes e de sequência

O **diagrama de classes** mostra a estrutura: classes com atributos e métodos, e relações (associação, agregação, herança). Revê [classes e objetos](https://resumos.rgo.pt/cadeiras/p/classes-objetos/) se precisares. Para registar um pedido na app:

![Diagrama de classes com Utilizador, Pedido e BaseDados. O Utilizador efetua vários Pedidos, e cada Pedido é guardado na BaseDados.](https://resumos.rgo.pt/cadeiras/es/arquitetura-desenho/figura-1.svg)

Lê-se: um utilizador efetua vários pedidos; cada pedido tem itens e sabe calcular o seu total. O verbo na associação (“efetua”) importa: associações sem nome escondem decisões.

[Vídeo: Tutorial de diagramas de classes UML, Lucid Software](https://www.youtube.com/watch?v=UI6lqHOVHic)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=UI6lqHOVHic)

O **diagrama de sequência** mostra o comportamento no tempo: objetos em cima, tempo a descer, mensagens com setas, retornos a tracejado. Para o mesmo cenário, as sete mensagens por ordem, com o ramo alternativo à direita:

![Sequência de sete mensagens de cima para baixo: registar pedido, criar, calcular total, devolver pedido, guardar, confirmar gravação e mostrar confirmação. Um ramo alternativo mostra que um item sem preço devolve erro sem guardar.](https://resumos.rgo.pt/cadeiras/es/arquitetura-desenho/figura-2.svg)

Os dois diagramas respondem a perguntas diferentes: o de classes diz o que existe, o de sequência diz como colabora. Um desenho completo precisa dos dois.

[Vídeo: Como fazer um diagrama de sequência UML, Lucid Software](https://www.youtube.com/watch?v=pCK6prSq8aw)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=pCK6prSq8aw)

## Reutilização e desenho detalhado

**Reutilizar** é preferir código já feito e testado: bibliotecas, frameworks, serviços. Reutilizar poupa tempo e defeitos, mas cria dependência: a biblioteca pode mudar, ter vulnerabilidades ou não fazer exatamente o que precisas. A regra prática: reutiliza o que é genérico e bem testado (autenticação, validação, datas), escreve o que é o valor do teu produto (as regras de negócio que te distinguem).

No desenho detalhado, mantém cada módulo pequeno e com uma responsabilidade, se és programador decompõe como em [funções](https://resumos.rgo.pt/cadeiras/fp/funcoes/): cada função e cada classe fazem uma coisa e fazem bem. Fronteiras claras entre módulos são o que permite mudar um requisito sem partir o resto, como viste na [introdução](https://resumos.rgo.pt/cadeiras/es/arquitetura-desenho/introducao/).

Como desenhar sem paralisar

Desenha primeiro a sequência feliz num guardanapo: três a cinco mensagens chegam. Só depois pergunta pelos erros (credenciais inválidas, base de dados em baixo) e acrescenta os fluxos alternativos. Quem começa pelos erros nunca chega ao fluxo principal.

## Exercício: classes, sequência e decisão de reutilizar

Para “registar um pedido” na app:

1.  **Classes.** Desenha `Utilizador` (email, palavra passe, iniciarSessao), `Pedido` (itens, total, calcularTotal) e `BaseDados` (guardar, carregar). Marca a associação “efetua” entre utilizador e pedidos e justifica cada método com um requisito: `calcularTotal` existe porque o requisito de totais o exige.
2.  **Sequência.** Escreve as sete mensagens do diagrama acima e acrescenta o fluxo alternativo: se `calcularTotal` detetar um item sem preço, a App devolve erro ao utilizador sem guardar nada. Repara como o diagrama alternativo revela um requisito em falta: “o que é um item válido”.
3.  **Reutilizar ou escrever.** A app precisa de transformar palavras passe antes de as guardar. Escrever a tua própria função criptográfica é um erro clássico: parece simples e falha de formas subtis. Justifica reutilizar uma biblioteca estabelecida de dispersão com sal: é código genérico, revisto por especialistas e testado por milhões de utilizadores, enquanto a lógica de portes dinâmicos, essa sim específica do negócio, escreve-se em casa.

Na próxima página, [Construção e evolução](https://resumos.rgo.pt/cadeiras/es/arquitetura-desenho/construcao-evolucao/), o desenho transforma-se em código gerido com Git e integração contínua.