Projetar um sistema é a criação de sua estrutura interna de forma robusta, extensível e de alta qualidade. Um bom design melhora a qualidade e torna um sistema mais fácil de manter e estender, ao passo que um design pobre pode elevar significativamente o custo de produção e manutenção do software.

O design é uma abstração do código, que representa o sistema, a partir de uma perspectiva que torna mais fácil abordar a estrutura e o comportamento do sistema. Isto pode ser feito através da visualização do código, porém é mais difícil e menos eficaz resolver os problemas estruturais e comportamentais desta forma. O design pode ser: modelos visuais, simples esboços, descrições textuais, etc. O elemento crítico do design é que ele descreve como diferentes elementos do sistema interagem para atender aos requisitos.

A quantidade de design que é formalmente documentada e mantida irá variar dependendo de quão critico é o design e de quanto do design tiver que ser comunicado aos futuros membros da equipe. No mínimo, todos os elementos de design arquiteturalmente significantes devem ser documentados e mantidos atualizados em sincronia com a implementação. Estes são aspectos críticos do sistema que são necessários para o entendimento e a manutenção do software. Outras estruturas e comportamentos importantes ou complexos podem ser mantidos também.

Passos Múltiplos

O design será revisto muitas vezes ao longo do ciclo de vida iterativo e mesmo dentro de uma interação. Cada vez que alguma atividade de design está sendo executada, ela será feita com algum objetivo específico. O objetivo pode ser identificar um conjunto de participantes numa colaboração que possam ser incentivados a realizar o comportamento necessário (um passo de análise). O objetivo pode estar na identificação de alguns elementos granulares necessários à execução de algum cenário (um passo arquitetural). Então um passo pode ser realizado em um desses componentes para identificar os elementos que irão colaborar entre si para realizar o comportamento necessário (um passo mais detalhado de design).

O design pode ser realizado em um contexto específico tal como o contexto de base de dados, interfaces de usuário, ou talvez, o contexto de como alguma biblioteca existente será aplicada. Nestes casos, as etapas do design serão realizadas apenas para comunicar e tomar decisões relativas nesse contexto.

Evite a paralisia analítica. Evite refinar, estender e melhorar o design além de uma versão mínima que seja suficiente para atender as necessidades dos requisitos dentro da arquitetura. O design deve ser executado em pequenos pedaços, comprovado por meio da implementação, melhorado através da re-fatoração e integrado na linha de base para fornecer valor aos analistas de negócios.

Design versus Arquitetura

O design é uma coisa real, é a construção da estrutura e do comportamento e do sistema. A Arquitetura de Software define princípios, contextos e restrições sobre a construção o sistema. A arquitetura é descrita nos artefatos da arquitetura, mas é percebida como design (visual ou não) e implementação.

Uma forma de perceber a arquitetura é que ela contribui para tornar todo o design mais coeso com si mesmo pelo equilíbrio de todas as necessidades do sistema. O design tende a concentrar-se em uma área de cada vez. A arquitetura ajuda a assegurar que o design esteja coerente e adequado com as metas do sistema. Por exemplo, pode haver restrições impostas à maior parte do design para viabilizar o desempenho de uma parte do sistema, tal como a melhoria do acesso a um sistema legado. A não-conformidade com essas restrições do design pode fazer com que o sistema deixe de satisfazer os requisitos de desempenho do acesso ao sistema legado. A conformidade com a arquitetura assegura que todas as metas do sistema sejam alcançadas pelo equilíbrio dos problemas técnicos concorrentes.

Qualidade do Design

Você Não Necessitará Disso

O princípio YAGNI é uma boa abordagem geral para o design. Embora o design deva ser robusto o suficiente para modificação, reutilização, e manutenção, ele também deve ser o mais simples possível. Uma das formas de mantê-lo simples é fazer algumas suposições sobre o que o projeto vai precisar no futuro. Não presuma que você precisará de algo até que você saiba que irá precisar dele, então faça um bom trabalho de adicioná-lo. Acrescente o que é necessário para o requisito ou a iteração atual. Refatore o design apropriadamente quando mais funcionalidades necessitarem ser acrescentadas ou o design tenha que ser mais complexo para lidar com novas circunstâncias.

Acoplamento e Coesão

Dois dos mais elementares princípios de design são: o acoplamento e a coesão. Um bom design contém elementos que têm alta coesão e baixo acoplamento. Alta coesão significa que um único elemento, tal como uma classe ou subsistema, seja composto de peças que estejam estreitamente relacionadas ou trabalhem em estreita colaboração para cumprir algum propósito. Baixo acoplamento significa que os elementos de um sistema têm um mínimo de dependências em si. Um único elemento, como um subsistema deve ser facilmente substituível por outro subsistema que tenha um comportamento semelhante.

Por exemplo, num sistema de pagamento, uma classe Empregado deve ter alta coesão se ela contiver elementos e funções, tais como Nome, Número de Identificação e Salário Mensal. A princípio, pode parecer que a função Calcular Pagamento também será coesiva. Mas quando você considerar que empregados horistas devem ser pagos pelas horas extras, as pessoas de vendas devem ter comissão calculada para elas, etc. a função estará menos relacionada com o Empregado e deverá provavelmente ter sua própria classe ou subsistema.

Um exemplo de baixo acoplamento é que o subsistema Calcular Pagamento possa ser facilmente substituído por terceiros, podendo ser mais robusto e oferecer mais recursos.

É muito importante estar consciente sobre o acoplamento e a coesão porque eles estão em vários princípios e estratégias de design tais como os padrões.

Princípio Aberto-Fechado

Os elementos do design devem estar "abertos" para extensão, mas "fechados" para modificação. A meta deste princípio é a criação de software que possa ser estendido sem a alteração de código. Isso ocorre porque cada mudança de software gera o risco de introdução de erros no código que já está correto. Isto também permite que uma funcionalidade possa ser reutilizada sem ser necessário conhecer os detalhes da implementação, reduzindo o tempo que leva para criar algo novo. Mantendo este princípio em mente ajuda a construir um design mais fácil de manter.