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
Top Related