Design e Arquitetura de Software: Conceitos e Práticas

Design de Software

O que é Design de Software?

A essência do Design (estrutura/arquitetura) do software é tomar decisões sobre a organização lógica do software. É projetar a estrutura lógica do sistema.

Conceito: É um subprocesso do Processo de Software que consiste na definição e produção das perspectivas/diagramas sobre o Software.

“O processo de design é um processo de tomada de decisão.”

Design de Alto Nível (Mais Abstrato)

Quanto em maiores partes o sistema é dividido (logicamente), maior é o nível do seu design.

“Vamos pegar um sistema de gestão empresarial e vamos tentar pensar no design desse sistema. Se eu falo que estou pensando no design de um sistema de gestão empresarial, estou pensando na organização lógica desse sistema, ou seja, em decidir a organização do sistema.”

Exemplo: ERP – Divisão de Módulos

• Módulo de Transporte
• Módulo de Estoque
• Módulo Contábil

São todos grandes módulos.

Processo de Design

Dividir esses módulos é fornecer uma lógica de organização. Estruturar o código-fonte em módulos (organizar logicamente) é fazer o Design do código.

A soma das perspectivas de software permite enxergar a arquitetura do software (normalmente, perspectiva lógica [sequência de ações], alocação de componentes).

O Design usa suas representações em diagramação UML.

Nível de Detalhe do Design

Quanto mais detalhes, mais baixo é o nível do design.

Bases históricas e empíricas de experiências anteriores auxiliam na hora de produzir o Design.

Design de Arquitetura

É o processo que leva à definição da decomposição dos sistemas e subsistemas e a um framework de comunicação entre eles.

Vantagens do Design de Arquitetura

• Facilita a comunicação e interpretação do sistema.
• Auxilia no planejamento.
• Melhora a organização.
• Promove o reuso.

Existe uma ligação forte entre Arquitetura e Requisitos Não-Funcionais (Qualidade de Software).

Arquitetura com Melhor Performance

Paralelismo vs. Arquitetura Sequencial

Paralelismo entre as ações.

As ações não dependem tanto delas mesmas; não há tanto encadeamento de ações.

Alta Granularidade

Reduzir ao máximo o número de processos/módulos em um sistema, evitar redundância e procurar sempre o caminho mais rápido e eficiente para realizar as ações.

Relação Arquitetura e Requisitos Não-Funcionais

• Eficiência (citada acima)
• Proteção
  • Camadas
• Segurança
  • Sistema com várias camadas a serem atravessadas até a informação original.
• Disponibilidade
  • “Banco de dados não pode cair.” Uso da arquitetura Cluster (vários bancos rodando ao mesmo tempo).
• Manutenibilidade
  • Baixa granularidade

Tipos de Perspectivas e Design

Arquiteturas contêm perspectivas.

“Projeto de Arquitetura é um processo criativo em que se tenta estabelecer uma organização de sistema que satisfaça os requisitos funcionais e não-funcionais.”

O processo de design da arquitetura gera um Documento de Design (um marco no processo). Esse documento é uma representação gráfica das perspectivas do sistema:

• Perspectiva Estática de Estrutura: “Basicamente, nós queremos enxergar os subsistemas.” Estrutura dividida em partes estáticas.
• Perspectiva Dinâmica de Processo: Processos descritos em tempo de execução.
• Perspectiva de Interface (Relacional): Destaca as interfaces entre os subsistemas, discriminando os processos públicos e privados.
• Perspectiva de Relacionamento: Meios relacionais de transferência de dados ou qualquer outro tipo de ligação entre os métodos.
• Perspectiva de Distribuição: Distribuição física dos componentes.

Evolução dos Modelos de Desenvolvimento

Por que os modelos foram mudando (por que não usaram o Cascata para sempre)?

Métodos Ágeis

Os Métodos Ágeis (desenvolvimento de negócios) buscam uma metodologia para “abraçar” a mudança de requisitos, tentando incorporar a constante mudança de requisitos dentro da metodologia.

“O tempo que você tem para ficar pegando os requisitos, aí você faz o design do projeto, codifica, testa, depois você vai, instala, implanta e entrega, mas é tarde demais, mudaram muito os requisitos e o cliente não precisa mais do software.”

Desvantagens dos Métodos Ágeis (em relação à Arquitetura)

• Dificuldade contratual (estimar prazos, etc.).
• Dificulta o gerenciamento de projetos.
• Causa dificuldades de manutenção e não mantém uma arquitetura fixa, pois há constante mudança de requisitos. (Degradação da qualidade da arquitetura).

Vantagens dos Métodos Ágeis

• Entrega rápida.
• Engajamento do Usuário: A constante presença do usuário evita a formulação errada dos requisitos. A chance de interpretar errado é muito baixa.
• O usuário, participando do processo de requisitos, auxilia indiretamente e consequentemente no processo de testes, na parte de validação do sistema. Um processo bem definido evita erros nos testes.

Processo de Testes

• Validação: Significa que você está entregando o software que o cliente pediu. Quer dizer que o sistema atende apenas aos requisitos do usuário.
• Verificação: O sistema verificado é o sistema que não possui erros de codificação.

Desenvolvimento Incremental

Possui os requisitos mais importantes para o cliente logo no início, pois esse programa será o produto final do cliente.

Desenvolvimento por Protótipo

O protótipo começa a pegar os requisitos que você não tem pleno conhecimento, para sanar as dúvidas. Não será o produto final entregue.

RAD - Rapid Application Development

Exemplo: Access, Visual Studio, Dropbox.

Componentes do Ambiente RAD

• Gerador de Interface
• Gerador de Relatórios
• Linguagem de Programação
• Sistema de Escritórios (vínculos entre o ambiente de programação com outros aplicativos)

Linguagem de Quarta Geração (4GL)

Linguagens de alto nível (Exemplo: Clipper).