Introdução à Programação Sistemática – Semana 3

A Semana 3 de Introdução ao Design Sistemático de Programas foi definitivamente MUITO mais conteúdo de vídeo do que eu estava acostumado antes, e posso dizer com segurança que, tendo começado a assistir aos vídeos da Semana 4, só vai ficar mais louco daqui em diante!

Portanto, a semana 3 da aula se concentrou principalmente em aprender como projetar dados e eu o guiarei por cada lição que aprendemos passo a passo da melhor maneira possível. Curiosamente, também descobri que escrever esses resumos também ajuda no meu próprio aprendizado, então espero que lê-los faça algo semelhante para aqueles de vocês que são meus colegas de classe!

Lição 1: Expressões cond

Fica claro para a turma nesta lição que o design de dados é um ponto de alavancagem no design de programas. Isso ocorre porque, quando cada um de nós projeta os dados, estamos tomando, consciente ou inconscientemente, decisões sobre como todas as funções que mais tarde operam nesses dados funcionarão.

Expressões condicionais, ou expressões cond, nos permitem programar o comportamento condicional quando há dois ou mais casos. Isso permite que as expressões cond sejam consideradas "condicionais multi-armadas".

Modelo de expressão cond padrão:

Para formar uma expressão de controle de qualidade:

Onde a expressão 1 é a pergunta e a expressão 2 é a resposta.

Usando o modelo de expressão cond para fazer um exemplo cond:

As regras para avaliar as condições são:

1. No Question/Answer pair? Signal an error.
2. Se a primeira pergunta não for um valor, avalie-a, substitua-a por seu valor. Substitua todo o cond por um novo cond em que a primeira pergunta é substituída por seu valor.
3. Se a primeira pergunta for um booleano que é avaliado como verdadeiro ou é uma instrução que é avaliada como else, substitua todo o cond pela primeira resposta.
4. Se a primeira pergunta for falsa, descarte o primeiro par de perguntas / respostas e substitua-o por um novo cond que não tenha o primeiro par de perguntas / respostas.
5. Como a ^1ª pergunta não é verdadeira ou falsa, sinalize um erro.

Notas adicionais desta lição:

[] são convenções visuais – Dr. Racket processa ()s e []s da mesma maneira, mas usar []s nos permite não ficar sobrecarregados.

Lição 2: Definições de dados

Em primeiro lugar, nesta lição, é explicado que uma definição de dados é um elemento de design. Em qualquer programa, há um domínio problemático, bem como dados. É o domínio dos dados pegar as informações que estão alojadas no domínio do problema e representá-las com dados. Essencialmente, as Definições de Dados descrevem como representamos informações como dados em nosso programa. Quando eu estava assistindo ao vídeo desta lição, isso realmente me lembrou de uma chave de cores que eu criaria no Excel – pegando um símbolo, ou cor, e definindo o que isso significa para o usuário, ou neste caso, o computador, para que ele possa interpretar o que o designer (eu) quis dizer.

Aqui está um exemplo de uma definição de dados do Dr. Racket:

Lesson 3: Atomic Non-Distinct Data Definitions

Esta lição forneceu um exemplo direto de como as definições de dados funcionam na prática, usando a premissa de projetar uma definição de dados para representar o nome de uma cidade.

Pontos a serem lembrados:

1. As partes de uma Definição de Dados estão na lista Receita
2. Existem diferentes tipos de definições de dados
3. Atômico significa que você não pode desmontá-lo e ainda mantê-lo qualquer significado no espectro das informações do problema.

Exemplo de uma definição de dados para atômico não distinto:

;; CityName is String
;; interp the name of a city
(define CN1 “Boston”)
(define CN2 “Vancouver”)

Os modelos controlados por dados foram abordados a seguir na lição e, para este mesmo exemplo, continuaríamos da seguinte forma:

Lição 4: HtDF com definição de dados

O objetivo desta lição foi nos ensinar como projetar uma função que consome dados não primitivos.

A partir desta lição, houve apenas algumas dicas rápidas que eu recolhi e gostaria de compartilhar com você:

1. No caso de expressões booleanas, os predicados devem terminar em um ?
2. Ao projetar com a Definição de dados, use seus exemplos como suas diretrizes.
3. Quando uma função tiver dois casos, aprimore seu modelo envolvendo uma instrução if ao redor do modelo
4. (Mais importante ainda!!) Não se esqueça de comentar seu esboço ao iniciar seu código!

Lição 5: HtDF X Estrutura de Ortogonalidade de Dados

Em primeiro lugar, quando vi o título desta lição, não tinha ideia do que seria - me orgulho de um vocabulário inglês bastante decente, mas ortogonalidade era um termo completamente novo para mim. Para aqueles de vocês que estão no mesmo barco, deixe-me explicar: Ortogonal significa simplesmente "principalmente independente". Neste caso, é importante porque o método HtDF é estruturado com a suposição de que os tipos de dados com os quais está trabalhando são ortogonais, de modo que, à medida que aprendemos mais tipos de dados, podemos implementá-los em nossas funções escritas anteriormente sem erros. Eu não testei essa teoria, veja bem, mas é o que eu entendo que seja com base nas lições fornecidas aqui!

O resto desta lição foi baseado na explicação deste gráfico de tipo de dados, que eu acho muito legal:

Este gráfico basicamente percorre todos os diferentes tipos de dados e nos prepara para as próximas lições que falam sobre Intervalo, Enumeração e Itemização.

Lição 6: Definições de dados de intervalo

As definições de dados de intervalo são usadas quando os números a serem representados estão dentro de um determinado intervalo. A chave para representar isso adequadamente são as nuances de inclusão e exclusividade. Por exemplo:

[1, 7] é inclusivo, o que significa que os números incluídos no intervalo são 1, 2, 3, 4, 5, 6, 7.

[1, 7), no entanto, é exclusivo, o que significa que os números incluídos neste intervalo são 1, 2, 3, 4, 5, 6.

Ao contrário das expressões cond, no caso de definições de dados de intervalo, [] e () produzem resultados diferentes.

Além disso, ao usar definições de dados de intervalo, é importante utilizar as duas regras a seguir:

1. Use o Gráfico de Dados para encontrar a receita mais apropriada. VÁ PARA O MAIS ESPECÍFICO.
2. Use a página de modelos de definições de dados para encontrar o modelo!

Lição 7: Definições de dados de enumeração

As enumerações são usadas ao criar uma função/programa que possui informações de domínio para um número fixo de dois ou mais valores distintos. Em um exemplo mais real, porque eu prefiro esses, pense na diferença entre rastrear notas como valores de letras ou como porcentagens. Os valores das letras são muito mais fáceis de representar, pois há menos e são definidos com precisão. No entanto, as porcentagens são inexatas e, portanto, não podem ser definidas com enumerações.

Os principais pontos a serem lembrados ao trabalhar com enumerações são que as enumerações usam a frase "um de" em sua definição de dados, e esses itens recuados na seção "um de" são conhecidos como subclasses. Além disso, os exemplos se tornam completamente redundantes nas enumerações, porque o exemplo literalmente repetiria a própria definição.

Lesson 8: Itemization Data Definitions

As definições de dados de detalhamento são utilizadas quando categorias com estados diferentes, com valores e tipos variados são necessárias para uma função/programa. Deve haver 2 ou mais subclasses, pelo menos uma das quais NÃO é um valor único e distinto.

É muito importante observar que, quando você estiver trabalhando com itens de dados mistos, proteja as subclasses adequadamente para que sua função possa ser executada. Isso é necessário porque uma subclasse que é booleana não pode ser avaliada da mesma forma que um Natural seria, portanto, se você não disser ao programa para verificar que tipo de dados ele está analisando, ele pode ficar confuso e seu programa irá quebrar. Para fazer isso, você configura um "guarda". Se você estiver protegendo um Number, por exemplo, coloque o seguinte antes de sua expressão de avaliação real: (number? c).

Isso é usado no Dr. Racket da mesma forma que um compilador em uma linguagem mais avançada entraria naturalmente e verificaria o tipo de dados. No entanto, no Dr. Racket, temos que fazer isso manualmente.

Lição 9: HtDF com intervalos

Testar ao usar Definições de Dados de Intervalo é um pouco mais complicado do que como fomos ensinados anteriormente a escrever cheques esperados no curso até agora. No caso de intervalos, certificar-se de testar os limites do intervalo, bem como um ponto médio, é a lição mais importante disseminada nesta seção.

Lição 10: HtDF com Enumeração

No que diz respeito ao teste com Enumerations, a chave aqui é testar pelo menos tantas expectativas de verificação quanto você tem subclasses. Se você não fizer isso, você não está cobrindo todas as suas possibilidades!

Também observado nesta lição é que você não precisa de definições de dados separadas para funções separadas, se elas residirem no mesmo programa. Você pode reutilizar suas definições de dados!

Lição 11: HtDF com Itemização

No caso do teste de itemização, infelizmente você precisa pensar um pouco mais para cobrir suas bases. É essencial testar todos os seus pontos de variação nas discriminações, bem como verificar quaisquer limites de definições adjacentes, para garantir que seu comportamento seja o esperado. É muito melhor para você testar minuciosamente e incluir quaisquer casos extremos que você possa imaginar, em vez de terminar seu programa, enviá-lo aos usuários e, em seguida, ter que corrigir retroativamente algo que eles descobriram que você estava "muito ocupado" para testar!

Lição 12: Estrutura do fluxo de informações

Identificar a estrutura de suas informações é uma etapa fundamental no design do seu programa, porque, como dissemos no início das notas desta semana, as escolhas que você faz na forma como você cria seus dados acabarão afetando as opções que você tem ao criar o código de toda a sua função/programa.

Encerrando a Semana 3

Então, nos fóruns de classe, muitas pessoas disseram que esta semana foi quando a aula "caiu na real". Francamente, eu discordo. Acho que a semana 3 em muitos MOOCs é quando há uma queda bastante acentuada, porque o que está sendo apresentado vai do conhecimento generalista e se torna um pouco mais aprofundado. No entanto, novamente, como mencionei, comecei a assistir aos vídeos da semana 4 e posso dizer com confiança que a semana 4 é onde vai "cair na real". Programas interativos? Isso é algo que me deixa animado.

Fique ligado na próxima semana e você pode ver se ainda estou aguentando a aula! Há o dobro do conteúdo de vídeo e tenho certeza de que o dever de casa vai ser intenso!