Princípios da Engenharia de Software
Agenda



O que são princípios?
Princípios gerais
Princípios de design
2
O que é um "princípio"?

http://www.priberam.pt/dlpo/defi
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;
3
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
4
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
5
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.
6
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.
7
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
construtivos!
gerais,
ambíguos
e
não
8
Aplicação de princípios em ES

Princípios se tornam aplicáveis
através de métodos e técnicas

prática
Exemplo: uso de herança
9
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
10
Aplicação de Princípios em ES

Em geral, métodos e técnicas
empacotados em uma metodologia

Em ES, uma metodologia se espalha por
diversas atividades e agrega métodos,
técnicas, ferramentas

Exemplo: Metodologia OO


são
Método de Jacobson, de Booch, de Rumbaugh
Design OO, implementação OO
11
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
12
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)
13
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
14
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
16
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
processos

permite
mecanização
de
programas são produtos formais
17
Exemplos: produto


Análise matemática (formal) da correção de
programas
Derivação sistemática (rigorosa) de dados de
teste
18
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.
19
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
20
Exemplo: produto

Separação de interesses em documentos de
requisitos (SRS)

Mantenha os requisitos separados



funcionalidade
desempenho
interface do usuário e usabilidade
21
Separação de interesses
Authorization
Synchronization
Logging
Contract validation
Cache update
Persistence
22
Separação de interesses

tempo



atributos de qualidade
visões



modelo em camada
estrutural x comportamental
fluxo de dados x fluxo de controle
papéis

gerenciais x técnicos X...
23
Subject-oriented programming
24
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
25
Modularidade
(Critérios de Meyer para avaliação)

decomposabilidade


composabilidade



capacidade de compor um sistema a partir de um
conjunto de módulos;
compreensibilidade (a partir das partes)


capacidade de decompor um sistema complexo
ou de grande porte;
facilidade de compreender sistemas complexos
continuidade
proteção
26
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.
27
Modularidade

Para alcançar composabilidade,
decomposabilidade, facilidade de
compreensão e modificabilidade

Projete módulos com baixo acoplamento e alta
coesão
28
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
relacionados
módulo
Módulos
devem
apresentar
acoplamento (low coupling)


estão
baixo
módulos possuem poucas interações com outros
podem ser compreendidos separadamente
29
acoplamento e coesão
(a)
acoplamento alto
(b)
coesão alta, acoplamento baixo
30

Olhar slides

http://se.ethz.ch/teaching/ss2004/0250/index.html
#slides (Lecture 3 – Modularity)
31
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.
32
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
33
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.
34
Abstração

Princípio básico para lidar com a complexidade.
[Booch 91]
35
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
36
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)
37
Antecipação de mudança

antecipação de mudança é a base
estratégia de modularização

de uma
“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?
38
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
39
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
40
Basics

http://www.faqs.org/docs/artu/ch01s06.html

http://se.inf.ethz.ch/teaching/ss2006/0050/slid
es/softarch_20_modularity_reusability_1up.p
df
41
The Art of Unix Programming
Regras
1.
2.
3.
4.
5.
6.
7.
8.
9.
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.
10.
11.
12.
13.
14.
15.
16.
17.
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.
42
“Axiomas” da Engenharia de Software


Adding developers to a project will likely result in
further delays and accumulated costs
Basic tension of software engineering



The longer a fault exists in software



better, cheaper, faster — pick any two!
functionality, scalability, performance — pick any two!
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
43