Projeto e Arquitetura de Software
O projeto e a arquitetura de software abordam como um sistema de software é estruturado em componentes e conectores, como as responsabilidades são decompostas e como as decisões de projeto satisfazem as necessidades funcionais e os atributos de qualidade.
Definition
Projeto de software é o processo de definir a arquitetura, componentes, interfaces e outras características de um sistema, e arquitetura de software é o conjunto de estruturas que compreendem os elementos do sistema, suas relações e as propriedades de ambos.
Scope
Esta área abrange estilos e padrões arquitetônicos (camadas, cliente-servidor, microsserviços, orientado a eventos, pipe-and-filter); princípios de projeto como modularidade, ocultação de informação, coesão, acoplamento e separação de preocupações; projeto orientado a objetos e baseado em componentes; padrões de projeto; atributos de qualidade arquitetônica e suas compensações; e notações de modelagem como UML usadas para expressar projetos.
Sub-topics
Core questions
- Como um sistema deve ser decomposto em módulos e componentes?
- Qual estilo arquitetônico melhor suporta os atributos de qualidade exigidos?
- Como os princípios de projeto como acoplamento e coesão guiam uma boa estrutura?
- Como problemas de projeto recorrentes são resolvidos por padrões reutilizáveis?
Key theories
- Ocultação de informação e modularidade
- Parnas argumentou que os módulos devem ser definidos para ocultar decisões de projeto propensas a mudanças por trás de interfaces estáveis, de modo que a mudança seja localizada; este princípio subjaz à modularidade, encapsulamento e baixo acoplamento.
- Atributos de qualidade arquitetônica e compensações
- A arquitetura é impulsionada por atributos de qualidade como desempenho, modificabilidade, disponibilidade e segurança; como estes entram em conflito, a arquitetura é fundamentalmente sobre o raciocínio sobre compensações guiadas por táticas e padrões.
- Padrões de projeto
- Problemas de projeto recorrentes têm soluções bem compreendidas e nomeadas — padrões criacionais, estruturais e comportamentais — que capturam a prática de especialistas e fornecem um vocabulário compartilhado para o projeto orientado a objetos.
Clinical relevance
As decisões de arquitetura são as mais difíceis de mudar posteriormente e as que mais fortemente determinam os atributos de qualidade de um sistema, portanto, um bom projeto e arquitetura reduzem o custo de manutenção a longo prazo, permitem escalabilidade e evolução, e moldam a organização da equipe.
Evidence & guidelines
A norma ISO/IEC/IEEE 42010 padroniza a descrição da arquitetura, e a área de conhecimento de Projeto de Software do SWEBOK, juntamente com textos de referência como Software Architecture in Practice, fornecem orientação consensual.
History
Os princípios de projeto modular foram articulados por Parnas no início dos anos 1970. O projeto orientado a objetos e os padrões de projeto amadureceram nas décadas de 1980 e 1990, a arquitetura de software emergiu como uma disciplina distinta com o trabalho de Shaw e Garlan em meados dos anos 1990, e os estilos orientado a serviços e microsserviços seguiram nas décadas de 2000 e 2010.
Debates
- Arquitetura monolítica versus microsserviços
- A decisão de construir sistemas como um único monólito implantável ou como muitos serviços implantáveis independentemente é amplamente debatida; microsserviços oferecem escalabilidade e implantação independentes ao custo da complexidade de sistemas distribuídos, então a escolha certa depende da escala e da estrutura organizacional.
Key figures
- David Parnas
- Mary Shaw
- Len Bass
- Erich Gamma
- Grady Booch
Related topics
Seminal works
- parnas1972
- gamma1994
- bass2012
Frequently asked questions
- Qual é a diferença entre projeto e arquitetura?
- A arquitetura diz respeito às estruturas de mais alto nível e às decisões mais custosas de mudar — componentes principais, suas interações e atributos de qualidade de todo o sistema — enquanto o projeto abrange a estrutura interna mais detalhada desses componentes; a fronteira é de significância, e não uma linha nítida.
- Por que os padrões de projeto são importantes?
- Os padrões capturam soluções comprovadas para problemas de projeto recorrentes e fornecem aos engenheiros um vocabulário compartilhado, tornando os projetos mais fáceis de comunicar, raciocinar e evoluir; eles são uma orientação a ser aplicada com critério, não receitas obrigatórias.