Desenvolvimento Criativo

Em 1999, a NASA perdeu a Mars Climate Orbiter, uma sonda espacial que havia custado bem mais de cem milhões de dólares. O código não era mal escrito. O software de uma equipe fornecia seus números em unidades americanas, e o software de outra equipe os interpretava como unidades métricas. Cada parte funcionava isoladamente; a falha ocorreu na comunicação entre as pessoas. Esta unidade trata de como os programas são realmente criados: por grupos, para usuários, em ciclos repetidos, com erros identificados e corrigidos ao longo do processo.

A computação é uma atividade colaborativa. Trabalhar em equipe traz mais perspectivas, detecta mais erros e produz melhores programas do que trabalhar sozinho. Boa colaboração usa construção de consenso, comunicação clara e os pontos fortes de cada membro. Programação em par – duas pessoas em um computador, uma digitando e outra revisando – é uma prática comum. Na prova, você deve ser capaz de explicar como a colaboração melhorou um programa (mais ideias, menos bugs, testes mais amplos).

Uma inovação computacional é algo novo que tem um programa como parte essencial. Pode ser algo físico (um carro autônomo), um software (um editor de fotos) ou um conceito (compras on-line). Quando uma questão disser “inovação computacional”, qualquer um dos três serve.

Por que pessoas diferentes são importantes. Pessoas com experiências diferentes percebem problemas diferentes. Uma equipe que reúne perspectivas diferentes tem mais chances de evitar vieses, porque alguém perguntará “e quanto aos usuários como eu?”. Os desenvolvedores também conversam diretamente com os usuários: o que eles dizem ajuda a equipe a entender a finalidade do programa e para quem ele deve funcionar.

Habilidades e ferramentas. Boas equipes praticam comunicação, construção de consenso, resolução de conflitos e negociação. Ferramentas on-line, como documentos compartilhados e repositórios de código compartilhados, permitem que as pessoas deem feedback de qualquer lugar.

Exemplo resolvido. Dois alunos criam um aplicativo de questionário. Mei escreve o procedimento de pontuação enquanto Tom revisa cada linha à medida que ela digita; depois, Tom pede a cinco colegas para testar o app, e dois deles descobrem que uma resposta em branco causa travamento. Como a colaboração ajudou?

1. Tom revisa o código enquanto ele é digitado (programação em pares), o que pode identificar erros cedo.
2. Os colegas são usuários com hábitos diferentes; seus testes encontraram um caso que nenhum dos programadores havia pensado: a resposta em branco.
3. Cada benefício é nomeado e vinculado ao programa: "mais testadores encontraram o travamento da resposta em branco" ganha créditos onde "trabalho em equipe é bom" não ganha.

Exemplo resolvido: uma discordância. Dois colegas de equipe discordam: Sara quer um cronômetro em cada questão do questionário, e Li diz que um cronômetro deixará usuários nervosos preocupados. Qual é o melhor próximo passo?

• Sara e Li votam, e quem perde cede: é rápido, mas ignora os usuários.
• Cada um cria sua própria versão e eles nunca a compartilham: a equipe se divide.
• Eles consultam alguns usuários e depois chegam juntos a um acordo, por exemplo, um cronômetro que os usuários possam desativar.

A terceira opção é a construção de consenso: a decisão vem de evidências, e ambas as pessoas a aceitam.

Todo programa é escrito para um propósito – resolve um problema ou persegue um interesse. Um programa recebe entrada, processa-a e produz saída. Entradas podem vir de um usuário, dispositivo, arquivo ou outro programa; saídas podem ser visuais, auditivas, textuais ou um sinal para um dispositivo. Saber declarar o propósito de um programa e descrever claramente suas entradas e saídas é uma habilidade essencial (e parte da tarefa de desempenho Criar).

Alguns termos usados pela prova de forma precisa:

• Um programa (também chamado de software) é um conjunto de instruções que executa uma tarefa quando um computador o executa. Um segmento de código é uma parte de um programa.
• O comportamento de um programa é a maneira como ele age durante sua execução, geralmente descrita pela forma como um usuário interage com ele.
• Tanto a entrada quanto a saída podem ser táteis (toque, vibração), sonoras, visuais ou textuais.
• A saída geralmente depende da entrada e também pode depender do estado anterior: valores que o programa já armazena.

Você pode descrever um programa de modo geral (o que ele faz) ou com mais detalhes (o que ele faz e como suas instruções o fazem). Uma resposta escrita geralmente exige a segunda opção.

Exemplo resolvido. Um aplicativo contador de passos lê o movimento pelo sensor de movimento do celular, conta os passos e mostra o total do dia e um distintivo quando o usuário atinge 10,000.

O distintivo também mostra o estado anterior em ação: o mesmo passo recebido como entrada só gera um distintivo se o total armazenado tiver acabado de atingir a meta.

Um erro comum é dar a função como finalidade: "ele conta passos" diz o que o programa faz, não o problema que resolve.

Os programas são construídos por um processo iterativo, não em uma única linha reta: investigar o problema e os usuários, projetar (muitas vezes com um diagrama ou plano escrito), implementar em código e testar – depois repetir. Um problema grande é dividido em partes menores (decomposição). Comentários e nomenclatura clara documentam o projeto para que outros (e seu futuro eu) possam entendê-lo. O desenvolvimento é incremental – construa e teste uma pequena parte, depois adicione a próxima.

As fases comuns são investigação e reflexão, planejamento, construção de um protótipo (um modelo inicial funcional) e testes. A ordem pode ser planejada com antecedência ou mais exploratória, e uma equipe pode voltar a uma fase anterior a qualquer momento.

Exemplo resolvido: iterativo ou incremental? As duas palavras soam parecidas, e a prova faz distinção entre elas.

Um projeto real geralmente faz as duas coisas.

Investigando o que os usuários realmente precisam

Antes de escrever qualquer código, a pessoa desenvolvedora investiga o problema e as pessoas que usarão o programa. Algumas maneiras de fazer isso:

• pesquisas enviadas a potenciais usuários, que coletam dados de muitas pessoas rapidamente;
• entrevistas e observação direta de usuários realizando a tarefa manualmente;
• testes com usuários, nos quais as pessoas experimentam uma versão inicial enquanto a equipe observa;
• estudar soluções existentes para ver o que já funciona e o que frustra as pessoas.

Os resultados são transformados em um projeto. Dois artefatos fazem isso: uma lista de requisitos do programa dizendo exatamente o que o programa deve fazer, e diagramas representando o layout da interface do usuário – esboços mostrando quais controles aparecem onde e o que cada um faz quando usado. Projetar a interface em papel primeiro é mais barato do que descobrir após a codificação que os botões estão no lugar errado.

A especificação de um programa define seus requisitos. A fase de planejamento então estabelece como atendê-los. Ela pode incluir uma chuva de ideias, um roteiro visual (uma sequência de esboços do que o usuário vê), a divisão do programa em módulos e o planejamento de como ele será testado.

Eventos, e programas que aguardam

Nem todo programa é executado diretamente de cima para baixo. Um evento é gerado quando uma tecla é pressionada, o mouse é clicado, um programa é iniciado ou qualquer outra ação definida ocorre — e um evento pode alterar o fluxo de execução ao acionar o código associado a ele, chamado de tratador de eventos. Em muitos programas gráficos, os eventos aguardam em uma fila até que o tratador atual termine.

É por isso que um programa com interface gráfica pode parecer não estar fazendo nada: ele está esperando o próximo evento. A ordem em que esses eventos chegam depende das ações do usuário e de outras fontes de eventos, portanto o mesmo programa pode executar seus blocos em uma ordem diferente cada vez que é usado.

Esse estilo é chamado de programação orientada a eventos: as instruções são executadas quando são acionadas, e não uma após a outra a partir do início. O evento também fornece dados de entrada, como qual tecla foi pressionada.

Documentação e atribuição de autoria

A documentação de um programa é uma descrição escrita do que um segmento de código, evento, procedimento ou programa faz e de como foi desenvolvido. Os comentários são uma forma de documentação: são escritos para pessoas e não alteram a execução do programa. Nem todo ambiente de programação permite comentários, por isso a documentação às vezes fica em um arquivo separado.

Escreva a documentação ao longo de todo o desenvolvimento, e não no final: ela ajuda você e seus colegas de equipe a manter o programa correto.

O código de outra pessoa deve ter sua autoria reconhecida: informe na documentação de onde ele veio e o nome do autor original, se você souber. Isso também se aplica ao código escrito com um colega.

Um bug é um erro em um programa; depuração é o processo de encontrá-lo e corrigi-lo. A prova identifica quatro tipos:

• um erro de sintaxe viola as regras da linguagem, impedindo que o programa execute;
• um erro de tempo de execução causa travamento do programa durante a execução (ex.: divisão por zero);
• um erro de lógica permite que o programa seja executado, mas produz o resultado errado;
• um erro de transbordamento ocorre quando um número está fora do intervalo que o computador consegue representar.

Encontre bugs usando casos de teste com diferentes entradas, acrescentando instruções de impressão para ver os valores e acompanhando manualmente o código. Um depurador interrompe o programa em uma linha escolhida para que você possa examinar cada variável, e uma visualização, como um gráfico, pode facilitar a identificação de um padrão incorreto. Escolha as entradas de teste de forma criteriosa: elas devem demonstrar os diferentes resultados esperados nos extremos ou logo além deles — os valores mínimo e máximo que o programa deve aceitar e um valor imediatamente fora de cada extremo. Um programa que funciona com dados comuns frequentemente falha com uma lista vazia, um zero ou um valor imediatamente além do fim de um intervalo, portanto vale a pena testar essas entradas primeiro. Corrigir um bug de cada vez e testar novamente é o método confiável.

Exemplo resolvido: escolha de entradas de teste. Uma página de inscrição em um clube deve aceitar idades de 13 a 18. Os requisitos informam o resultado correto, para que você possa escolher entradas e dizer o que espera:

Cinco testes são suficientes: 12, 13, 15, 18 e 19. Se o código disser age > 13, somente o teste com 13 revela a falha; a idade 15 é aceita de qualquer maneira.

Habilidade de prova: ser capaz de nomear o tipo de erro e descrever uma estratégia de teste que o capturar — um tema recorrente em questões de múltipla escolha e tarefas Create.

Exemplo resolvido. Um programa destinado a imprimir a média de dois números, em vez disso, executa avg = a + b / 2. Ao traçar a ordem das operações, / é executado antes de +, portanto calcula $a+\tfrac{b}{2}$ em vez da média. Adicione parênteses para corrigir: avg = (a + b) / 2. Testar com $a=4,\ b=6$ confirma a correção — a linha com erro dá $4+3=7$, a linha corrigida dá $\tfrac{10}{2}=5$. Testar com entradas conhecidas é exatamente como você encontra e confirma um erro lógico.

Exemplo resolvido: identifique o erro.

Respostas escritas sobre seu próprio programa

A Seção II da prova dá 60 minutos para duas questões com quatro itens de resposta escrita, todos sobre o programa que você enviou para a tarefa de criação. Você vê seus próprios segmentos de código na sua Referência Personalizada do Projeto, portanto as respostas devem tratar do seu programa, e não de programas em geral. Imagine que este procedimento esteja no seu programa:

PROCEDURE Average(numbers)
{
   sum ← 0
   FOR EACH n IN numbers
   {
      sum ← sum + n
   }
   RETURN(sum / LENGTH(numbers))
}

Itens de provas anteriores pediram o seguinte.

1. Uma modificação que causa um erro de lógica e como o comportamento muda. "Se sum ← 0 for alterado para sum ← 1, o procedimento ainda será executado, mas cada total será uma unidade maior do que deveria. Average([2, 4]) retorna $3.5$ em vez de $3$."
2. Uma chamada que o procedimento aceita, mas trata incorretamente. "Average([]): a lista vazia é aceita, mas LENGTH(numbers) é 0, então a última linha divide por zero e um erro de execução interrompe o programa." Informe a chamada, o comportamento incorreto e o motivo: três coisas distintas.
3. Documentação para outra pessoa programadora. "Um comentário acima do procedimento dizendo que numbers não deve estar vazio. Outra pessoa programadora que reutilize Average saberá, assim, que deve verificar se a lista está vazia antes de chamá-lo."
4. Uma entrada inesperada. Indique uma entrada real para seu programa e diga o que ele de fato faz em seguida. Se ele rejeitar a entrada, diga qual linha faz isso.

Erros comuns. Descrever o que é uma modificação sem dizer o que muda quando o programa é executado. Fornecer uma chamada sem valores específicos para os argumentos. Responder sobre um procedimento diferente daquele indicado no enunciado.

Responda antes de ler as respostas abaixo.

1. Um aplicativo contador de passos conta passos e mostra um total diário para que os usuários possam atingir uma meta. Informe a finalidade do programa e uma de suas funções.
2. Classifique cada erro como sintaxe, lógica, execução ou transbordamento: (a) a ausência de um sinal de fechamento de agrupamento; (b) uma média calculada como sum / (count + 1); (c) a divisão por uma variável que é zero durante a execução do programa; (d) a adição de $1$ ao maior valor que uma quantidade fixa de bits pode armazenar.
3. Um procedimento retorna "pass" para pontuações de $60$ ou mais. Escolha quatro entradas de teste e explique suas escolhas.
4. Apresente um benefício da colaboração ao planejar um programa.
5. Diferencie o desenvolvimento iterativo do desenvolvimento incremental.
6. Apresente dois motivos para escrever comentários e outros tipos de documentação de programas.

1. Finalidade: ajudar os usuários a atingir uma meta diária de atividade. Função: por exemplo, acrescentar $1$ ao total cada vez que um passo é detectado ou exibir o total.
2. (a) Sintaxe; (b) lógica; (c) execução; (d) transbordamento.
3. $59$, $60$ e $61$ testam o limite, onde erros são mais prováveis; um extremo como $0$ ou $100$ verifica os limites das entradas válidas.
4. Perspectivas diferentes ajudam a encontrar erros e evitar vieses, de modo que o programa funcione para mais usuários (por exemplo, a programação em pares identifica erros mais cedo).
5. O desenvolvimento iterativo repete ciclos de planejamento, teste e aperfeiçoamento, revisando o programa após receber feedback. O desenvolvimento incremental constrói e testa o programa em pequenas partes, acrescentando uma parte funcional de cada vez.
6. Ela explica o que o código faz e por quê, para que outras pessoas (e o autor posteriormente) possam entendê-lo, mantê-lo e depurá-lo; também registra as fontes de código de terceiros.

• A avaliação inclui questões de múltipla escolha e o componente Criar, com respostas escritas no exame AP. Explique seu raciocínio claramente, não apenas o resultado.
• Conheça os benefícios da colaboração e como perspectivas diversas reduzem viés em um programa.
• Use vocabulário preciso (iterativo, incremental, requisitos do programa) ao descrever um processo de planejamento.
• Teste os extremos do intervalo de entrada e valores imediatamente além deles, e informe a saída esperada para cada teste.
• Dê e receba feedback de forma construtiva; dê crédito aos colaboradores e fontes.
• Divida um problema grande em módulos menores que uma equipe possa construir em paralelo.