TECNOLOGIAS DE CONSTRUÇÃO

DE SOFTWARE
CMP 1069
Prof. Me. Fábio Assunção

Parte 2
PONTO DE VISTA DO USUÁRIO?
 Resume ao o que o software faz, não como.
 Um olhar para o “o que”.
 Lembrar-se dos testes caixa-preta, geralmente
executados pelo usuário final.
PROGRAMAÇÃO DEFENSIVA
 Um olhar para o “como”.
 Um teste caixa-branca, geralmente executado por
quem tem conhecimento da estrutura.
PROGRAMAÇÃO DEFENSIVA

“Todo código é inseguro até se provar o contrário”

PROGRAMAÇÃO DEFENSIVA
 Em média, 80% dos custos previstos são
dedicados à manutenção.

 Manutenção do autor é temporária.

 ATENÇÃO à documentação.
 Todo produto expedido deve ser bem cuidado.
PROGRAMAÇÃO DEFENSIVA
 Nem todo erro é encontrado na compilação, tão
pouco todo defeito é revelado.
 Quais problemas o seguinte trecho de código pode
ter?
PROGRAMAÇÃO DEFENSIVA
 Uso de posições inválidas do vetor.
 Cálculo incorreto.
 Término inesperado do programa.
 Apresentação incorreta de informações.

 Programação defensiva tenta lidar com os

problemas listados.
PROGRAMAÇÃO DEFENSIVA
 Habilidade conferida ao código de se proteger de
entradas inesperadas. Isto é, cuida dos eventos
que não deveriam acontecer.
 Entradas inválidas.
 Eventos que nunca aconteceriam.
 Erros de outros programadores.
 Acoplamento.
 Fontes externas.

 Mensagens de erro, logs, encerramento, etc.

PROGRAMAÇÃO DEFENSIVA
BOAS PRÁTICAS
 Conheça bem a Tecnologia de Construção do
Software.
 Linguagem.
 Possibilita escolher entre aplicar o simples ou
sofisticado em cada caso.
 Complexidade pode criar bugs.
 Alocação de recursos consciente.
 Objetos.
 Parâmetros.
 Bom uso dos recursos alocados.
 Liberação dos recursos após o uso.
PROGRAMAÇÃO DEFENSIVA
BOAS PRÁTICAS
 Cuidado para não exceder.
 Use sempre todos os parâmetros.
 Limite de 5 parâmetros.
 Modulação, se necessário.
 Objetos que contenham dados correlacionados.
PROGRAMAÇÃO DEFENSIVA
CONVENÇÃO DE NOMES
 Classes
 Métodos

 Lembram-se do problema da conformidade da

Engenharia de Software?
 Lembrem-se que a documentação, é a forma de o
programador estar sempre presente.
NOMES DE VARIÁVEIS
 Atenção para com legibilidade e documentação.
 Variáveis são referenciadas por meio de seu
nome.
 Devem ser intuitivos.
 O que usar no nome?
 Letras
 Utilizadas como o primeiro caractere
 Números
 _ (underline)
 Padronização.
NOMES DE VARIÁVEIS
 Nomenclatura com sentido.
 Detalhamento é importante!
 Mas... sem excessos.
 Modelo de negócio muda de acordo com o
domínio.
 Regras particulares de cada linguagem.
NOMES DE VARIÁVEIS
 Cuidado com letras maiúsculas e minúsculas.
 Case sensitive.
 Cuidado com abreviações.
 Atenção com “nomes compostos”.

 Cuidado com o uso de caracteres especiais.

 Atenção às palavras reservadas da linguagem.

 Observe o idioma da nomenclatura.

PROGRAMAÇÃO DEFENSIVA
BOAS PRÁTICAS
 Documentação.
 Comentários = auto documentação.
 Ideal?
PROGRAMAÇÃO DEFENSIVA
TRATAMENTO DE ERROS
 Robustez: capacidade de manter o funcionamento
mesmo diante situações inesperadas.
 Precisão: capacidade de executar as tarefas
descritas pelos requisitos.
PROGRAMAÇÃO DEFENSIVA
TRATAMENTO DE ERROS
 Erros podem variar em função da linguagem,
programador ou projetista.

 Tratamento de Exceções.
 Impacto local x integral.
 Diretas.
 Tratáveis a nível de programação.
 Indiretas.
 Não tratáveis a níveis de programação.
 SO, hardware, etc.

 Exceções são eventos que suspendem a execução

normal do sistema.
 funcionamento + aviso.
PROGRAMAÇÃO DEFENSIVA
 Asserções: encerram a execução, pois não
deveriam ocorrer.
 Assegurar que não irá ocorrer.
 Exceções: permitem a recuperação da execução
(trata-se da robustez).
 Comportamento normal (trata-se da precisão).

 Depuração do código.
PROGRAMAÇÃO DEFENSIVA
 Reuso.
 Padrões de Projeto.
PROGRAMAÇÃO DEFENSIVA
 Planejamento.
 Controle de Versão.