SlideShare uma empresa Scribd logo
1 de 69
Baixar para ler offline
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
Desafios é um problema “perverso”
Projeto de software
(é 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
Subsistemas
ROZANSKI, N. AND WOODS, E. SOFTWARE SYSTEMS ARCHITECTURE. READING, MASSACHUSETTS:
ADDISON-WESLEY, 2005, P. 16.
Subsistemas
STEVENS, 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 Architecture
http://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ísticas
Nã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 soft ware 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()

Classes
MegaSenaDownload
Barreiras para o
ocultamento
Distribuição excessiva

Dependências circulares

Dados de classes (dados globais)

Perda de desempenho (String.toString() e
vetor.length)
HABITUE-SE À PERGUNTA




O que devo ocultar?
Áreas de provável
alteração
Regras 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 erros
Retornar 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ções
Use 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?)

Mais conteúdo relacionado

Mais procurados

Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Adriano Tavares
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Softwareelliando dias
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de softwareAdriano Tavares
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANEFco Edilson Nascimento
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de SistemasGuilherme
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialAlexandre Leão
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Softwareeros.viggiano
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Javaarmeniocardoso
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de SistemasGuilherme
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantaçãoelliando dias
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvcJhordam Siqueira
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!Flávio Lisboa
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwarePeter Jandl Junior
 

Mais procurados (20)

Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1Modelagem Arquitetural e Visão 4+1
Modelagem Arquitetural e Visão 4+1
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANEAPSI 2   aulas  - padroes arquiteturais - camadas PROF.TARCIANE
APSI 2 aulas - padroes arquiteturais - camadas PROF.TARCIANE
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Javascript Eventos, Métodos e Funções
Javascript Eventos, Métodos e FunçõesJavascript Eventos, Métodos e Funções
Javascript Eventos, Métodos e Funções
 
Arquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencialArquitetura de Software - Uma visão gerencial
Arquitetura de Software - Uma visão gerencial
 
Analise sistemas 03
Analise sistemas 03Analise sistemas 03
Analise sistemas 03
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Análise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e JavaAnálise e Projeto de Sistemas com UML e Java
Análise e Projeto de Sistemas com UML e Java
 
Modelagem 21102006_2
Modelagem 21102006_2Modelagem 21102006_2
Modelagem 21102006_2
 
Análise e Projeto de Sistemas
Análise e Projeto de SistemasAnálise e Projeto de Sistemas
Análise e Projeto de Sistemas
 
Arquitetura de Sofware
Arquitetura de SofwareArquitetura de Sofware
Arquitetura de Sofware
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvc
 
Modelagem 21102006_1
Modelagem 21102006_1Modelagem 21102006_1
Modelagem 21102006_1
 
Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01Análise de Sistemas Orientado a Objetos - 01
Análise de Sistemas Orientado a Objetos - 01
 
Modelagem 16102006
Modelagem 16102006Modelagem 16102006
Modelagem 16102006
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de Software
 

Semelhante a Cs 2

Engenharia de Software I - Aula 6
Engenharia de Software I - Aula 6Engenharia de Software I - Aula 6
Engenharia de Software I - Aula 6Alessandro Almeida
 
Estratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de VersãoEstratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de VersãoComunidade NetPonto
 
Arquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioArquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioRalph Rassweiler
 
Padrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsPadrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsHerval Freire
 
Boas práticas no desenvolvimento de software
Boas práticas no desenvolvimento de softwareBoas práticas no desenvolvimento de software
Boas práticas no desenvolvimento de softwareFelipe
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agileAlini Rebonatto
 
Framework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoFramework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoMarcius Brandão
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven DesignAndré Borgonovo
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Taller Negócio Digitais
 
Scrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento ÁgilScrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento Ágilabacrazy
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projetoejdn1
 
Domain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHDomain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHGiovanni Bassi
 
Clean code - Qualidade em desenvolvimento de Software
Clean code - Qualidade em desenvolvimento de SoftwareClean code - Qualidade em desenvolvimento de Software
Clean code - Qualidade em desenvolvimento de SoftwareGabriel Felipe Soares
 
Removendo o cheiro ruim do seu código - PHPSC Conf 2011
Removendo o cheiro ruim do seu código - PHPSC Conf 2011Removendo o cheiro ruim do seu código - PHPSC Conf 2011
Removendo o cheiro ruim do seu código - PHPSC Conf 2011Luís Cobucci
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisRogerio Fontes
 

Semelhante a Cs 2 (20)

Engenharia de Software I - Aula 6
Engenharia de Software I - Aula 6Engenharia de Software I - Aula 6
Engenharia de Software I - Aula 6
 
Estratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de VersãoEstratégias de Estruturação de Código-fonte e Controlo de Versão
Estratégias de Estruturação de Código-fonte e Controlo de Versão
 
Arquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioArquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócio
 
Como desenvolver-software
Como desenvolver-softwareComo desenvolver-software
Como desenvolver-software
 
Padrões De Projeto e Anti Patterns
Padrões De Projeto e Anti PatternsPadrões De Projeto e Anti Patterns
Padrões De Projeto e Anti Patterns
 
Boas práticas no desenvolvimento de software
Boas práticas no desenvolvimento de softwareBoas práticas no desenvolvimento de software
Boas práticas no desenvolvimento de software
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agile
 
Framework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoFramework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da Dissertacao
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
 
Scrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento ÁgilScrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento Ágil
 
Padroes De Projeto
Padroes De ProjetoPadroes De Projeto
Padroes De Projeto
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Domain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BHDomain Driven Design (DDD) - DevIsland, BH
Domain Driven Design (DDD) - DevIsland, BH
 
Clean code - Qualidade em desenvolvimento de Software
Clean code - Qualidade em desenvolvimento de SoftwareClean code - Qualidade em desenvolvimento de Software
Clean code - Qualidade em desenvolvimento de Software
 
Removendo o cheiro ruim do seu código - PHPSC Conf 2011
Removendo o cheiro ruim do seu código - PHPSC Conf 2011Removendo o cheiro ruim do seu código - PHPSC Conf 2011
Removendo o cheiro ruim do seu código - PHPSC Conf 2011
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
 
Design patterns
Design patternsDesign patterns
Design patterns
 

Mais de Fábio Nogueira de Lucena

Jornada Goiana em Engenharia de Software 2017
Jornada Goiana em Engenharia de Software 2017Jornada Goiana em Engenharia de Software 2017
Jornada Goiana em Engenharia de Software 2017Fábio Nogueira de Lucena
 
Engenharia de Software - planejamento pedagógico
Engenharia de Software - planejamento pedagógicoEngenharia de Software - planejamento pedagógico
Engenharia de Software - planejamento pedagógicoFábio Nogueira de Lucena
 
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)Fábio Nogueira de Lucena
 

Mais de Fábio Nogueira de Lucena (20)

CSS
CSSCSS
CSS
 
Fundamentos de Programação Front-End
Fundamentos de Programação Front-EndFundamentos de Programação Front-End
Fundamentos de Programação Front-End
 
JavaScript: Aprendendo a programar
JavaScript: Aprendendo a programarJavaScript: Aprendendo a programar
JavaScript: Aprendendo a programar
 
HTML5: Primeiros Contatos (visão geral)
HTML5: Primeiros Contatos (visão geral)HTML5: Primeiros Contatos (visão geral)
HTML5: Primeiros Contatos (visão geral)
 
HTTP: Um Curso Básico
HTTP: Um Curso BásicoHTTP: Um Curso Básico
HTTP: Um Curso Básico
 
Apresentacao curso-2017-08-08
Apresentacao curso-2017-08-08Apresentacao curso-2017-08-08
Apresentacao curso-2017-08-08
 
Jornada Goiana em Engenharia de Software 2017
Jornada Goiana em Engenharia de Software 2017Jornada Goiana em Engenharia de Software 2017
Jornada Goiana em Engenharia de Software 2017
 
Arquétipos
ArquétiposArquétipos
Arquétipos
 
Introducao integracao
Introducao integracaoIntroducao integracao
Introducao integracao
 
Healthdb Visão Geral
Healthdb Visão GeralHealthdb Visão Geral
Healthdb Visão Geral
 
Engenharia de Software - planejamento pedagógico
Engenharia de Software - planejamento pedagógicoEngenharia de Software - planejamento pedagógico
Engenharia de Software - planejamento pedagógico
 
Prontuário Eletrônico do Paciente
Prontuário Eletrônico do PacienteProntuário Eletrônico do Paciente
Prontuário Eletrônico do Paciente
 
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)Especificação por meio de exemplos (BDD, testes de aceitação, ...)
Especificação por meio de exemplos (BDD, testes de aceitação, ...)
 
Introducao
IntroducaoIntroducao
Introducao
 
Uml
UmlUml
Uml
 
Orientação a Objetos (3)
Orientação a Objetos (3)Orientação a Objetos (3)
Orientação a Objetos (3)
 
Orientação a Objetos (2)
Orientação a Objetos (2)Orientação a Objetos (2)
Orientação a Objetos (2)
 
Orientação a Objetos (1)
Orientação a Objetos (1)Orientação a Objetos (1)
Orientação a Objetos (1)
 
Cs 1
Cs 1Cs 1
Cs 1
 
Orientação a objetos (tecnologias)
Orientação a objetos (tecnologias)Orientação a objetos (tecnologias)
Orientação a objetos (tecnologias)
 

Cs 2

  • 1. Projeto de Software: Durante a Construção de Software
  • 2. Em projetos pequenos, muitas atividades são consideradas parte da construção, inclusive o projeto.
  • 3. Em gera, o programador desenvolve parte do projeto.
  • 4. 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
  • 5. Desafios é um problema “perverso” Projeto de software (é 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)
  • 6. Principal objetivo técnico do software: controle da complexidade
  • 7. 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
  • 8. O que é desejável? Complexidade mínima Facilidade de manutenção Baixo acoplamento Extensibilidade Reutilização Alto fan-in, baixo fan-out, ...
  • 9. 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)
  • 10. Sistema Todo o sistema Em casos simples, nenhuma subidivisão é necessária antes da definição de classes
  • 11. Subsistemas ROZANSKI, N. AND WOODS, E. SOFTWARE SYSTEMS ARCHITECTURE. READING, MASSACHUSETTS: ADDISON-WESLEY, 2005, P. 16.
  • 12. Subsistemas STEVENS, R., BROOK, P., JACKSON, K., AND ARNOLD, S. SYSTEMS ENGINEERING. ENGLEWOOD CLIFFS, NEW JERSEY: PRENTICE HALL, 1998, P. 97.
  • 13. Subsistemas GARLAND, J. LARGE-SCALE SOFTWARE ARCHITECTURE. INDIANAPOLIS, INDIANA: WILEY, 2003, P. 91.
  • 14. Muitos outros exemplos... Handbook of Software Architecture http://handbookofsoftwarearchitecture.com Apresenta + de 1000 padrões arquiteturais
  • 15. 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, ...
  • 17. 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).
  • 18. Ferramenta do projetista Heurísticas Não existe caminho “bem definido” ou determinístico
  • 19. 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
  • 20. Abstração Capacidade de ignorar detalhes Como construir uma casa sem ignorar detalhes? Detalhes de soft ware devem ser encapsulados!
  • 21. 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?
  • 22. 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() Classes MegaSenaDownload
  • 23. Barreiras para o ocultamento Distribuição excessiva Dependências circulares Dados de classes (dados globais) Perda de desempenho (String.toString() e vetor.length)
  • 24. HABITUE-SE À PERGUNTA O que devo ocultar?
  • 25. Áreas de provável alteração Regras 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
  • 26. Manter baixo acoplamento PERSPECTIVAS Tamanho (poucas conexões) Visibilidade (pouca exposição) Flexibilidade (facilidade de alterar conexões)
  • 27. 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)
  • 28. Padrão de projeto Soluções prontas para problemas comuns Factory Method Publish/Subscribe (ou Observer), ...
  • 30. Práticas de Projeto Iteração Dividir e conquistar Top-down/bottom-up Prototipagem experimental Projeto colaborativo
  • 31. 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.”
  • 32. Registro do projeto No próprio código Wiki Resumos (enviar por email) Use uma câmera digital Diagramas UML Documentos formais
  • 33. Padrões IEEE Std 1016 Recommended Practice for Software Design Descriptions IEEE Std 1471 Recommended Practice for Architectural Description of Software Intensive Systems
  • 35. Evolução • Inicialmente desenvolvia-se software pensando em instruções • Depois em rotinas (anos 70 e 80) • Hoje se pensa em classes!
  • 36. Tipo Abstrato de Dados • Ou TAD • Conjunto composto por dados e operações executadas sobre tais dados
  • 37. 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, ...
  • 38. Implementação de TAD • Se a linguagem é orientada a objetos, então tem-se classes • Caso contrário, você terá mais trabalho
  • 39. Classe • Tipo Abstrado de Dados + • Herança + • Polimorfismo
  • 40. Passo + importante na criação de uma classe: Crie uma boa interface (oferece boa abstração)
  • 41. 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
  • 42. 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
  • 43. Bom encapsulamento • Abstração ajuda a controlar a complexidade (ignora detalhes) • Encapsulamento (impede que detalhes sejam conhecidos)
  • 44. 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)
  • 45. Elementos internos da classe • Relação tem-um (referência para objeto) • Relação é-um (herança), por exemplo, Boi é um Animal.
  • 46. 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)
  • 47. 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; }
  • 48. 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)
  • 49. 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)
  • 50. Métodos de Alta Qualidade O que você deve saber!
  • 51. O que é rotina? Rotina é um método, função ou procedimento que pode ser chamado para desempenhar um único propósito
  • 52. 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, ...
  • 53. 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).
  • 54. 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)
  • 55. 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)
  • 56. 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)
  • 57. 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)
  • 58. 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
  • 59. 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?
  • 60. PROGRAMAÇÃO DEFENSIVA “Direção defensiva” em software
  • 61. Postura Se alguém fizer algo perigoso, você não será prejudicado!
  • 62. Entradas inválidas Verifique dados de todas as fontes externas Verifique todos os parâmetros de entrada Decida o que fazer com entradas incorretas
  • 63. 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; }
  • 64. 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
  • 65. Tratando erros Retornar 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
  • 66. Tratando erros... Retornar um código de erro Chamar rotina de processamento de erro Exibir mensagem quando erro for encontrado Terminar a execução
  • 67. Tratamento de exceções Use 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
  • 68. 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
  • 69. 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?)