marcello.thiry@gmail.comPrincípios da Engenharia de Software
marcello.thiry@gmail.com http://ideas.scup.com/pt/files/2013/06/conte%C3%BAdo.jpg
1. Princípios, Métodos, Técnicas, Metodo...
Princípio?
marcello.thiry@gmail.com
http://www.ppp.uiuc.edu/newppp_2001/reso
urses/plant/graphics/slidejpgs/tap_root.jpg
Uma verdade ...
marcello.thiry@gmail.com
Princípios formam a base
para métodos e técnicas
Um meio sistemático de fazer
alguma coisa
https:...
marcello.thiry@gmail.com
métodos e técnicas*
* Neste curso, estes dois termos
serão usados sem distinção
semântica
Como pl...
marcello.thiry@gmail.com
Um corpo de práticas, procedimentos e regras
Sistema de métodos e princípios usados
em uma determ...
marcello.thiry@gmail.com
…
marcello.thiry@gmail.com
Apoiam a aplicação de métodos, técnicas e
metodologias
(Ghezzi, Jazayeri & Mandrioli, 2003)
marcello.thiry@gmail.com
…
marcello.thiry@gmail.com
Ferramentas CASE
Computer-Aided Software Engineering
Usadas em fases diferentes do desenvolviment...
marcello.thiry@gmail.com
List of Unified Modeling Language tools
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_La...
Retornando aos
Princípios
Rigor e formalidade
Separação de interesses
Modularidade
Abstração
Antecipação de mudanças
Generalidade
Incrementabilidade...
Rigor e
Formalidade
marcello.thiry@gmail.com
Desenvolvimento de
software é uma
atividade criativa,
certo?
Mas…
marcello.thiry@gmail.com
http://totallyhistory.com/wp-content/uploads/2012/03/Mona_Lisa_by_Leonardo_da_Vinci.jpg
Você conh...
marcello.thiry@gmail.com
Leonardo da Vinci
(1452-1519)
“…Leonardo da Vinci employed a
variety of techniques ...”
“One of h...
marcello.thiry@gmail.com
Engenharia de software deve ser
praticada sistematicamente
Rigor é um complemento necessário para...
marcello.thiry@gmail.com
Rigor
permite repetitividade e faz com as
equipes evitem problemas ocorridos
em projetos anterior...
marcello.thiry@gmail.com
Logo, rigor varia em grau!
Nós precisamos usar a quantidade apropriada
http://mcx.sourceforge.net...
marcello.thiry@gmail.com
Formalidade é rigor no mais alto grau
Permite automação ferramentas
Uma prática formal pode ser v...
Separação de
Interesses
marcello.thiry@gmail.com
“Dividir e conquistar"
(divide et impera)
Identificando diferentes
aspectos de um
problema, nós p...
marcello.thiry@gmail.com
https://en.wikipedia.org/wiki/
Edsger_W._Dijkstra
“The term separation of concerns
was probably c...
marcello.thiry@gmail.com
O único meio de dominar a complexidade
de um projeto é separar os diferentes
interesses
Tempo
Qua...
marcello.thiry@gmail.com
Tempo
Qualidades
Visões
Partes
Fases, iterações, atividades…,
Estrutural x Comportamental, Camada...
Modularidade
Um sistema complexo pode ser dividido em
unidades ou partes menores e mais simples
MÓDULOS
http://www.brickshop.co.uk/bric...
marcello.thiry@gmail.com
MAIOR
Nível de abstração
MENOR
Sistema Subsistema Módulos
marcello.thiry@gmail.com
Sistema modular
Tratar um módulo por vez,
ignorando detalhes dos demais
Modularidade
aplicação da...
marcello.thiry@gmail.com
Mas tenha cuidado…
(Pressman, 2015)
marcello.thiry@gmail.com
Decomposição
Mais alta abstração
funcional
Nível de sistema
marcello.thiry@gmail.com
Nível de
Subsistema
Decomposição
Mais alta abstração
funcional
Nível de sistema
marcello.thiry@gmail.com
Hierarquia
Top-down
+ abstrato
- abstrato
Nível de
Módulo
Nível de
Subsistema
Decomposição
Nível ...
marcello.thiry@gmail.com
https://en.wikipedia.org/wiki/
Niklaus_Wirth
In 1971, Niklaus Wirth, wrote the
influential paper ...
marcello.thiry@gmail.com
Considerações TOP-DOWN
+ -Disciplina lógica, que
organiza bem o pensamento
Permite equipes maiore...
marcello.thiry@gmail.com
Composição
Nível mais baixo
de abstração
funcional
Nível de
Módulo
marcello.thiry@gmail.com
Composição
Nível mais baixo
de abstração
funcional
Nível de
Módulo
Nível de
Subsistema
marcello.thiry@gmail.com
Hierarquia
Bottom-up
Composição
+ abstrato
- abstrato
Nível de sistema
Nível de
Módulo
Nível de
S...
marcello.thiry@gmail.com
BOTTOM-UP Considerations
+ -
Permite antecipar
codificação e testes
Potencializa reuso, mais
fáci...
marcello.thiry@gmail.com
TOP-DOWN
ou
BOTTOM-UP?
http://ruccs.rutgers.edu/faculty/pylyshyn/cogscitalk/fish2.gif
marcello.thiry@gmail.com
TOP-DOWN X BOTTOM-UP
Ambas permitem entender as relações entre
visões de alto e baixo nível abstr...
marcello.thiry@gmail.com
Módulo ACME
Dados
+
Estruturas
+
Procedimentos
+
Funções
Operacao_1 …
Operacao_2 …
Operacao_3 …
O...
marcello.thiry@gmail.com
https://en.wikipedia.org/wiki/
David_Parnas
The concept of information hiding was
first described...
marcello.thiry@gmail.com
Conta
getNumero : int
depositar float
sacar float
getSaldo : float
Encapsulamento + Ocultação de ...
marcello.thiry@gmail.com
Todos os elementos de um módulo
devem estar altamente relacionados
Coesão: medida interna
OBJETIV...
Princípio da responsabilidade única
Martin*, 1995
*Robert Martin é conhecido como Uncle Bob
http://wordlesstech.com/wp-con...
Motivo para mudar
PARTE ÚNICA de toda a funcionalidade
Encapsulamento coesão
Antecipar como a classe irá evoluir
Uma class...
marcello.thiry@gmail.com
marcello.thiry@gmail.com
Responsibility 1
Human Resources
Responsibility 2
Payroll Department
Responsibility 3
DBA team
marcello.thiry@gmail.com
marcello.thiry@gmail.com
Mas seja cuidadoso...
marcello.thiry@gmail.com
Cada módulo comunica-se com a menor
quantidade possível de outros módulos
Acoplamento: medida ext...
marcello.thiry@gmail.com
Princípio aberto-fechado
Meyer, 1988-1997
ABERTO = disponível para extensão
FECHADO = disponível ...
marcello.thiry@gmail.com
Adicionar novos comportamentos
para atender às mudanças
Aberto para extensão
Mas sem modificar o ...
marcello.thiry@gmail.com
A sacada…
Módulos que dependem
daqueles estendidos não são
afetados pela extensão
marcello.thiry@gmail.com
Mas como?
Abstrações
Herança
Interfaces
Redefinição
Polimorfismo
marcello.thiry@gmail.com
https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle
https://sklivvz.com/pos...
marcello.thiry@gmail.com
ALTO ACOPLAMENTO
Organização
não hierárquica
Organização
hierárquica
BAIXO ACOPLAMENTO
dependênci...
marcello.thiry@gmail.com
E sobre coesão?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, c...
marcello.thiry@gmail.com
Sacou?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
Orga...
marcello.thiry@gmail.com
Logo…
dependência
usa, chama
marcello.thiry@gmail.com
Princípio da Inversão de Dependência
Depender de abstrações, não de
implementações concretions
Ma...
marcello.thiry@gmail.com
Módulo como um pacote...
Oferece um espaço único de nome
namespace
Encapsula classes, interfaces ...
marcello.thiry@gmail.com
Módulo como uma biblioteca...
Contém um ou mais pacotes
Pedaço de código sem estado interno e um
...
marcello.thiry@gmail.com
Módulo como uma classe...
Podem ser instanciadas várias vezes
Podem implementar várias interfaces...
Abstração
marcello.thiry@gmail.com
http://www.promo-wholesale.com/Upfiles/Prod_q/Solar-
Powered-Desk-Calculator_20090641609.jpg
iden...
marcello.thiry@gmail.com
Mas tenha cuidado…
Você deve
desconsiderar apenas
aqueles detalhes que
podem ser realmente
ignora...
marcello.thiry@gmail.com
Abstração
Caso especial de separação de interesses
Técnica para dominar a complexidade
Aspectos i...
marcello.thiry@gmail.com
https://design2014level2.files.wordpress.com
/2014/04/ceiling-fan-70914.gif
Sistema de casa
intel...
marcello.thiry@gmail.com
Como estimar?
Quais aspectos ou fatores devemos considerar?
Complexidade
Quantidade
Experiência d...
Antecipação
de Mudanças
Novas
funcionalidades
Software
muda o
tempo todo
Melhorias em
funcionalidades
existentes
Correção
de defeitos
Melhorias no...
marcello.thiry@gmail.com
Manutenção
de software
Evolução
do software
Corretiva
ADAPTATIVA
EVOLUTIVA
Preventiva
marcello.thiry@gmail.com
Como antecipar prováveis
mudanças futuras?
CUIDADO! Isso não é sobre tentar
implementar o que os ...
marcello.thiry@gmail.com
Como melhorar a
Manutenibilidade?
Grau de eficácia e eficiência
com o qual o software pode
ser mo...
marcello.thiry@gmail.com
marcello.thiry@gmail.com
Como apoiar a manutenibilidade?
Ferramentas de gerência de configuração
Controle de versão
Gerênc...
marcello.thiry@gmail.com
Integration
tools
http://buildbot.net
http://jenkins-ci.org/
http://git-scm.com/
Version control
...
Generalidade
marcello.thiry@gmail.com
Se você pensa que já encontrou uma
solução, pense novamente!
Mas com uma mente
mais aberta!
Enqua...
marcello.thiry@gmail.com
Tente verificar se existe uma instância de um
PROBLEMA MAIS GENÉRICO
Algumas vezes, um problema g...
*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.acm.org/citation.cfm?id=62141
Se um objeto X do tip...
Princípio da substituição de Liskov
Liskov, 1987
*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.ac...
Incrementabilidade
Grow, Don't Build
http://cdn.shopify.com/s/files/1/0070/7032/files/The_10_Strategy.jpg?754
marcello.thiry@gmail.com
Entregar um sistema em partes para obter feedback contínuo dos usuários e
adicionar novas feature...
marcello.thiry@gmail.com
References.
 (Ghezzi, Jazayeri & Mandrioli, 2003). Fundamentals of Software Engineering. 2nd ed....
Próximos SlideShares
Carregando em…5
×

Princípios da engenharia de software (marcello thiry)

667 visualizações

Publicada em

Apresentações para as disciplinas de Engenharia Software (graduação)
Princípios da Engenharia de Software
University of Vale do Itajaí
Univali
Incremental Tecnologia
Versão em Português

Publicada em: Educação
0 comentários
4 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
667
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
32
Comentários
0
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Princípios da engenharia de software (marcello thiry)

  1. 1. marcello.thiry@gmail.comPrincípios da Engenharia de Software
  2. 2. marcello.thiry@gmail.com http://ideas.scup.com/pt/files/2013/06/conte%C3%BAdo.jpg 1. Princípios, Métodos, Técnicas, Metodologias e Ferramentas 2. Rigor e formalidade 3. Separação de interesses 4. Modularidade 5. Abstração 6. Antecipação de mudanças 7. Generalidade 8. Incrementabilidade Conteúdo.
  3. 3. Princípio?
  4. 4. marcello.thiry@gmail.com http://www.ppp.uiuc.edu/newppp_2001/reso urses/plant/graphics/slidejpgs/tap_root.jpg Uma verdade básica, lei ou suposição Base para predição e ação conduta (Ghezzi, Jazayeri & Mandrioli, 2003)
  5. 5. marcello.thiry@gmail.com Princípios formam a base para métodos e técnicas Um meio sistemático de fazer alguma coisa https://upload.wikimedia.org/wikipedia/c ommons/thumb/8/8f/PSM_V10_D029_A ncient_fire_making_methods.jpg/800px- PSM_V10_D029_Ancient_fire_making_ methods.jpg (Ghezzi, Jazayeri & Mandrioli, 2003)
  6. 6. marcello.thiry@gmail.com métodos e técnicas* * Neste curso, estes dois termos serão usados sem distinção semântica Como planejar... Como testar... Como projetar... Como codificar... Como elicitar requisitos Como estimar... ... Observação, entrevistas, workshops, questionários...
  7. 7. marcello.thiry@gmail.com Um corpo de práticas, procedimentos e regras Sistema de métodos e princípios usados em uma determinada disciplina (Ghezzi, Jazayeri & Mandrioli, 2003)
  8. 8. marcello.thiry@gmail.com …
  9. 9. marcello.thiry@gmail.com Apoiam a aplicação de métodos, técnicas e metodologias (Ghezzi, Jazayeri & Mandrioli, 2003)
  10. 10. marcello.thiry@gmail.com …
  11. 11. marcello.thiry@gmail.com Ferramentas CASE Computer-Aided Software Engineering Usadas em fases diferentes do desenvolvimento de software
  12. 12. marcello.thiry@gmail.com List of Unified Modeling Language tools https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools List of diagramming tools http://www.diagramming.org/ Data Modeling Tools http://toolsfordatabases.com/data-modeling-tools.html Comparison of data modeling tools https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools Test management tools https://en.wikipedia.org/wiki/Test_management_tools List of GUI testing tools https://en.wikipedia.org/wiki/List_of_GUI_testing_tools List of web testing tools https://en.wikipedia.org/wiki/List_of_web_testing_tools Comparison of project management software https://en.wikipedia.org/wiki/Comparison_of_project_management_software List of build automation software Configuration, Build, Integration, ... https://en.wikipedia.org/wiki/List_of_build_automation_software Application lifecycle management (ALM) https://en.wikipedia.org/wiki/Application_lifecycle_management Experimente... …
  13. 13. Retornando aos Princípios
  14. 14. Rigor e formalidade Separação de interesses Modularidade Abstração Antecipação de mudanças Generalidade Incrementabilidade Princípios chave (Ghezzi, Jazayeri & Mandrioli, 2003) * Do inglês “concerns”. Outras traduções: conceitos, responsabilidades*
  15. 15. Rigor e Formalidade
  16. 16. marcello.thiry@gmail.com Desenvolvimento de software é uma atividade criativa, certo? Mas…
  17. 17. marcello.thiry@gmail.com http://totallyhistory.com/wp-content/uploads/2012/03/Mona_Lisa_by_Leonardo_da_Vinci.jpg Você conhece o cara que pintou isso, certo?
  18. 18. marcello.thiry@gmail.com Leonardo da Vinci (1452-1519) “…Leonardo da Vinci employed a variety of techniques ...” “One of his most well-known paintings, the Mona Lisa, displays some of the techniques used by da Vinci in its grandeur.” http://www.davincilife.com
  19. 19. marcello.thiry@gmail.com Engenharia de software deve ser praticada sistematicamente Rigor é um complemento necessário para a criatividade que aumenta a confiança nos resultados do desenvolvimento Precisão, exatidão
  20. 20. marcello.thiry@gmail.com Rigor permite repetitividade e faz com as equipes evitem problemas ocorridos em projetos anteriores Qual nível de disciplina conjunto de regras nós precisamos para… … produzir produtos com maior confiabilidade e qualidade, sem deixar de controlar custos e atender expectativas?
  21. 21. marcello.thiry@gmail.com Logo, rigor varia em grau! Nós precisamos usar a quantidade apropriada http://mcx.sourceforge.net/upload/matlab_mmclab.pnghttp://www.mathworks.com/products/matlab/ http://4.bp.blogspot.com/- IyHsfT1sB1A/UhTQdRV8opI/AAAAAAAABiI/H2R3X1OmAUg/s1600/V NLIVES.NE-Simple-calculator-01.png
  22. 22. marcello.thiry@gmail.com Formalidade é rigor no mais alto grau Permite automação ferramentas Uma prática formal pode ser verificada por leis matemáticas Métodos formais redes de petri, z, … O código fonte é escrito numa linguagem formal
  23. 23. Separação de Interesses
  24. 24. marcello.thiry@gmail.com “Dividir e conquistar" (divide et impera) Identificando diferentes aspectos de um problema, nós podemos nos concentrar em cada um individualmente
  25. 25. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ Edsger_W._Dijkstra “The term separation of concerns was probably coined by Dijkstra in his 1974 paper On the role of scientific thought” Edsger Wybe Dijkstra (1930-2002) A pioneer in the fields of computer science and computational physics. Among many contributions, he coined the phrase "structured programming" and discovered the algorithm for the shortest path in a graph, which now bears his name. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html Paper "On the role of scientific thought" transcribed by Richard Walker: https://en.wikipedia.org/wiki/Separation_of_concerns
  26. 26. marcello.thiry@gmail.com O único meio de dominar a complexidade de um projeto é separar os diferentes interesses Tempo Qualidades Visões Partes Habilidades http://www.crochetville.com/community/uploads/monthly_06_2013/post-48806-0-42116700-1370920781.jpg
  27. 27. marcello.thiry@gmail.com Tempo Qualidades Visões Partes Fases, iterações, atividades…, Estrutural x Comportamental, Camadas ex: MVC Funcional, Eficiência, Usabilidade, confiabilidade, … modularidade Responsabilidades e habilidades Gerente de Projeto, Analista de Sistemas, Projetista, …
  28. 28. Modularidade
  29. 29. Um sistema complexo pode ser dividido em unidades ou partes menores e mais simples MÓDULOS http://www.brickshop.co.uk/bricks-16-c.asp http://www.lego.com/ http://constructionweekonline.com//pictures/LEGO_Sungnyemun.jpg
  30. 30. marcello.thiry@gmail.com MAIOR Nível de abstração MENOR Sistema Subsistema Módulos
  31. 31. marcello.thiry@gmail.com Sistema modular Tratar um módulo por vez, ignorando detalhes dos demais Modularidade aplicação da separação de interesses composto por módulos
  32. 32. marcello.thiry@gmail.com Mas tenha cuidado… (Pressman, 2015)
  33. 33. marcello.thiry@gmail.com Decomposição Mais alta abstração funcional Nível de sistema
  34. 34. marcello.thiry@gmail.com Nível de Subsistema Decomposição Mais alta abstração funcional Nível de sistema
  35. 35. marcello.thiry@gmail.com Hierarquia Top-down + abstrato - abstrato Nível de Módulo Nível de Subsistema Decomposição Nível de sistema Mais alta abstração funcional
  36. 36. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ Niklaus_Wirth In 1971, Niklaus Wirth, wrote the influential paper Program Development by Stepwise Refinement. Today, we refer to this approach as top-down design (or top-down decomposition). Niklaus Emil Wirth (1934-) A Swiss computer scientist, best known for designing several programming languages (Algol W, Pascal, Modula, Modula-2, Oberon, Oberon- 2, Oberon-7) and for pioneering several classic topics in software engineering. In 1984 he won the Turing Award for developing a sequence of innovative computer languages. He designed the simple programming language PL/0 to illustrate compiler design. It has formed the basis for many university compiler design classes. http://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf “Program Development by Stepwise Refinement” (1971)
  37. 37. marcello.thiry@gmail.com Considerações TOP-DOWN + -Disciplina lógica, que organiza bem o pensamento Permite equipes maiores serem divididas entre os subsistemas Funciona muito bem para pequenos projetos Focado em requisitos funcionais Pensar um sistema como uma única função topo Decisões prematuras, menos preparada para mudanças Reuso é mais difícil Posterga codificação e testes Aumenta chance de dependências indesejáveis
  38. 38. marcello.thiry@gmail.com Composição Nível mais baixo de abstração funcional Nível de Módulo
  39. 39. marcello.thiry@gmail.com Composição Nível mais baixo de abstração funcional Nível de Módulo Nível de Subsistema
  40. 40. marcello.thiry@gmail.com Hierarquia Bottom-up Composição + abstrato - abstrato Nível de sistema Nível de Módulo Nível de Subsistema
  41. 41. marcello.thiry@gmail.com BOTTOM-UP Considerations + - Permite antecipar codificação e testes Potencializa reuso, mais fácil para incorporar e testar módulos pré- existentes Mais preparado para mudança Sem alguma antecipação, pode ser difícil ligar módulos Foco não está em requisitos funcionais resultados podem não atender alguma necessidade Difícil desenvolver um sistema completo bottom-up Adequado para equipes menores
  42. 42. marcello.thiry@gmail.com TOP-DOWN ou BOTTOM-UP? http://ruccs.rutgers.edu/faculty/pylyshyn/cogscitalk/fish2.gif
  43. 43. marcello.thiry@gmail.com TOP-DOWN X BOTTOM-UP Ambas permitem entender as relações entre visões de alto e baixo nível abstração de um sistema Na prática, o design de sistemas maiores nunca é realmente top-down Alguns ramos são projetados antes de outros Projetistas reusam experiência e módulos Projeto híbrido Sua combinação potencializa entendimento, proteção da informação e reuso (Sommerville, 1995)
  44. 44. marcello.thiry@gmail.com Módulo ACME Dados + Estruturas + Procedimentos + Funções Operacao_1 … Operacao_2 … Operacao_3 … Operacao_4 … Operacao_N …
  45. 45. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ David_Parnas The concept of information hiding was first described by Parnas in his paper On the Criteria to be Used in Decomposing Software into Modules (1972) David Lorge Parnas (1941-) Canadian early pioneer of software engineering, who was one of the first to recognize the importance of software structure. He developed the concept of information hiding in modular programming, which is an important element of object-oriented programming today. He is also noted for his advocacy of precise documentation. https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf “On the Criteria to be Used in Decomposing Software into Modules” (1972)
  46. 46. marcello.thiry@gmail.com Conta getNumero : int depositar float sacar float getSaldo : float Encapsulamento + Ocultação de informação IMPLEMENTAÇÃOINTERFACE http://thumbs.dreamstime.com/t/manikin-keep-distance- orange-cartoon-character-red-text-30647683.jpg Módulos cliente dependem somente da interface Continuidade: pequenas mudanças tem efeitos localizados Aumenta reusabilidade e capacidade de substituição Proteção: isolamento dos defeitos (Meyer, 1988-1997) Information Hiding
  47. 47. marcello.thiry@gmail.com Todos os elementos de um módulo devem estar altamente relacionados Coesão: medida interna OBJETIVO: ALTA COESÃO Todos os elementos compartilham o mesmo objetivo Entendimento de um módulo de modo isolado Conta getNumero : int depositar float sacar float getSaldo : float
  48. 48. Princípio da responsabilidade única Martin*, 1995 *Robert Martin é conhecido como Uncle Bob http://wordlesstech.com/wp-content/uploads/2010/12/swiss-army-knife-giant-elite1.jpg https://lostechies.com/gabrielschenker/2009/01/21/real- swiss-don-t-need-srp-do-they/ By Gabriel Schenker
  49. 49. Motivo para mudar PARTE ÚNICA de toda a funcionalidade Encapsulamento coesão Antecipar como a classe irá evoluir Uma classe deveria ter um único motivo para mudar RESPONSABILIDADE
  50. 50. marcello.thiry@gmail.com
  51. 51. marcello.thiry@gmail.com Responsibility 1 Human Resources Responsibility 2 Payroll Department Responsibility 3 DBA team
  52. 52. marcello.thiry@gmail.com
  53. 53. marcello.thiry@gmail.com Mas seja cuidadoso...
  54. 54. marcello.thiry@gmail.com Cada módulo comunica-se com a menor quantidade possível de outros módulos Acoplamento: medida externa Dependência entre módulos OBJETIVO: BAIXO ACOPLAMENTO Reduzindo o acoplamento + Entendimento Meyer, 1988-1997 + Testabilidade + Modificabilidade + Reusabilidade
  55. 55. marcello.thiry@gmail.com Princípio aberto-fechado Meyer, 1988-1997 ABERTO = disponível para extensão FECHADO = disponível para uso por outros módulos Módulos deveriam estar ABERTOS e FECHADOS
  56. 56. marcello.thiry@gmail.com Adicionar novos comportamentos para atender às mudanças Aberto para extensão Mas sem modificar o código fonte dos módulos existentes Fechado para modificação
  57. 57. marcello.thiry@gmail.com A sacada… Módulos que dependem daqueles estendidos não são afetados pela extensão
  58. 58. marcello.thiry@gmail.com Mas como? Abstrações Herança Interfaces Redefinição Polimorfismo
  59. 59. marcello.thiry@gmail.com https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle https://sklivvz.com/posts/say-no-to-the-openclosed-pattern http://blogs.msmvps.com/jonskeet/2013/03/15/the-open-closed-principle-in-review/ http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html http://codecourse.sourceforge.net/materials/The-Importance-of-Being-Closed.pdf Interesting reading…
  60. 60. marcello.thiry@gmail.com ALTO ACOPLAMENTO Organização não hierárquica Organização hierárquica BAIXO ACOPLAMENTO dependência usa, chama
  61. 61. marcello.thiry@gmail.com E sobre coesão? ALTO ACOPLAMENTO Organização não hierárquica BAIXO ACOPLAMENTO dependência usa, chama Organização hierárquica
  62. 62. marcello.thiry@gmail.com Sacou? ALTO ACOPLAMENTO Organização não hierárquica BAIXO ACOPLAMENTO dependência usa, chama Organização hierárquica
  63. 63. marcello.thiry@gmail.com Logo… dependência usa, chama
  64. 64. marcello.thiry@gmail.com Princípio da Inversão de Dependência Depender de abstrações, não de implementações concretions Martin*, 1995
  65. 65. marcello.thiry@gmail.com Módulo como um pacote... Oferece um espaço único de nome namespace Encapsula classes, interfaces e recursos Regras de acesso: visibilidade package
  66. 66. marcello.thiry@gmail.com Módulo como uma biblioteca... Contém um ou mais pacotes Pedaço de código sem estado interno e um API pública Em Java, os limites de um JAR não ficam claros depois de sua liberação no class path
  67. 67. marcello.thiry@gmail.com Módulo como uma classe... Podem ser instanciadas várias vezes Podem implementar várias interfaces Classes e responsabilidade única Granularidade?
  68. 68. Abstração
  69. 69. marcello.thiry@gmail.com http://www.promo-wholesale.com/Upfiles/Prod_q/Solar- Powered-Desk-Calculator_20090641609.jpg identificar os aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais Abstrair é…
  70. 70. marcello.thiry@gmail.com Mas tenha cuidado… Você deve desconsiderar apenas aqueles detalhes que podem ser realmente ignorados O que fazer aqui??? http://www.convio.com/common-ground/assets/crazy_sm.jpg
  71. 71. marcello.thiry@gmail.com Abstração Caso especial de separação de interesses Técnica para dominar a complexidade Aspectos importantes x Detalhes menos importantes A seleção de quais aspectos são importantes e quais podem ser ignorados depende do observador e do problema observado Modelagem, diagramação, prototipação, equações, …
  72. 72. marcello.thiry@gmail.com https://design2014level2.files.wordpress.com /2014/04/ceiling-fan-70914.gif Sistema de casa inteligente Sistema de vendas online Qual é o problema?
  73. 73. marcello.thiry@gmail.com Como estimar? Quais aspectos ou fatores devemos considerar? Complexidade Quantidade Experiência da equipe Tecnologia usada Tipo de produto ... Quais deles são essenciais?
  74. 74. Antecipação de Mudanças
  75. 75. Novas funcionalidades Software muda o tempo todo Melhorias em funcionalidades existentes Correção de defeitos Melhorias no desempenho Adaptação devido a mudanças na legislação, no ambiente ex: DBMS, SO
  76. 76. marcello.thiry@gmail.com Manutenção de software Evolução do software Corretiva ADAPTATIVA EVOLUTIVA Preventiva
  77. 77. marcello.thiry@gmail.com Como antecipar prováveis mudanças futuras? CUIDADO! Isso não é sobre tentar implementar o que os usuários TALVEZ precisem no futuro Isso é sobre estar preparado para mudar!
  78. 78. marcello.thiry@gmail.com Como melhorar a Manutenibilidade? Grau de eficácia e eficiência com o qual o software pode ser modificado (ISO/IEC 25010, 2011)
  79. 79. marcello.thiry@gmail.com
  80. 80. marcello.thiry@gmail.com Como apoiar a manutenibilidade? Ferramentas de gerência de configuração Controle de versão Gerência de mudanças Integração Repositórios Componentes reutilizáveis Documentação
  81. 81. marcello.thiry@gmail.com Integration tools http://buildbot.net http://jenkins-ci.org/ http://git-scm.com/ Version control tools https://travis-ci.org/ http://subversion.tigris.org/ https://github.com/ Change Management tools https://www.mantisbt.org/ http://www.accurev.com/ …… … http://www.redmine.org/
  82. 82. Generalidade
  83. 83. marcello.thiry@gmail.com Se você pensa que já encontrou uma solução, pense novamente! Mas com uma mente mais aberta! Enquanto estiver resolvendo um problema...
  84. 84. marcello.thiry@gmail.com Tente verificar se existe uma instância de um PROBLEMA MAIS GENÉRICO Algumas vezes, um problema genérico é mais fácil de resolver do que um caso especial Talvez, a solução possa ser aplicada em outros casos Você precisa considerar o custo/benefício entre generalidade, desempenho e custo Mas... Enquanto estiver resolvendo um problema...
  85. 85. *Keynote address: data abstraction and hierarchy, OOPSLA '87 http://dl.acm.org/citation.cfm?id=62141 Se um objeto X do tipo T tem um método P que se comporta de uma forma O objeto Y do tipo S, onde S é um subtipo de T, deveria ter o mesmo método P se comportando da mesma forma Princípio da substituição de Liskov Liskov, 1987
  86. 86. Princípio da substituição de Liskov Liskov, 1987 *Keynote address: data abstraction and hierarchy, OOPSLA '87 http://dl.acm.org/citation.cfm?id=62141 Tudo está na semântica! Depender mais das interfaces do que de tipos de classe
  87. 87. Incrementabilidade
  88. 88. Grow, Don't Build http://cdn.shopify.com/s/files/1/0070/7032/files/The_10_Strategy.jpg?754
  89. 89. marcello.thiry@gmail.com Entregar um sistema em partes para obter feedback contínuo dos usuários e adicionar novas features de modo incremental Entregar um protótipo inicial e então adicionar novas features de modo incremental para transformar o protótipo em produto O processo avança em passos sucessivos incrementos FeedbackEntrega FeedbackEntrega Entrega Exemplos processo Desenvolvimento usuário Inc #1 Inc #2 Inc #N usuário usuário usuário Desenvolvimento Desenvolvimento
  90. 90. marcello.thiry@gmail.com References.  (Ghezzi, Jazayeri & Mandrioli, 2003). Fundamentals of Software Engineering. 2nd ed. Pearson Education.  (ISO/IEC 25010, 2011). Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models.  (Martin, 1995). https://groups.google.com/forum/?hl=en#!topic/comp.object/WICPDcXAMG8.  (Meyer, 1997). Object-Oriented Software Construction. 2nd ed. Prentice Hall.  (Sommerville, 2015). Software Engineering. 10th ed. Pearson.

×