Princípios da engenharia de software (marcello thiry)

768 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

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.

×