O documento descreve 7 princípios da engenharia de software:
1. Rigor e formalidade para aumentar a confiabilidade dos resultados do desenvolvimento de software.
2. Separação de interesses para dividir um problema complexo em aspectos mais simples.
3. Modularidade para dividir um sistema complexo em unidades menores e mais simples.
5. marcello.thiry@gmail.com
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
(Ghezzi, Jazayeri & Mandrioli, 2003)
6. marcello.thiry@gmail.com
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...
7. marcello.thiry@gmail.com
Um corpo de práticas, procedimentos e regras
Sistema de métodos e princípios usados
em uma determinada disciplina
(Ghezzi, Jazayeri & Mandrioli, 2003)
12. marcello.thiry@gmail.com
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...
…
18. marcello.thiry@gmail.com
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
19. marcello.thiry@gmail.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
20. marcello.thiry@gmail.com
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?
21. marcello.thiry@gmail.com
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
22. marcello.thiry@gmail.com
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
25. marcello.thiry@gmail.com
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
26. marcello.thiry@gmail.com
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
29. 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
36. marcello.thiry@gmail.com
https://en.wikipedia.org/wiki/
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)
37. marcello.thiry@gmail.com
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
41. marcello.thiry@gmail.com
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
43. marcello.thiry@gmail.com
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)
45. marcello.thiry@gmail.com
https://en.wikipedia.org/wiki/
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)
46. marcello.thiry@gmail.com
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
47. marcello.thiry@gmail.com
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
48. 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
49. 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
54. marcello.thiry@gmail.com
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
65. marcello.thiry@gmail.com
Módulo como um pacote...
Oferece um espaço único de nome
namespace
Encapsula classes, interfaces e recursos
Regras de acesso: visibilidade package
66. marcello.thiry@gmail.com
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
67. marcello.thiry@gmail.com
Módulo como uma classe...
Podem ser instanciadas várias vezes
Podem implementar várias interfaces
Classes e responsabilidade única
Granularidade?
70. marcello.thiry@gmail.com
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
71. marcello.thiry@gmail.com
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, …
80. marcello.thiry@gmail.com
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
83. marcello.thiry@gmail.com
Se você pensa que já encontrou uma
solução, pense novamente!
Mas com uma mente
mais aberta!
Enquanto estiver resolvendo um problema...
84. marcello.thiry@gmail.com
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...
85. *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
86. 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
89. marcello.thiry@gmail.com
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
90. marcello.thiry@gmail.com
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.