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"?

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;

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?

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

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

Cache update

Logging

Contract validation

Persistence

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

(a) (b)

acoplamento alto coesão alta, acoplamento baixo

31

Olhar slides http://se.ethz.ch/teaching/ss2004/0250/index.html

#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

http://se.inf.ethz.ch/teaching/ss2006/0050/slides/softarch_20_modularity_reusability_1up.pdf

42

The Art of Unix ProgrammingRegras 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

“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