A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Princípios da Engenharia de Software. 2 Agenda O que são princípios? Princípios gerais Princípios de design.

Apresentações semelhantes


Apresentação em tema: "Princípios da Engenharia de Software. 2 Agenda O que são princípios? Princípios gerais Princípios de design."— Transcrição da apresentação:

1 Princípios da Engenharia de Software

2 2 Agenda O que são princípios? Princípios gerais Princípios de design

3 3 O que é um "princípio"? nir_resultados.aspx nir_resultados.aspx do Lat. principiu s. m., momento em que alguma coisa tem origem; início; começo; origem; causa primária; matéria constitutiva; agente natural; razão; base; regra que se funda num juízo de valor e que constitui um modelo para a ação; regra; lei fundamental; preceito moral; máxima; sentença; Filos., verdade fundamental sobre a qual se apoia o raciocínio;

4 4 Princípio noun 1 a fundamental truth or proposition serving as the foundation for belief or action. 2 a rule or belief governing ones personal behaviour. 3 morally correct behaviour and attitudes. 4 a general scientific theorem or natural law. 5 a fundamental source or basis of something. 6 Chemistry an active or characteristic constituent of a substance. ORIGIN Latin principium source, from princeps first, chief. Oxford English Dictionary

5 5 Princípios da Engenharia de Software Princípios são proposições genéricas e abstratas que descrevem propriedades desejáveis a processos e produtos de software

6 6 Princípios de Design Open Closed Principle (OCP) Autor: Bertrand Meyer Um módulo deve estar aberto para extensão porém fechado para modificação.

7 7 The Open Closed Principle (OCP) Em teoria: devemos escrever nossos módulos de modo que possam ser estendidos, sem a necessidade de serem modificados Na prática, para OO: Podemos adicionar funcionalidade usando herança, sem modificar o código fonte existente.

8 8 Princípios Discussões abstratas sobre princípios são importantes, porém eles precisam ser efetivamente aplicados em problemas concretos Princípios são gerais, ambíguos e não construtivos!

9 9 Aplicação de princípios em ES Princípios se tornam aplicáveis prática através de métodos e técnicas Exemplo: uso de herança

10 10 Métodos e Técnicas ? método: recomendação geral que governa the exa execução de alguma atividade rigoroso, sistemático, disciplinado técnica: um modo de realizar eficientemente alguma atividade de uma maneira que não é imediatamente óbvia mecânica, mais restrita

11 11 Aplicação de Princípios em ES Em geral, métodos e técnicas são empacotados em uma metodologia Em ES, uma metodologia se espalha por diversas atividades e agrega métodos, técnicas, ferramentas Exemplo: Metodologia OO Método de Jacobson, de Booch, de Rumbaugh Design OO, implementação OO

12 12 Metodologia e Ferramentas? Metodologia Um pacote de métodos e técnicas Ferramentas Dão suporte à aplicação de métodos, técnicas e metodologias

13 13 Princípios [Buschmann] Abstração Encapsulamento e Ocultamento de Informação Modularidade Separação de interesses Acoplamento e Coesão Suficiência, Completude, Primitiveness Separação entre Interface e Implementação Dividir para conquistar (divide-and-conquer)

14 14 Princípios [Ghezzi] Alguns princípios Rigor e formalidade Separação de interesses Modularidade Abstração Antecipação da mudança Generalidade Incrementalidade Foco Confiabilidade Capacidade de evolução

15 Alguns princípios Visão de Ghezzi

16 16 Rigor e formalidade Desenvolver software é uma atividade criativa mas, deve ser praticada com rigor Rigor é um complemento necessário à criatividade que aumenta nossa confiança em nossos produtos Formalidade é o rigor em mais alto grau processo de software dirigido e avaliado por leis matem á ticas

17 17 Rigor e formalidade O engenheiro deve saber compreender e identificar o nível de rigor necessário, a depender da dificuldade da tarefa ou se a mesma é crítica ou não. formalidade permite mecanização de processos programas são produtos formais

18 18 Exemplos: produto Análise matemática (formal) da correção de programas Derivação sistemática (rigorosa) de dados de teste

19 19 Exemplo: processo Documentação rigorosa de passos de desenvolvimento ajuda em contexto de reuso e manutenção, gerência de projetos e avaliação de pontualidade (timeliness), etc.

20 20 Separação de interesses (Separation of concerns - SoC) Para domar a complexidade, separe as questões e se concentre em uma de cada vez Princípio dá suporte à paralelização de esforços e separação de responsabilidades

21 21 Exemplo: produto Separação de interesses em documentos de requisitos (SRS) Mantenha os requisitos separados funcionalidade desempenho interface do usuário e usabilidade

22 22 Separação de interesses Authorization Synchronization Cache update Logging Contract validation Persistence

23 23 Separação de interesses tempo modelo em camada atributos de qualidade visões estrutural x comportamental fluxo de dados x fluxo de controle papéis gerenciais x técnicos X...

24 24 Subject-oriented programming

25 25 Modularidade Um sistema complexo pode ser dividido em unidades ou partes mais simples chamadas m ó dulos Um sistema que é composto por m ó dulos é chamado de modular Modularidade d á suporte a separa ç ão de interesses ao lidar com um m ó dulo, podemos ignorar detalhes acerca de outros m ó dulos

26 26 Modularidade (Critérios de Meyer para avaliação) decomposabilidade capacidade de decompor um sistema complexo ou de grande porte; composabilidade capacidade de compor um sistema a partir de um conjunto de módulos; compreensibilidade (a partir das partes) facilidade de compreender sistemas complexos continuidade proteção

27 27 Information hiding principle The designer of every module must select a subset of the modules properties as the official information about the module, to be made available to authors of client modules.

28 28 Modularidade Para alcançar composabilidade, decomposabilidade, facilidade de compreensão e modificabilidade Projete módulos com baixo acoplamento e alta coesão

29 29 Coesão e Acoplamento Cohesion and coupling Cada módulo deve ser altamente coeso (highly cohesive) o módulo é visto como "unidade" componentes internos a um módulo estão relacionados Módulos devem apresentar baixo acoplamento (low coupling) módulos possuem poucas interações com outros podem ser compreendidos separadamente

30 30 acoplamento e coesão acoplamento altocoesão alta, acoplamento baixo

31 31 Olhar slides #slides (Lecture 3 – Modularity) #slides

32 32 Abstração Abstração consiste em um processo no qual identificamos os aspectos essenciais de um fenômeno e ignoramos os detalhes ou aspectos não relevantes.

33 33 Abstração O tipo de abstra ç ão escolhido depende do prop ó sito Exemplo interface de um rel ó gio provê abstra ç ão sobre o funcionamento interno do rel ó gio para o prop ó sito de ajustar o hor á rio (usu á rio) outras abstra ç ões são necess á rias para dar suporte ao reparo do rel ó gio

34 34 Abstração O bom projetista de software deve ser capaz de efetuar abstrações mentais de elementos de um sistema complexo e incluir abstrações bem elaboradas como parte do projeto arquitetural.

35 35 Abstração Princípio básico para lidar com a complexidade. [Booch 91]

36 36 Abstração de processo Quando se faz estimativas de custo, podemos considerar apenas alguns fatores e ignorar outros Pode-se raciocinar sobre sistemas anteriores parecidos, ignorando as diferenças

37 37 Antecipação de mudança Habilidade de dar suporte à evolução de software requer antecipação de mudanças futuras com grande chance de acontecer Capacidade de evolução (evolvability)

38 38 Antecipação de mudança antecipação de mudança é a base de uma estratégia de modularização On the criteria to be used in decomposing systems into modules (Parnas 1972) (RE)LER antecipação de mudança é um princípio importante para alcançar evolutibilidade antecipação de mudança também interfere com potencial de reuso reuse as-is?

39 39 Generalidade Ao resolver um problema, tente descobrir se ele é uma instância de um problema mais geral cuja solu ç ão pode ser reusada em outros casos Avalie o grau de generalidade com o desempenho e custos esperados À s vezes, um problema mais geral é mais f á cil de ser resolvido que um caso especial

40 40 Incrementalidade Processo prossegue de modo ''stepwise" (incrementos sucessivos) Exemplos (processo) entregar subsistemas tão logo fiquem prontos feedback adiciona novas funcionalidades incrementalmente Lidar primeiro com funcionalidade, depois desempenho entregar um primeiro prot ó tipo e incrementalmente tornar o prot ó tipo em um produto

41 41 Basics es/softarch_20_modularity_reusability_1up.p df

42 42 The Art of Unix Programming Regras 1. Rule of Modularity: Write simple parts connected by clean interfaces. 2. Rule of Clarity: Clarity is better than cleverness. 3. Rule of Composition: Design programs to be connected to other programs. 4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines. 5. Rule of Simplicity: Design for simplicity; add complexity only where you must. 6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. 7. Rule of Transparency: Design for visibility to make inspection and debugging easier. 8. Rule of Robustness: Robustness is the child of transparency and simplicity. 9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. 10. Rule of Least Surprise: In interface design, always do the least surprising thing. 11. Rule of Silence: When a program has nothing surprising to say, it should say nothing. 12. Rule of Repair: When you must fail, fail noisily and as soon as possible. 13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time. 14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. 15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it. 16. Rule of Diversity: Distrust all claims for one true way. 17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

43 43 Axiomas da Engenharia de Software Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering better, cheaper, faster pick any two! functionality, scalability, performance pick any two! The longer a fault exists in software the more costly it is to detect and correct the less likely it is to be properly corrected Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more


Carregar ppt "Princípios da Engenharia de Software. 2 Agenda O que são princípios? Princípios gerais Princípios de design."

Apresentações semelhantes


Anúncios Google