Princípios da engenharia de software (marcello thiry)

marcello.thiry@gmail.comPrincípios da Engenharia de Software

marcello.thiry@gmail.com http://ideas.scup.com/pt/files/2013/06/conte%C3%BAdo.jpg
1. Princípios, Métodos, Técnicas, Metodologias e Ferramentas
2. Rigor e formalidade
3. Separação de interesses
4. Modularidade
5. Abstração
6. Antecipação de mudanças
7. Generalidade
8. Incrementabilidade
Conteúdo.

marcello.thiry@gmail.com
http://www.ppp.uiuc.edu/newppp_2001/reso
urses/plant/graphics/slidejpgs/tap_root.jpg
Uma verdade básica, lei
ou suposição
Base para predição
e ação conduta
(Ghezzi, Jazayeri & Mandrioli, 2003)

Princípios formam a base
para métodos e técnicas
Um meio sistemático de fazer
alguma coisa
https://upload.wikimedia.org/wikipedia/c
ommons/thumb/8/8f/PSM_V10_D029_A
ncient_fire_making_methods.jpg/800px-
PSM_V10_D029_Ancient_fire_making_
methods.jpg

métodos e técnicas*
* Neste curso, estes dois termos
serão usados sem distinção
semântica
Como planejar...
Como testar...
Como projetar...
Como codificar...
Como elicitar requisitos
Como estimar...
...
Observação, entrevistas, workshops, questionários...

Um corpo de práticas, procedimentos e regras
Sistema de métodos e princípios usados
em uma determinada disciplina

Apoiam a aplicação de métodos, técnicas e
metodologias

Ferramentas CASE
Computer-Aided Software Engineering
Usadas em fases diferentes do desenvolvimento
de software

List of Unified Modeling Language tools
https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
List of diagramming tools
http://www.diagramming.org/
Data Modeling Tools
http://toolsfordatabases.com/data-modeling-tools.html
Comparison of data modeling tools
https://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Test management tools
https://en.wikipedia.org/wiki/Test_management_tools
List of GUI testing tools
https://en.wikipedia.org/wiki/List_of_GUI_testing_tools
List of web testing tools
https://en.wikipedia.org/wiki/List_of_web_testing_tools
Comparison of project management software
https://en.wikipedia.org/wiki/Comparison_of_project_management_software
List of build automation software
Configuration, Build, Integration, ...
https://en.wikipedia.org/wiki/List_of_build_automation_software
Application lifecycle management (ALM)
https://en.wikipedia.org/wiki/Application_lifecycle_management
Experimente...
…

Rigor e formalidade
Separação de interesses
Modularidade
Abstração
Antecipação de mudanças
Generalidade
Incrementabilidade
Princípios chave
*
Do inglês “concerns”. Outras traduções: conceitos, responsabilidades*

Desenvolvimento de
software é uma
atividade criativa,
certo?
Mas…

http://totallyhistory.com/wp-content/uploads/2012/03/Mona_Lisa_by_Leonardo_da_Vinci.jpg
Você conhece o
cara que pintou
isso, certo?

Leonardo da Vinci
(1452-1519)
“…Leonardo da Vinci employed a
variety of techniques ...”
“One of his most well-known paintings,
the Mona Lisa, displays some of the
techniques used by da Vinci in its
grandeur.”
http://www.davincilife.com

Engenharia de software deve ser
praticada sistematicamente
Rigor é um complemento necessário para
a criatividade que aumenta a confiança
nos resultados do desenvolvimento
Precisão, exatidão

Rigor
permite repetitividade e faz com as
equipes evitem problemas ocorridos
em projetos anteriores
Qual nível de disciplina conjunto de
regras nós precisamos para…
… produzir produtos com maior confiabilidade e
qualidade, sem deixar de controlar custos e
atender expectativas?

Logo, rigor varia em grau!
Nós precisamos usar a quantidade apropriada
http://mcx.sourceforge.net/upload/matlab_mmclab.pnghttp://www.mathworks.com/products/matlab/
http://4.bp.blogspot.com/-
IyHsfT1sB1A/UhTQdRV8opI/AAAAAAAABiI/H2R3X1OmAUg/s1600/V
NLIVES.NE-Simple-calculator-01.png

Formalidade é rigor no mais alto grau
Permite automação ferramentas
Uma prática formal pode ser verificada por
leis matemáticas
Métodos formais redes de petri, z, …
O código fonte é escrito numa linguagem
formal

“Dividir e conquistar"
(divide et impera)
Identificando diferentes
aspectos de um
problema, nós podemos
nos concentrar em cada
um individualmente

https://en.wikipedia.org/wiki/
Edsger_W._Dijkstra
“The term separation of concerns
was probably coined by Dijkstra in
his 1974 paper On the role of
scientific thought”
Edsger Wybe Dijkstra
(1930-2002)
A pioneer in the fields of computer
science and computational physics.
Among many contributions, he coined
the phrase "structured programming"
and discovered the algorithm for the
shortest path in a graph, which now
bears his name.
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
Paper "On the role of scientific thought" transcribed by Richard Walker:
https://en.wikipedia.org/wiki/Separation_of_concerns

O único meio de dominar a complexidade
de um projeto é separar os diferentes
interesses
Tempo
Qualidades
Visões
Partes
Habilidades
http://www.crochetville.com/community/uploads/monthly_06_2013/post-48806-0-42116700-1370920781.jpg

Tempo
Qualidades
Visões
Partes
Fases, iterações, atividades…,
Estrutural x Comportamental, Camadas ex: MVC
Funcional, Eficiência, Usabilidade, confiabilidade, …
modularidade
Responsabilidades e habilidades
Gerente de Projeto, Analista de Sistemas, Projetista, …

Um sistema complexo pode ser dividido em
unidades ou partes menores e mais simples
MÓDULOS
http://www.brickshop.co.uk/bricks-16-c.asp http://www.lego.com/ http://constructionweekonline.com//pictures/LEGO_Sungnyemun.jpg

MAIOR
Nível de abstração
MENOR
Sistema Subsistema Módulos

Sistema modular
Tratar um módulo por vez,
ignorando detalhes dos demais
Modularidade
aplicação da separação de interesses
composto por módulos

Mas tenha cuidado…
(Pressman, 2015)

Decomposição
Mais alta abstração
funcional
Nível de sistema

Nível de
Subsistema
Decomposição
funcional
Nível de sistema

Hierarquia
Top-down
+ abstrato
- abstrato
Nível de
Módulo
Nível de
Subsistema
Decomposição
Nível de sistema
funcional

Niklaus_Wirth
In 1971, Niklaus Wirth, wrote the
influential paper Program Development
by Stepwise Refinement. Today, we refer
to this approach as top-down design (or
top-down decomposition).
Niklaus Emil Wirth
(1934-)
A Swiss computer scientist, best known for
designing several programming languages (Algol
W, Pascal, Modula, Modula-2, Oberon, Oberon-
2, Oberon-7) and for pioneering several classic
topics in software engineering. In 1984 he won
the Turing Award for developing a sequence of
innovative computer languages. He designed
the simple programming language PL/0 to
illustrate compiler design. It has formed the
basis for many university compiler design
classes.
http://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf
“Program Development by Stepwise Refinement” (1971)

Considerações TOP-DOWN
+ -Disciplina lógica, que
organiza bem o pensamento
Permite equipes maiores
serem divididas entre os
subsistemas
Funciona muito bem para
pequenos projetos
Focado em requisitos
funcionais
Pensar um sistema como
uma única função topo
Decisões prematuras, menos
preparada para mudanças
Reuso é mais difícil
Posterga codificação e
testes
Aumenta chance de
dependências indesejáveis

Composição
Nível mais baixo
de abstração
funcional
Nível de
Módulo

Composição
Nível mais baixo
de abstração
funcional
Nível de
Módulo
Nível de
Subsistema

Hierarquia
Bottom-up
Composição
+ abstrato
- abstrato
Nível de sistema
Nível de
Módulo
Nível de
Subsistema

BOTTOM-UP Considerations
+ -
Permite antecipar
codificação e testes
Potencializa reuso, mais
fácil para incorporar e
testar módulos pré-
existentes
Mais preparado para
mudança
Sem alguma antecipação, pode
ser difícil ligar módulos
Foco não está em requisitos
funcionais resultados podem
não atender alguma
necessidade
Difícil desenvolver um
sistema completo bottom-up
Adequado para equipes
menores

TOP-DOWN
ou
BOTTOM-UP?
http://ruccs.rutgers.edu/faculty/pylyshyn/cogscitalk/fish2.gif

TOP-DOWN X BOTTOM-UP
Ambas permitem entender as relações entre
visões de alto e baixo nível abstração de um
sistema
Na prática, o design de sistemas maiores nunca é realmente top-down
Alguns ramos são projetados antes de outros
Projetistas reusam experiência e módulos
Projeto híbrido
Sua combinação potencializa entendimento, proteção da
informação e reuso
(Sommerville, 1995)

Módulo ACME
Dados
+
Estruturas
+
Procedimentos
+
Funções
Operacao_1 …
Operacao_2 …
Operacao_3 …
Operacao_4 …
Operacao_N …

David_Parnas
The concept of information hiding was
first described by Parnas in his paper On
the Criteria to be Used in Decomposing
Software into Modules (1972)
David Lorge Parnas
(1941-)
Canadian early pioneer of software engineering,
who was one of the first to recognize the
importance of software structure. He developed
the concept of information hiding in modular
programming, which is an important element
of object-oriented programming today. He is
also noted for his advocacy of precise
documentation.
https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
“On the Criteria to be Used in Decomposing Software into Modules” (1972)

Conta
getNumero : int
depositar float
sacar float
getSaldo : float
Encapsulamento + Ocultação de informação
IMPLEMENTAÇÃOINTERFACE
http://thumbs.dreamstime.com/t/manikin-keep-distance-
orange-cartoon-character-red-text-30647683.jpg
Módulos cliente dependem somente da interface
Continuidade: pequenas mudanças tem efeitos localizados
Aumenta reusabilidade e capacidade de substituição
Proteção: isolamento dos defeitos
(Meyer, 1988-1997)
Information Hiding

Todos os elementos de um módulo
devem estar altamente relacionados
Coesão: medida interna
OBJETIVO: ALTA COESÃO
Todos os elementos
compartilham o mesmo objetivo
Entendimento de um módulo de
modo isolado
Conta
getNumero : int
depositar float
sacar float
getSaldo : float

Princípio da responsabilidade única
Martin*, 1995
*Robert Martin é conhecido como Uncle Bob
http://wordlesstech.com/wp-content/uploads/2010/12/swiss-army-knife-giant-elite1.jpg
https://lostechies.com/gabrielschenker/2009/01/21/real-
swiss-don-t-need-srp-do-they/
By Gabriel Schenker

Motivo para mudar
PARTE ÚNICA de toda a funcionalidade
Encapsulamento coesão
Antecipar como a classe irá evoluir
Uma classe deveria ter um único
motivo para mudar
RESPONSABILIDADE

Responsibility 1
Human Resources
Responsibility 2
Payroll Department
Responsibility 3
DBA team

Mas seja cuidadoso...

Cada módulo comunica-se com a menor
quantidade possível de outros módulos
Acoplamento: medida externa
Dependência entre módulos
OBJETIVO: BAIXO ACOPLAMENTO
Reduzindo o acoplamento
+ Entendimento
Meyer, 1988-1997
+ Testabilidade
+ Modificabilidade
+ Reusabilidade

Princípio aberto-fechado
Meyer, 1988-1997
ABERTO = disponível para extensão
FECHADO = disponível para uso por
outros módulos
Módulos deveriam estar ABERTOS
e FECHADOS

Adicionar novos comportamentos
para atender às mudanças
Aberto para extensão
Mas sem modificar o código fonte
dos módulos existentes
Fechado para modificação

A sacada…
Módulos que dependem
daqueles estendidos não são
afetados pela extensão

Mas como?
Abstrações
Herança
Interfaces
Redefinição
Polimorfismo

https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle
https://sklivvz.com/posts/say-no-to-the-openclosed-pattern
http://blogs.msmvps.com/jonskeet/2013/03/15/the-open-closed-principle-in-review/
http://blog.8thlight.com/uncle-bob/2013/03/08/AnOpenAndClosedCase.html
http://codecourse.sourceforge.net/materials/The-Importance-of-Being-Closed.pdf
Interesting reading…

ALTO ACOPLAMENTO
Organização
não hierárquica
Organização
hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama

E sobre coesão?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
Organização
hierárquica

Sacou?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
Organização
hierárquica

Logo…
dependência
usa, chama

Princípio da Inversão de Dependência
Depender de abstrações, não de
implementações concretions
Martin*, 1995

Módulo como um pacote...
Oferece um espaço único de nome
namespace
Encapsula classes, interfaces e recursos
Regras de acesso: visibilidade package

Módulo como uma biblioteca...
Contém um ou mais pacotes
Pedaço de código sem estado interno e um
API pública
Em Java, os limites de um JAR não ficam
claros depois de sua liberação no class path

Módulo como uma classe...
Podem ser instanciadas várias vezes
Podem implementar várias interfaces
Classes e responsabilidade única
Granularidade?

http://www.promo-wholesale.com/Upfiles/Prod_q/Solar-
Powered-Desk-Calculator_20090641609.jpg
identificar os
aspectos essenciais
de um contexto qualquer,
ignorando características
menos importantes ou acidentais
Abstrair é…

Mas tenha cuidado…
Você deve
desconsiderar apenas
aqueles detalhes que
podem ser realmente
ignorados
O que
fazer
aqui???
http://www.convio.com/common-ground/assets/crazy_sm.jpg

Abstração
Caso especial de separação de interesses
Técnica para dominar a complexidade
Aspectos importantes x Detalhes menos importantes
A seleção de quais aspectos são importantes e quais
podem ser ignorados depende do observador e do
problema observado
Modelagem, diagramação, prototipação,
equações, …

https://design2014level2.files.wordpress.com
/2014/04/ceiling-fan-70914.gif
Sistema de casa
inteligente
Sistema de
vendas online
Qual é o
problema?

Como estimar?
Quais aspectos ou fatores devemos considerar?
Complexidade
Quantidade
Experiência da equipe
Tecnologia usada
Tipo de produto
...
Quais deles
são essenciais?

Novas
funcionalidades
Software
muda o
tempo todo
Melhorias em
funcionalidades
existentes
Correção
de defeitos
Melhorias no
desempenho
Adaptação devido a
mudanças na legislação, no
ambiente ex: DBMS, SO

Manutenção
de software
Evolução
do software
Corretiva
ADAPTATIVA
EVOLUTIVA
Preventiva

Como antecipar prováveis
mudanças futuras?
CUIDADO! Isso não é sobre tentar
implementar o que os usuários TALVEZ
precisem no futuro
Isso é sobre estar
preparado para mudar!

Como melhorar a
Manutenibilidade?
Grau de eficácia e eficiência
com o qual o software pode
ser modificado
(ISO/IEC 25010, 2011)

Como apoiar a manutenibilidade?
Ferramentas de gerência de configuração
Controle de versão
Gerência de mudanças
Integração
Repositórios
Componentes reutilizáveis
Documentação

Integration
tools
http://buildbot.net
http://jenkins-ci.org/
http://git-scm.com/
Version control
tools
https://travis-ci.org/
http://subversion.tigris.org/
https://github.com/
Change
Management
tools
https://www.mantisbt.org/
http://www.accurev.com/
…… …
http://www.redmine.org/

Se você pensa que já encontrou uma
solução, pense novamente!
Mas com uma mente
mais aberta!
Enquanto estiver resolvendo um problema...

Tente verificar se existe uma instância de um
PROBLEMA MAIS GENÉRICO
Algumas vezes, um problema genérico é mais fácil
de resolver do que um caso especial
Talvez, a solução possa ser aplicada em
outros casos
Você precisa considerar o
custo/benefício entre
generalidade, desempenho e custo
Mas...
Enquanto estiver resolvendo um problema...

*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.acm.org/citation.cfm?id=62141
Se um objeto X do tipo T tem um método P
que se comporta de uma forma
O objeto Y do tipo S, onde S é um subtipo
de T, deveria ter o mesmo método P se
comportando da mesma forma
Princípio da substituição de Liskov
Liskov, 1987

Princípio da substituição de Liskov
Liskov, 1987
*Keynote address: data abstraction and hierarchy, OOPSLA '87
http://dl.acm.org/citation.cfm?id=62141
Tudo está na semântica!
Depender mais das interfaces do
que de tipos de classe

Grow, Don't Build
http://cdn.shopify.com/s/files/1/0070/7032/files/The_10_Strategy.jpg?754

Entregar um sistema em partes para obter feedback contínuo dos usuários e
adicionar novas features de modo incremental
Entregar um protótipo inicial e então adicionar novas features de modo
incremental para transformar o protótipo em produto
O processo avança em passos sucessivos incrementos
FeedbackEntrega FeedbackEntrega Entrega
Exemplos processo
Desenvolvimento
usuário
Inc #1 Inc #2 Inc #N
usuário usuário usuário
Desenvolvimento Desenvolvimento

References.
 (Ghezzi, Jazayeri & Mandrioli, 2003). Fundamentals of Software Engineering. 2nd ed. Pearson Education.
 (ISO/IEC 25010, 2011). Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — System and software quality models.
 (Martin, 1995). https://groups.google.com/forum/?hl=en#!topic/comp.object/WICPDcXAMG8.
 (Meyer, 1997). Object-Oriented Software Construction. 2nd ed. Prentice Hall.
 (Sommerville, 2015). Software Engineering. 10th ed. Pearson.

Princípios da engenharia de software (marcello thiry)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Princípios da engenharia de software (marcello thiry)

Semelhante a Princípios da engenharia de software (marcello thiry) (20)

Mais de Marcello Thiry

Mais de Marcello Thiry (11)

Último

Último (20)

Princípios da engenharia de software (marcello thiry)