Transferir como PDF, PPTX
Carregado porMarcello Thiry
Princípios da engenharia de software (marcello thiry)
O documento descreve 7 princípios da engenharia de software: 1. Rigor e formalidade para aumentar a confiabilidade dos resultados do desenvolvimento de software. 2. Separação de interesses para dividir um problema complexo em aspectos mais simples. 3. Modularidade para dividir um sistema complexo em unidades menores e mais simples.
Mais conteúdo relacionado
Semelhante a Princípios da engenharia de software (marcello thiry)
![[PARFOR 2017.1] ESW - Aula 01](https://cdn.slidesharecdn.com/ss_thumbnails/parforesw-aula01-170604082852-thumbnail.jpg?width=640&height=640&fit=bounds)
Princípios da engenharia de software (marcello thiry)
- 1.
- 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.
- 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. marcello.thiry@gmail.com Princípios formam abase 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. 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. marcello.thiry@gmail.com Um corpo depráticas, procedimentos e regras Sistema de métodos e princípios usados em uma determinada disciplina (Ghezzi, Jazayeri & Mandrioli, 2003)
- 8.
- 9. marcello.thiry@gmail.com Apoiam a aplicaçãode métodos, técnicas e metodologias (Ghezzi, Jazayeri & Mandrioli, 2003)
- 10.
- 11. marcello.thiry@gmail.com Ferramentas CASE Computer-Aided SoftwareEngineering Usadas em fases diferentes do desenvolvimento de software
- 12. marcello.thiry@gmail.com List of UnifiedModeling 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.
- 14. Rigor e formalidade Separaçãode 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.
- 16. marcello.thiry@gmail.com Desenvolvimento de software éuma atividade criativa, certo? Mas…
- 17.
- 18. marcello.thiry@gmail.com Leonardo da Vinci (1452-1519) “…Leonardoda 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. marcello.thiry@gmail.com Engenharia de softwaredeve 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. marcello.thiry@gmail.com Rigor permite repetitividade efaz 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. marcello.thiry@gmail.com Logo, rigor variaem 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. marcello.thiry@gmail.com Formalidade é rigorno 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.
- 24. marcello.thiry@gmail.com “Dividir e conquistar" (divideet impera) Identificando diferentes aspectos de um problema, nós podemos nos concentrar em cada um individualmente
- 25. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ Edsger_W._Dijkstra “The term separationof 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. marcello.thiry@gmail.com O único meiode 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. marcello.thiry@gmail.com Tempo Qualidades Visões Partes Fases, iterações, atividades…, Estruturalx Comportamental, Camadas ex: MVC Funcional, Eficiência, Usabilidade, confiabilidade, … modularidade Responsabilidades e habilidades Gerente de Projeto, Analista de Sistemas, Projetista, …
- 28.
- 29. Um sistema complexopode 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. marcello.thiry@gmail.com MAIOR Nível de abstração MENOR SistemaSubsistema Módulos
- 31. marcello.thiry@gmail.com Sistema modular Tratar ummódulo por vez, ignorando detalhes dos demais Modularidade aplicação da separação de interesses composto por módulos
- 32.
- 33.
- 34. marcello.thiry@gmail.com Nível de Subsistema Decomposição Mais altaabstração funcional Nível de sistema
- 35. marcello.thiry@gmail.com Hierarquia Top-down + abstrato - abstrato Nívelde Módulo Nível de Subsistema Decomposição Nível de sistema Mais alta abstração funcional
- 36. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ Niklaus_Wirth In 1971, NiklausWirth, 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. marcello.thiry@gmail.com Considerações TOP-DOWN + -Disciplinaló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. marcello.thiry@gmail.com Composição Nível mais baixo deabstração funcional Nível de Módulo
- 39. marcello.thiry@gmail.com Composição Nível mais baixo deabstração funcional Nível de Módulo Nível de Subsistema
- 40. marcello.thiry@gmail.com Hierarquia Bottom-up Composição + abstrato - abstrato Nívelde sistema Nível de Módulo Nível de Subsistema
- 41. marcello.thiry@gmail.com BOTTOM-UP Considerations + - Permiteantecipar 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.
- 43. marcello.thiry@gmail.com TOP-DOWN X BOTTOM-UP Ambaspermitem 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. marcello.thiry@gmail.com Módulo ACME Dados + Estruturas + Procedimentos + Funções Operacao_1 … Operacao_2… Operacao_3 … Operacao_4 … Operacao_N …
- 45. marcello.thiry@gmail.com https://en.wikipedia.org/wiki/ David_Parnas The concept ofinformation 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. marcello.thiry@gmail.com Conta getNumero : int depositarfloat 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. marcello.thiry@gmail.com Todos os elementosde 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. 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. 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.
- 51. marcello.thiry@gmail.com Responsibility 1 Human Resources Responsibility2 Payroll Department Responsibility 3 DBA team
- 52.
- 53.
- 54. marcello.thiry@gmail.com Cada módulo comunica-secom 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. 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. marcello.thiry@gmail.com Adicionar novos comportamentos paraatender às mudanças Aberto para extensão Mas sem modificar o código fonte dos módulos existentes Fechado para modificação
- 57. marcello.thiry@gmail.com A sacada… Módulos quedependem daqueles estendidos não são afetados pela extensão
- 58.
- 59.
- 60. marcello.thiry@gmail.com ALTO ACOPLAMENTO Organização não hierárquica Organização hierárquica BAIXOACOPLAMENTO dependência usa, chama
- 61. marcello.thiry@gmail.com E sobre coesão? ALTOACOPLAMENTO Organização não hierárquica BAIXO ACOPLAMENTO dependência usa, chama Organização hierárquica
- 62. marcello.thiry@gmail.com Sacou? ALTO ACOPLAMENTO Organização não hierárquica BAIXOACOPLAMENTO dependência usa, chama Organização hierárquica
- 63.
- 64. marcello.thiry@gmail.com Princípio da Inversãode Dependência Depender de abstrações, não de implementações concretions Martin*, 1995
- 65. marcello.thiry@gmail.com Módulo como umpacote... Oferece um espaço único de nome namespace Encapsula classes, interfaces e recursos Regras de acesso: visibilidade package
- 66. marcello.thiry@gmail.com Módulo como umabiblioteca... 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. marcello.thiry@gmail.com Módulo como umaclasse... Podem ser instanciadas várias vezes Podem implementar várias interfaces Classes e responsabilidade única Granularidade?
- 68.
- 69. marcello.thiry@gmail.com http://www.promo-wholesale.com/Upfiles/Prod_q/Solar- Powered-Desk-Calculator_20090641609.jpg identificar os aspectos essenciais deum contexto qualquer, ignorando características menos importantes ou acidentais Abstrair é…
- 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. marcello.thiry@gmail.com Abstração Caso especial deseparaçã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. marcello.thiry@gmail.com https://design2014level2.files.wordpress.com /2014/04/ceiling-fan-70914.gif Sistema de casa inteligente Sistemade vendas online Qual é o problema?
- 73. marcello.thiry@gmail.com Como estimar? Quais aspectosou fatores devemos considerar? Complexidade Quantidade Experiência da equipe Tecnologia usada Tipo de produto ... Quais deles são essenciais?
- 74.
- 75. Novas funcionalidades Software muda o tempo todo Melhoriasem funcionalidades existentes Correção de defeitos Melhorias no desempenho Adaptação devido a mudanças na legislação, no ambiente ex: DBMS, SO
- 76.
- 77. marcello.thiry@gmail.com Como antecipar prováveis mudançasfuturas? CUIDADO! Isso não é sobre tentar implementar o que os usuários TALVEZ precisem no futuro Isso é sobre estar preparado para mudar!
- 78. marcello.thiry@gmail.com Como melhorar a Manutenibilidade? Graude eficácia e eficiência com o qual o software pode ser modificado (ISO/IEC 25010, 2011)
- 79.
- 80. marcello.thiry@gmail.com Como apoiar amanutenibilidade? 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.
- 82.
- 83. marcello.thiry@gmail.com Se você pensaque já encontrou uma solução, pense novamente! Mas com uma mente mais aberta! Enquanto estiver resolvendo um problema...
- 84. marcello.thiry@gmail.com Tente verificar seexiste 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. *Keynote address: dataabstraction 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. Princípio da substituiçãode 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.
- 88.
- 89. marcello.thiry@gmail.com Entregar um sistemaem 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. 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.