Princípios da Engenharia de Software

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

O que é um "princípio"? http://www.priberam.pt/dlpo/definir_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;

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

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

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.

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.

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!

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

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

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

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

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)

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

Alguns princípios Visão de Ghezzi

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

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

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

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.

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

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

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.

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...

Subject-oriented programming

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

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

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.

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

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

acoplamento e coesão acoplamento alto coesão alta, acoplamento baixo

Olhar slides http://se.ethz.ch/teaching/ss2004/0250/index.html#slides (Lecture 3 – Modularity)

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.

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

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.

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

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

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)

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?

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

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

Basics http://www.faqs.org/docs/artu/ch01s06.html http://se.inf.ethz.ch/teaching/ss2006/0050/slides/softarch_20_modularity_reusability_1up.pdf

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.

“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