View
693
Download
1
Category
Preview:
Citation preview
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)
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)
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...
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)
marcello.thiry@gmail.com
Apoiam a aplicação de métodos, técnicas e
metodologias
(Ghezzi, Jazayeri & Mandrioli, 2003)
marcello.thiry@gmail.com
Ferramentas CASE
Computer-Aided Software Engineering
Usadas em fases diferentes do desenvolvimento
de software
marcello.thiry@gmail.com
List of Unified Modeling Language toolshttps://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
List of diagramming toolshttp://www.diagramming.org/
Data Modeling Toolshttp://toolsfordatabases.com/data-modeling-tools.html
Comparison of data modeling toolshttps://en.wikipedia.org/wiki/Comparison_of_data_modeling_tools
Test management toolshttps://en.wikipedia.org/wiki/Test_management_tools
List of GUI testing toolshttps://en.wikipedia.org/wiki/List_of_GUI_testing_tools
List of web testing toolshttps://en.wikipedia.org/wiki/List_of_web_testing_tools
Comparison of project management softwarehttps://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
(Ghezzi, Jazayeri & Mandrioli, 2003)
*
Do inglês “concerns”. Outras traduções: conceitos, responsabilidades*
marcello.thiry@gmail.comhttp://totallyhistory.com/wp-content/uploads/2012/03/Mona_Lisa_by_Leonardo_da_Vinci.jpg
Você conhece o
cara que pintou
isso, certo?
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
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
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?
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
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
marcello.thiry@gmail.com
“Dividir e conquistar"
(divide et impera)
Identificando diferentes
aspectos de um
problema, nós podemos
nos concentrar em cada
um individualmente
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 computerscience and computational physics.Among many contributions, he coinedthe phrase "structured programming"and discovered the algorithm for theshortest path in a graph, which nowbears 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
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
marcello.thiry@gmail.com
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
marcello.thiry@gmail.com
Sistema modular
Tratar um módulo por vez,
ignorando detalhes dos demais
Modularidade
aplicação da separação de interesses
composto por módulos
marcello.thiry@gmail.com
Nível de
Subsistema
Decomposição
Mais alta abstração
funcional
Nível de sistema
marcello.thiry@gmail.com
Hierarquia
Top-down
+ abstrato
- abstrato
Nível de
Módulo
Nível de
Subsistema
Decomposição
Nível de sistema
Mais alta abstração
funcional
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 fordesigning several programming languages (AlgolW, Pascal, Modula, Modula-2, Oberon, Oberon-2, Oberon-7) and for pioneering several classictopics in software engineering. In 1984 he wonthe Turing Award for developing a sequence ofinnovative computer languages. He designedthe simple programming language PL/0 toillustrate compiler design. It has formed thebasis for many university compiler designclasses.
http://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf
“Program Development by Stepwise Refinement” (1971)
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
marcello.thiry@gmail.com
Composição
Nível mais baixo
de abstração
funcional
Nível de
Módulo
Nível de
Subsistema
marcello.thiry@gmail.com
Hierarquia
Bottom-up
Composição
+ abstrato
- abstrato
Nível de sistema
Nível de
Módulo
Nível de
Subsistema
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
marcello.thiry@gmail.com
TOP-DOWN
ou
BOTTOM-UP?
http://ruccs.rutgers.edu/faculty/pylyshyn/cogscitalk/fish2.gif
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)
marcello.thiry@gmail.com
Módulo ACME
Dados
+
Estruturas
+
Procedimentos
+
Funções
Operacao_1 …
Operacao_2 …
Operacao_3 …
Operacao_4 …
Operacao_N …
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 theimportance of software structure. He developedthe concept of information hiding in modularprogramming, which is an important elementof object-oriented programming today. He isalso noted for his advocacy of precisedocumentation.
https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf“On the Criteria to be Used in Decomposing Software into Modules” (1972)
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
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
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
marcello.thiry@gmail.com
Responsibility 1
Human Resources
Responsibility 2
Payroll Department
Responsibility 3
DBA team
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
marcello.thiry@gmail.com
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
marcello.thiry@gmail.com
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
marcello.thiry@gmail.com
A sacada…
Módulos que dependem
daqueles estendidos não são
afetados pela extensão
marcello.thiry@gmail.com
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…
marcello.thiry@gmail.com
ALTO ACOPLAMENTO
Organização
não hierárquica
Organização
hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
marcello.thiry@gmail.com
E sobre coesão?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
Organização
hierárquica
marcello.thiry@gmail.com
Sacou?
ALTO ACOPLAMENTO
Organização
não hierárquica
BAIXO ACOPLAMENTO
dependência
usa, chama
Organização
hierárquica
marcello.thiry@gmail.com
Princípio da Inversão de Dependência
Depender de abstrações, não de
implementações concretions
Martin*, 1995
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
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
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?
marcello.thiry@gmail.com
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 é…
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
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, …
marcello.thiry@gmail.com
https://design2014level2.files.wordpress.com
/2014/04/ceiling-fan-70914.gif
Sistema de casa
inteligente
Sistema de
vendas online
Qual é o
problema?
marcello.thiry@gmail.com
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
marcello.thiry@gmail.com
Manutenção
de software
Evolução
do software
Corretiva
ADAPTATIVA
EVOLUTIVA
Preventiva
marcello.thiry@gmail.com
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!
marcello.thiry@gmail.com
Como melhorar a
Manutenibilidade?
Grau de eficácia e eficiência
com o qual o software pode
ser modificado(ISO/IEC 25010, 2011)
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
marcello.thiry@gmail.com
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/
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...
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...
*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
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
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.
Recommended