Princípios da Engenharia de Software

Apresentação em tema: "Princípios da Engenharia de Software"— Transcrição da apresentação:

1 Princípios da Engenharia de Software

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

3 O que é um "princípio"? 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 Princípio noun 1 a fundamental truth or proposition serving as the foundation for belief or action. 2 a rule or belief governing one’s 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 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 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 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 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 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 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 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 Metodologia e Ferramentas?
Um pacote de métodos e técnicas Ferramentas Dão suporte à aplicação de métodos, técnicas e metodologias

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 Princípios [Ghezzi] Alguns princípios Foco Confiabilidade
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 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 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 Exemplos: produto Análise matemática (formal) da correção de programas
Derivação sistemática (rigorosa) de dados de teste

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 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 Exemplo: produto Separação de interesses em documentos de requisitos (SRS) Mantenha os requisitos separados funcionalidade desempenho interface do usuário e usabilidade

22 Separação de interesses
Authorization Synchronization Logging Contract validation Cache update Persistence while we may have had a good understanding of different crosscutting concerns and their separation during the design phase, the implementation paid almost no attention to preserving the separation.

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 Subject-oriented programming

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 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 Information hiding principle
The designer of every module must select a subset of the module’s properties as the official information about the module, to be made available to authors of client modules.

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

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 acoplamento e coesão acoplamento alto coesão alta, acoplamento baixo

31 Olhar slides (Lecture 3 – Modularity)

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 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 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 Abstração Princípio básico para lidar com a complexidade. [Booch 91]

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 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 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 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 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 Basics http://www.faqs.org/docs/artu/ch01s06.html

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

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