Arquitetura e desenho de software
Responsabilidades, estilos, vistas UML, reutilização e decisões de desenho detalhado.
Responsabilidades e contratos
-
Arquitetura: elementos principais, responsabilidades, relações e princípios de evolução. O desenho detalhado escolhe classes, operações, algoritmos e estruturas internas.
-
Um requisito arquiteturalmente significativo influencia a estrutura ou uma decisão difícil de alterar. Concorrência, vários dispositivos e funcionamento sem rede podem exigir escolhas diferentes.
-
Coesão: relação entre responsabilidades de um módulo. Acoplamento: dependências entre módulos; devem ser explícitas e limitar a propagação de mudanças.
-
Ocultação de informação: esconder decisões mutáveis atrás de uma interface. O contrato define entradas, garantias, resultados e falhas.
-
Para reservas concorrentes, o contrato deve oferecer
criarSeLivreatómica, com confirmação ou conflito.consultarseguido deguardarpermite que dois pedidos leiam «livre» e criem reservas sobrepostas. Trocar armazenamento só preserva consumidores se conservar estas garantias.
Estilos arquiteturais
| Estilo | Organização e limite |
|---|---|
| Camadas | Separa níveis de abstração. Na forma estrita usa a camada seguinte; na relaxada admite atalhos para camadas inferiores. |
| Cliente-servidor | Clientes usam uma autoridade remota; exige tratar rede, disponibilidade e segurança. |
| MVC | Separa modelo, vista e controlo da interação, com responsabilidades concretas. |
| Pipes and filters | Etapas transformam dados num fluxo; conversão e coordenação têm custo. |
| Repositório central | Subsistemas partilham dados; dependem do esquema e da disponibilidade comuns. |
Podem coexistir, como cliente-servidor organizado em camadas. O repositório arquitetural não é sinónimo de uma classe Repository.
Um importador pode usar filtros para ler, normalizar, validar e agrupar registos, enquanto a interface usa MVC. Os contratos entre filtros precisam de fixar formatos e erros: trocar datas locais por UTC pode invalidar o resultado sem mudar o estilo arquitetural.
Vistas 4+1 e UML
| Vista | Preocupação |
|---|---|
| Lógica | Responsabilidades e abstrações, classes/pacotes |
| Implementação | Unidades de desenvolvimento, componentes |
| Processo | Interações em execução |
| Implantação | Recursos onde os elementos correm |
| Casos de uso, +1 | Cenários que relacionam e avaliam as quatro vistas |
Pacote agrupa elementos do modelo; componente expõe interfaces fornecidas/requeridas; artefacto é um ficheiro concreto; nó é um recurso de execução.
- Três responsabilidades lógicas podem correr em dois nós: apresentação no telemóvel, serviço e acesso a dados no servidor. Módulo não significa máquina.
Desenho, reutilização e decisões
- Na aplicação, separa apresentação, regras de reserva, acesso a dados e adaptador da API externa. Avalia a arquitetura com um cenário crítico de ponta a ponta.
- Em MVVM, a View apresenta estado; a ViewModel prepara-o e coordena operações; Repositories gerem dados e Services isolam fontes externas. A camada de domínio depende da complexidade das regras.
- Uma biblioteca é chamada pela aplicação; um framework organiza execução e chama código da aplicação, por inversão de controlo. Avalia função, interfaces, qualidade, licença, suporte e integração.
- Regista decisões com contexto, alternativas, escolha e consequências. Uma validação no ecrã melhora feedback; a autoridade dos dados tem de preservar as regras.