Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, com método e organização graças às boas práticas e princípios exercitados no curso anterior; mas você talvez não se sinta ainda confortável em projetar programas usando técnicas ágeis, como o desenvolvimento guiado por testes (TDD). O objetivo deste curso é expor você aos princípios e práticas de desenvolvimento guiado por testes, tanto para modelar quanto para desenvolver aplicações e componentes de software, sem abandonar os conceitos e princípios de orientação a objetos aprendidos no curso anterior. De fato, pregamos que tais conceitos e princípios fortalecem o emprego do TDD no desenvolvimento ágil de software com mais qualidade. Este curso terá um grande foco em atividades hands-on, permitindo a você captar todos os aspectos práticos da técnica e facilitar a sua aplicação quando estiver projetando e desenvolvendo software de maneira ágil nos próximos cursos. Os conceitos de desenvolvimento de software com Java apresentados neste curso incluem o seguinte: revisão de testes de unidade; automação de testes; desenvolvimento guiado por testes; ciclo do TDD; refatoração de código de produção; ciclo de refatoração; uso de objetos stubs e mocks; boas práticas no TDD; modelagem de software por meio do TDD. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar, agora usando o TDD, versões modificadas e estendidas do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
TDD: Projeto Suficiente com Modelagem CRC
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
318 classificações
Instituto Tecnológico de Aeronáutica
318 classificações
Na lição
Semana 1
Olá, bem-vindo ao Curso 2 – Desenvolvimento de Software Guiado por Testes. Neste módulo você fará contato com os conceitos básicos de TDD. Ao final desta semana, você será capaz de: 1) entender como funciona o TDD e, principalmente, que o TDD é uma técnica poderosa de projeto e desenvolvimento de software; 2) será capaz de entender o papel fundamental da Refatoracão dentro do ciclo do TDD, permitindo a você alcançar um código de mais qualidade passo a passo e continuamente!
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] Olá, bem vindo ao curso sobre TDD.
Eu sou Clovis Fernandes,
na aula de hoje iremos falar sobre projeto suficiente com modelagem CRC.
É possível fazer projeto suficiente com modelagem CRC?
Essa é a ideia que nós iremos mostrar aqui,
mas iremos detalhar isso nas próximas aulas,
hoje só iremos mostrar que é possível.
No TDD, nós vimos que não se deve empregar o BDUF nem o NoDUF,
ou seja, eu não quero empregar nem fazer Big Design Up Front,
projeto grande antecipadamente, nem NoDUF,
No Design Up Front, projeto algum antecipadamente.
Eu não quero sem nada, eu quero o meio termo está certo?
O que seja suficiente.
O problema é que eu não sei direito o que é que é esse suficiente.
Na literatura aparece o EDUF,
ENOUGH Design Up Front, que é o design suficiente antecipadamente.
Quero lembrar para vocês que essa sigla, ela não é usada na literatura,
eu que estou colocando aqui apenas para efeitos didáticos,
agora o ENOUGH Design Up Front aparece vários textos da literatura.
O projeto suficiente, feito antecipadamente,
é para permitir dar início, com mais segurança,
ao que você precisa fazer, ou seja, você não vai olhar tudo,
mas você olha algumas coisas a mais, você antecipa algumas coisas, está certo?
Ou seja, ele vai dar a primeira direção com alguma visão do caminho,
que vai ser trilhado para resolver o seu problema,
para implementar a sua aplicação.
O resultado final, usando o EDUF,
é que eu deverei ter conjunto de informações suficiente para
eu começar com mais segurança, quando eu falo com mais segurança é,
o risco menor, o risco menor ter problemas no futuro com novos
requisitos ou mudanças de requisitos e que possa atrapalhar substancialmente
o que eu tinha feito anteriormente, é isso que eu vou me antecipar.
Esse projeto antecipado dependendo da aplicação,
ele pode ser feito dia, uma semana ou até duas semanas,
mas ele não deve se estender mais do que duas semanas.
A ideia, na verdade,
é fazer esse projeto antecipado, esse EDUF,
dentro do sprint ou da
iteração preliminar do processo ágil que você estiver empregando.
Essa é a ideia.
O EDUF, que é uma sigla que eu uso, está certo?
Tem nomes diferentes, por exemplo, ele tem esse aí: RDUF,
ROUGH Design Up Front, que traduzindo toscamente é,
projeto tosco ou preliminar antecipadamente,
ao contrário do EDUF o RDUF é uma sigla que aparece na literatura.
Aparace tanto o termo ROUGH Design Up Front, quanto o RDUF,
mas é com o mesmo significado do que eu dou no EDUF, os termos são equivalentes.
O outro, é termo que era usado antes para quando você fazia o NoDUF,
quase com pouco projeto, que é o Emergent Design, projeto emergente.
A diferença agora é que ele passa a ser empregado junto com esse conceito
de projeto suficiente ou projeto tosco preliminar, ou seja,
você tem uma base do seu projeto, aí sim, ou seja, você olhou pouquinho acima,
pouquinho mais a frente do projeto, sem se antecipar muito, está certo?
Então você já tem uma base melhor para fazer agora com
pouco mais de segurança, emergir.
Emergir significa vir, alguma coisa que vai aflorar na superfície.
Então meu projeto ele vai emergindo, ele vai aparecendo, ou seja,
eu faço preliminar, EDUF ou RDUF, está certo?
E ele se chama agora, poderia se chamar agora, esse projeto emergente que já
agora incorpora isso, ou seja, ele tem essa base,
esse olhar adicional que eu olho para ter mais condições,
condições suficientes para caminhar,
para desenvolver meu software com mais segurança.
Agora meu problema é: o quanto é suficiente projetar antecipadamente?
O paradoxo é que na modelagem ágil,
do seus princípios é que eu devo adiar ao máximo possível,
tomar decisões, porque ao tomar decisões eu estou enrijecendo.
Eu posso tomar decisões que ainda mantenham alguma coisa flexível,
mas outras vão enrijecer, de alguma forma é alguma coisa que enrijece.
Então, ao tentar procurar
estender o máximo possível suficiente, mas não tomar decisões,
muitas decisões antecipadamente, esse é o conflito que eu vou ter que resolver,
e isso vai servir para cada aplicação.
Isso vai estar na cabeça de cada desenvolvedor ou time de desenvolvedores,
não é uma coisa que tem uma regra que sai de repente
e está funcionando para todo mundo, não, isso não é dessa forma que ocorre.
O que é que eu preciso olhar antecipadamente?
Eu preciso ter mais informações sobre o contexto da aplicação,
quem vão ser os usuários, quais são os outros softwares que se
interconectam com essa aplicação que eu estou fazendo, está certo?
Eu posso estar fazendo uma aplicação para celular, cuja parte de pagamentos
vai ter que interagir com sistemas bancários ou de cartões, está certo?
Então eu preciso levantar os requisitos principais, eu não preciso ser completo,
levantar todos os requisitos, mas os principais, aqueles que são mais óbvios.
Eu preciso estar com essas informações,
aqueles que são mais problemáticos eventualmente.
Eu preciso ter alguma estrutura da arquitetura do meu sistema.
Eu vou ter software que vai funcionar telefones Iphone,
telefones Android, vai ter cada loja da
minha cadeira de lojas e das nuvens estar reunindo,
armazenando sobre tudo isso base de dados, eu vou ter então,
essa estrutura de subsistemas.
Essas informações, eu preciso ter o conjunto de informações
suficientes para isso, é esse o suficiente e aí eu não posso,
por exemplo, eu posso definir que vou usar algumas linguagens,
por exemplo, no Iphone eu vou ter que usar tipo de linguagem,
eu sou obrigado a usar aquela, ao ter dito que vou fazer
Iphone eu já tornei restrito tipo de linguagem para programar no Iphone.
No Android, eu vou usar Java ou alguma framework que me
ajude a fazer essa programação.
Então, eu vou tomando decisões que podem atrapalhar o futuro,
ou não, vai depender então, desse,
da aplicação e da experiência que o grupo, o time de desenvolvedores têm.
Então, como eu havia dito, né, uma sprint ou iteração de no máximo uma,
duas semanas, eu teria isso resolvido, está certo?
Eu vou obter o conjunto de informações suficientes para tocar o projeto sem
muitos sobressaltos, sem receio de que vai acontecer alguma
coisa lá mais para frente, porque ao não me demorar muito no projeto,
eu não vou engessar muitas coisas, eu não vou tomar muitas decisões,
além disso eu vou dar uma ênfase maior no, o quê fazer,
não no, como fazer e principalmente sem ter a pretenção de ser completo,
eu não vou ter essa pretenção de ser completo.
Agora eu não posso deixar de levantar algumas coisas e isso vai ser importante.
Vocês vejam que eu estou dando ênfase no what, o que,
ou seja, quando eu estiver fazendo meu projeto antecipado,
é muito importante eu saber o que fazer versus o como fazer.
O que, se eu consigo dirimir bem isso, ele vai mudar pouco no futuro,
o como, eu tenho uma miríade de formas de como fazer isso e aí estaria engessando,
tomando muitas decisões antecipadamente,
acarretando problemas posteriores.
Na prática, naquela parte de projeto que tem a ver com o
levantamento dos requisitos, eu posso usar casos de uso,
histórias de usuário e user stories, para definir os requisitos de sistema.
Então, por exemplo, eu posso estar usando os casos de uso,
que são definidos através da UML,
diagramas da UML, eu posso estar usando os cartões CRC, né, tá certo?
A modelagem CRC para definir a responsabilidade de colaborações,
e eu posso usar uma coisa que nós vamos usar mais para frente,
bastante, curso mais para frente, que são as User Story, está certo?
Que ali eu estou mostrando determinado formato de uma User Story.
Que todos eles vão me ajudar a definir os requisitos.
Obviamente, nesse meu exemplo, eu vou usar a modelagem
CRC e obter responsabilidades, colaborações e cartões CRC.
Obviamente eu também vou usar alguns diagramas UML de classes que vão me
ajudar a entender melhor, quer dizer, eu tenho as colaboração, os cartões,
etcetera, mas também vou usar isso.
Aí, suponha que eu vá fazer isso.
Eu vou usar a modelagem CRC como se fosse EDUF, está certo?
Quer dizer, projeto antecipado.
Vocês lembram quando eu fiz o projeto do sistema SAB,
eu tentei ser o mais completo possível lá, na parte de projeto,
que eu fazia análise inclusive até de como era a representação,
os códigos implícitos das responsabilidades que permitiam que
eu descobrisse novas responsabilidades, novas colaborações, está certo.
Aqui eu não preciso disso.
Eu vou fazer uma coisa mais simplificada, está certo.
Eu vou usar os cartões CRC ou as classes correspondentes, né, a cada cartão,
também associadas a esses diagramas de classe da UML.
Eu poderei fazer, como eu vou mostrar aulas no futuro,
refatorações, olhamos apenas o código de produção e o código de testes.
Está certo?
Então no sistema SAB, o sistema de automação da biblioteca que eu fiz no CRC,
eu vou apresentar para vocês o código da implementação deles, do SAB, e aí vocês,
vou usar isso também como pretexto para fazer as refatorações.
Obviamente muitas dessas refatorações
vai ajudar muito olhar as representações de relacionamento, de associações
entre as classes correspondentes do meu exemplo, que no caso vai ser o SAB.
Ele vai poder facilitar ou fazer com que você entenda melhor
a técnica de refatoração empregada à proposta dado momento.
O que é que nós estamos propondo aqui?
Nós vamos fazer projeto simplificado que corresponderia ao
que eu estava chamando de EDUF, Enough Design up Front,
projeto suficiente e simplificado antecipadamente, que vai ser
uma modelagem CRC pouquinho mais simples, que vai anteceder a modelagem ágil,
que no nosso caso na modelagem ágil, nós estaremos usando o TDD.
Então, com base nas responsabilidades,
eu vou começar a fazer a propor os testes, com os
testes eu vou construindo os códigos para as classes que eu estiver representando.
No meu caso do SAB, eu estaria trabalhando com classe biblioteca,
classe livro e classe usuário.
E eu estaria então, trabalhando com as responsabilidades correspondentes
e eu iria fazendo os testes e iria criando códigos diferentemente
do que eu fiz no meu exemplo.
No meu exemplo, eu fiz usando uma modelagem tradicional.
Eu fiz todo o projeto com a modelagem CRC,
implementei todo o código e só depois é que eu fui fazer o teste.
A única diferença é que eu fiz teste como se fosse usando
a técnica de cada teste que eu ia fazendo,
eu ia testando primeiro ele a primeiro,
para no final ter o conjunto de teste todos, está certo,
então eu fiz desta maneira misturando pouco as técnicas.
Mas, o que fica aqui, eu estou usando a modelagem CRC de
uma maneira simplificado para obter as responsabilidades,
as colaborações e com isso então eu posso definir os testes,
eu posso começar a fazer o ciclo do TDD de fazer o teste falhar,
construir teste que faça ele funcionar, refatorar e etc.
Então eu vou ter refatorações que eu faço no ciclo, que eu posso fazer no ciclo,
ou refatorações adicionais de melhoria da estrutura do meu código.
O que pode acontecer?
Eu fiz antecipado, simplesmente,
dado momento e aí começam a aparecer alguns novos requisitos,
ou mudanças de requisitos que o meu projeto TDD começa a ficar complexo.
O que é que eu faço então?
Eu volto a fazer alguma coisa também como se fosse uma EDUF, reprojeto simplificado.
Eu volto lá para o CRC para trabalhar como se fossem os cartões
CRC para aqueles novos requisitos para tentar esclarecer melhor.
Só que agora ao invés de levar uma semana ou duas, como a gente está propondo no
começo, nesse dado momento eu vou levar 1 hora, meia hora, 2 horas.
Pouco tempo que eu retrabalho,
eu volto para trabalhar na modelagem e volto de novo para o TDD.
Entendi o que eu tinha que fazer, aí eu volto para lá.
Entendeu?
Então eu posso fazer essa mistura, que eu sempre vou recorrer a esse
projeto ou reprojeto simplificado, toda vez que for necessário.
Eu faço uma vez, pouquinho mais longo, olho pouquinho mais para frente,
mas num dado momento eu posso recorrer de novo à técnica.
Isso é muito usual, na verdade.
Com isso, nessa aula,
você terá entendido que é possível fazer projeto suficiente com modelagem CRC.
Nós só não estamos mostrando como fazer, vai ser fruto das próximas aulas.
Nós iremos mostrar com base nas responsabilidades,
como é que eu vou criando os testes, para entrar no ciclo do TDD.
É isso que nós iremos fazer nas próximas aulas.
Obrigado.
[MÚSICA]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
