[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]
