Projeto de Software:Durante a Construção de Software
Em projetos pequenos, muitas atividades são consideradas parte da construção, inclusive o projeto.
Em gera, o programador desenvolve parte do projeto.
Como é o projeto?
Desenho de um diagrama na UML, contendo algumas classes e relacionamentos entre elas
Pseudocódigo de um método
Selecionar um padrão de projeto a ser empregado
DesafiosProjeto de software é um problema “perverso”(é preciso resolver o problema para entendê-lo)
O projeto é obtido de um processo desordenado (faz uso de heurísticas)
Equilíbrio de prioridades(desempenho, produtividade, manutenção?)
Envolve restrições (tempo, custo, ...)
Não é determinístico (n pessoas, n projetos)
Evoluem (não nascem prontos)
Principal objetivo técnico do software: controle da complexidade
Como lidar com a complexidade?
Minimizar a quantidade de complexidade que o cérebro tem que lidar em dado momento
Evitar complexidade acidental desnecessária
O que é desejável?
Complexidade mínima
Facilidade de manutenção
Baixo acoplamento
Extensibilidade
Reutilização
Alto fan-in, baixo fan-out, ...
Níveis de projeto
Sistema (todo o software)
Divisão em subsistemas (vários pacotes)
Divisão em classes dentro de pacotes
Divisão em dados e rotinas (nas classes)
Projeto interno de rotina (método)
Sistema
Todo o sistema
Em casos simples, nenhuma subidivisão é necessária antes da definição de classes
SubsistemasROZANSKI, N. AND WOODS, E. SOFTWARE SYSTEMS ARCHITECTURE. READING, MASSACHUSETTS: ADDISON-WESLEY, 2005, P. 16.
SubsistemasSTEVENS, R., BROOK, P., JACKSON, K., AND ARNOLD, S. SYSTEMS ENGINEERING. ENGLEWOOD CLIFFS, NEW JERSEY: PRENTICE HALL, 1998, P. 97.
Subsistemas
GARLAND, J. LARGE-SCALE SOFTWARE ARCHITECTURE. INDIANAPOLIS, INDIANA: WILEY, 2003, P. 91.
Muitos outros exemplos...
Handbook of Software Architecturehttp://handbookofsoftwarearchitecture.com
Apresenta + de 1000 padrões arquiteturais
Subsistemas típicos
Regras de negócio (cômputos, regras como o aluno não poderá matricular se estiver em débito com a biblioteca, ...)
Interface com o usuário
Acesso a banco de dados
Dependências do sistema operacional, hardware específico, bibliotecas, ...
Classes
Projeto interno de rotinas
Projeto de métodos (algoritmos, pseudocódigo, ...)
Exemplo:Fazer uso de busca binária e, quando encontrado o elemento, verificar se se trata do elemento de menor índice (o que deve ser retornado).
Ferramenta do projetista
HeurísticasNão existe caminho “bem definido” ou determinístico
Da perspectiva OO
Encontre objetos do mundo real (modelagem de domínio)
Identifique objetos (software) e seus atributos
Determine o que pode ser feito com cada objeto
Determine o que cada objeto faz com os demais
Identifique partes visíveis de um objeto
Defina as interfaces de cada objeto
Abstração
Capacidade de ignorar detalhes
Como construir uma casa sem ignorar detalhes?
Detalhes de software devem ser encapsulados!
Ocultamento de informação
Decisões de projeto ou construção são ocultados de todas as outras classes!
Por exemplo, você sabe como está implementada a classe java.util.ArrayList?
Como ocultar?
Usar constantes em vez de literais, ou seja, MAX_ALUNOS_POR_TURMA em vez de 30
Tipos de dados (por exemplo, ArrayList)
Rotinas (métodos)getNextID()
ClassesMegaSenaDownload
Barreiras para o ocultamento
Distribuição excessiva
Dependências circulares
Dados de classes (dados globais)
Perda de desempenho (String.toString() e vetor.length)
O que devo ocultar?
HABITUE-SE À PERGUNTA
Áreas de provável alteraçãoRegras de negócio
Dependências de hardware
Entrada/Saída
Recursos não padronizados (linguagem de programação)
Áreas de projeto e construção difíceis
Variáveis de status
Restrições quanto ao tamanho dos dados
Manter baixo acoplamento
PERSPECTIVAS
Tamanho (poucas conexões)
Visibilidade (pouca exposição)
Flexibilidade (facilidade de alterar conexões)
Tipos. Acoplamento de:Parâmetro e dados simples (apenas tipos primitivos)
Objeto simples (cria instância de uma classe)
Parâmetro-objeto (+ elaborado do que parâmetro de tipos primitivos)
Acoplamento semântico (conhece o funcionamento de outro módulo)(imperceptível ao compilador ou IDE)
Padrão de projeto
Soluções prontas para problemas comuns
Factory Method
Publish/Subscribe (ou Observer), ...
Abstract Factory
Práticas de Projeto
Iteração
Dividir e conquistar
Top-down/bottom-up
Prototipagem experimental
Projeto colaborativo
Quanto de projeto é suficiente?Depende: (a) da experiência da equipe; (b) do conhecimento do domínio; (c) rotatividade da equipe; (d) quão crítica é a aplicação; (e) projeto é pequeno; (f) tempo de vida do software.
Steve McConnell diz:“Eu preferiria usar 80% do trabalho de projeto na criação e exploração de alternativas e 20% na criação de documentação menos aperfeiçoada.”
Registro do projeto
No próprio código
Wiki
Resumos (enviar por email)
Use uma câmera digital
Diagramas UML
Documentos formais
Padrões
IEEE Std 1016 Recommended Practice for Software Design Descriptions
IEEE Std 1471 Recommended Practice for Architectural Description of Software Intensive Systems
Classes funcionais
Evolução
• Inicialmente desenvolvia-se software pensando em instruções
• Depois em rotinas (anos 70 e 80)
• Hoje se pensa em classes!
Tipo Abstrato de Dados
• Ou TAD
• Conjunto composto por dados e operações executadas sobre tais dados
Exemplo
• Elevador: sobe um andar, desce um andar, move-se para andar específico, ...
• Menu: inicia novo menu, cria entrada no menu, ativa/desativa item de menu, ...
Implementação de TAD
• Se a linguagem é orientada a objetos, então tem-se classes
• Caso contrário, você terá mais trabalho
Classe
• Tipo Abstrado de Dados +
• Herança +
• Polimorfismo
Passo + importante na criação de uma classe:Crie uma boa interface(oferece boa abstração)
Dicas• A interface deve oferecer um nível de
abstração consistente
• Certifique-se de compreender qual abstração a classe está implementando
• Forneça serviços em pares (e opostos)(apaga/acende, define/obtém, ...)
• Mova informações não relacionadas para outra classe
Mais dicas...
• Crie interfaces programáticas em vez de semânticas
• (semântica indica como a interface deve ser empregada)
• Considere a abstração e a coesão em conjunto
Bom encapsulamento
• Abstração ajuda a controlar a complexidade (ignora detalhes)
• Encapsulamento (impede que detalhes sejam conhecidos)
Dicas
• Minimize a acessibilidade de classes e membros
• Não exponha dados como públicos
• Elemento interno deve ser privado
• Não faça suposições sobre clientes
• Cuidado com violações semânticas de encapsulamento (não chamar db.connect() porque você sabe que db.busca(jogo) chama o método anterior se não existir conexão)
Elementos internos da classe
• Relação tem-um (referência para objeto)
• Relação é-um (herança), por exemplo, Boi é um Animal.
Dicas
• Pense em herança ou a proíba (final)
• Siga o PSL (Princípio de Substituição de Liskov)
• Evite árvores profundas de herança (7+-2)
Mais dicas...
• Verifique se um switch pode ser substituído por uso de polimorfismo
switch (bicho.getTipo()) { case BOI: System.out.println(“boi”); break; case SAPO: System.out.println(“sapo”); break;}
Funções
• Mantenha o menor número de métodos em uma classe
• Minimize o número de diferentes métodos chamados por uma classe
• Minimize as chamadas indiretas de métodos (Lei de Demétrio)
TAREFA
• Crie código que ilustre uma substituição apropriada de switch pelo uso de polimorfismo
• Crie um diagrama de sequência (UML) que ilustre a Lei de Demétrio
• Crie uma classe com construtor privado e só permita a criação de uma única instância (Singleton)
Métodos de Alta Qualidade
O que você deve saber!
O que é rotina?
Rotina é um método, função ou procedimento que pode ser chamado para desempenhar um único propósito
Razões para criar um método
Reduzir a complexidade
Introduzir uma abstração (aluno.isAprovado() em vez de aluno.naoDeveBilioteca && ...)
Evitar código duplicado
Melhorar a portabilidade, desempenho, ...
Coesão
Quão intimamente estão relacionadas as operações em uma rotina?
Por exemplo, raizDoInverso(x) é menos coesa que raiz(x) e inverso(x).
Tipos
Funcional (executa uma única operação)(MegaSena proposta não coesa)
Sequencial (não identifica função completa)
Comunicativa (usam os mesmos dados)
Temporal
Procedural (ordem de dados fornecidos pela UI)
Lógica (ocorre decisão por flag)
Bons nomes de rotinas
Descreva tudo que a rotina faz
Evite imprecisão (fazCalculo()? geraImpressao()?
Não divida por número (r1(), r2(), r3(), ...)
Use nomes tão longos quanto necessário
Descreva o valor de retorno (raizQuadrada(x))
Use verbo + nome “fortes” (gerarExtrato(fulano)
Bons nomes...
Use opostos corretamente
adicionar/remover em vez de adicionar/destruir
min/max em vez de min/maior
abrir/fechar em vez de abrir/encerrar
Convenções para operações comuns (get/set)
Quão longa deve ser uma rotina?
• Tamanho de uma rotina é inversamente proporcional ao número de erros?!
• Não ultrapasse 200 linhas (não inclui linha em branco nem comentário)
Como usar parâmetros?
• Siga a ordem entrada-uso-saída
• Considere convenções (in, out, ...)
• Se várias rotinas usam os mesmos parâmetros, use uma mesma ordem
• Use todos os parâmetros
• Não os use como variáveis locais
• Limite o número de parâmetros a 7
TAREFA
• JavaBeans possui uma convenção para dar nomes a métodos que obtém e modificam valores de propriedades. Qual é esta convenção?
• java.lang.String possui os métodos regionMatches e copyValueOf, dentre outras. O uso de parâmetros é consistente?
PROGRAMAÇÃO DEFENSIVA“Direção defensiva” em software
Postura
Se alguém fizer algo perigoso, você não será prejudicado!
Entradas inválidas
Verifique dados de todas as fontes externas
Verifique todos os parâmetros de entrada
Decida o que fazer com entradas incorretas
Assertions
Código usado durante o desenvolvimento que permite a um programa fazer uma “auto-verificação” enquanto é executado
calculaMediaFinal(Aluno aluno) { .... mediaFinal = ... assert mediaFinal >= 0 && mediaFinal <= 10; return mediaFinal;}
Dicas
Use um assert para algo que nunca pode ocorrer!
Use código de tratamento de exceção para o que pode ocorrer
Não use código executável em um assert
Use asserts para verificar pré-condições e pós-condições
Tratando errosRetornar um valor “inofensivo” (String vazia, array sem elementos, ...)
Substituir pelos próximos dados válidos(browsers fazem isto com HTML)
Retornar a mesma resposta anterior
Valor válido mais próximo (-2 Kelvin para 0 Kelvin)
Registrar alerta em arquivo de log
Tratando erros...
Retornar um código de erro
Chamar rotina de processamento de erro
Exibir mensagem quando erro for encontrado
Terminar a execução
Tratamento de exceçõesUse para notificar ocorrências que não podem ser ignoradas
Use exceção apenas para situação excepcional
Não use exceção para “empurrar” para outro um problema seu
Evite gerar exceções em construtores, exceto se você as tratar
Exceção deve ser compatível com nível de abstração
Tratando exceções...
Inclua mensagens (contexto) da exceção)
Evite blocos catch vazios
Não ignore exceções que código de biblioteca gera
Considere a criação de “relator” de exceção global
Padronize as exceções do seu projeto
TAREFA
• System.out.println(“x”) retorna void. Como é feito o tratamento em caso de erro?
• System.out.println(“x”) pode gerar uma exceção?
• O que é programar de forma ofensiva? (segundo Steve McConnell?)