Glossário de EDA

Question 2

abstracção

abstraction

Answer 2

Processo mental que consiste em escolher ou isolar um aspecto determinado de um estado de coisas relativamente complexo, a fim de simplificar a sua avaliação ou classificação, ou para permitir a comunicação do mesmo. [Antônio Houaiss et al., Dicionário Houaiss da Língua Portuguesa, 1.ª reimpressão com alterações, Objetiva, Rio de Janeiro, 2004.] A abstracção é um conceito fundamental em informática. Muitos dos artefactos das linguagens de programação têm como objectivo possibilitar a modularização e o encapsulamento, que são ferramentas essenciais para facilitar a abstracção.

Question 3

algoritmo

algorithm

Answer 3

1. Uma sequência pormenorizada de acções a executar para realizar alguma tarefa [Foldoc]. 2. Uma sequência finita de instruções bem definidas e não ambíguas, cada uma das quais pode ser executada mecanicamente num período de tempo finito e com uma quantidade de esforço finita [Wikipédia]. 3. Um conjunto finito de regras que fornece uma sequência de operações para resolver um tipo específico de problema e que tem as seguintes características: finitude, definitude, entradas, saídas e eficácia [Donald Knuth, The Art of Computer Programming, Volume 1: Fundamental Algorithms, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973]. (Nota: Donald Knuth é uma das maiores figuras da ciência da computação.)

Question 4

ciclo
* controlado por contador
* controlado por guarda
ciclo infinito
* controlado por colecção

loop
count-controlled loop
condition-controlled loop
infinite loop
collection-controlled loop

Answer 4

Um ciclo é uma sequência de instruções que é especificada uma única vez para ser executada várias vezes sucessivamente. O código dentro do ciclo (o seu passo ou a sua acção) é executado um determinado número de vezes (ciclos controlados por contador), uma vez para cada membro de uma colecção de itens (ciclos controlados por colecção), até que uma dada condição (a sua guarda) se verifique (ciclos controlados por guarda) ou indefinidamente (ciclos infinitos). [Wikipédia] Cada ciclo consiste usualmente num conjunto de instruções que o precede, a inicialização, numa guarda implícita ou explícita, que controla a duração do ciclo, sendo avaliada a cada passo do ciclo, e num passo, que é executado repetidamente e que pode normalmente ser decomposto numa acção e num progresso. Em ciclos controlados por contador e em ciclos controlados por colecção é típico que a guarda e o progresso sejam implícitos e que a inicialização se relacione apenas com a acção a realizar, e não com o progresso do ciclo. Usualmente os ciclos têm uma variável de controlo. Esta variável está envolvida no progresso do ciclo.

As instruções iterativas do C (o while, o do-while e o for) suportam directamente apenas ciclos controlados por guarda. No entanto, qualquer tipo de ciclo pode ser escrito à custa dessas instruções (aliás, bastaria apenas uma delas para se poder escrever qualquer tipo de ciclo).

Exemplo de ciclo controlado por guarda em C:

exemplo de ciclo controlado por guarda para calcular numero de dígitos

Exemplo de ciclo controlado por contador em C:

exemplo de ciclo controlado por contador para calcular factorial

Exemplo de ciclo infinito em C:

exemplo de ciclo controlado infinito para obter do utilizador valor cumprindo condição

Exemplo de ciclo controlado por colecção em C:

exemplo de ciclo controlado por colecção para somar os itens de uma lista

Question 5

código
código fonte

code
source code

Answer 5

O nome genérico código (ou código fonte) aplica-se a qualquer troço de programa escrito numa qualquer linguagem de programação legível por humanos.

Question 6

expressão

expression

Answer 6

Uma expressão numa linguagem de programação é uma combinação explícita de valores, constantes, operadores e funções que é interpretada de acordo com as regras de precedência e associatividade particulares dessa linguagem, resultando num valor calculado. A este processo, tal como no caso das expressões matemáticas, chama-se cálculo. O valor pode ser de vários tipos, por exemplo, um valor numérico, uma cadeia de caracteres ou um valor booleano. Por exemplo, 2 + 3 é uma expressão cujo valor calculado é 5. Uma variável é também uma expressão, uma vez que denota um valor em memória. Assim, se x for uma variável, então x será também uma expressão, tal como x + 2. Um exemplo de uma expressão relacional é 4 ≠ 4, cujo valor é falso. Uma função, embora isso se considere uma má prática, pode ter efeitos laterais, coisa que também pode acontecer com alguns operadores (e.g., =, += ou ++, no C e nas linguagens dele derivadas). O cálculo do valor de uma expressão pode, por isso, em alguns casos, alterar o estado do programa. [Wikipédia] (Nota: Em Snap!, uma expressão consiste sempre na invocação de um repórter, passando-lhe os respectivos argumentos, que são também eles expressões.)

Exemplo de uma expressão em C:

> factorial(3 + 2) // uma expressão

Question 7

fluxo de controlo

control flow

Answer 7

O fluxo de controlo consiste na sequência exacta das instruções que são executadas por um programa. Imagine uma linha a unir as instruções que vão sendo executadas num programa. Quando passar por uma instrução de selecção, a linha seguirá apenas por um dos seus ramos. Quando atinguir um ciclo, a linha dará um determinado número de voltas. Quando uma rotina for invocada, a linha ligar-se-á à primeira instrução dessa rotina. Quando a rotina retornar, a linha retornará ao percurso que estava a percorrer antes da invocação da rotina. Essa linha representa um dado fluxo de controlo. O fluxo de controlo ao longo de um programa é tipicamente diferente consoante as circunstâncias que influenciam a sua execução (respostas do utilizador, conteúdos de ficheiros lidos pelo programa, etc.).

Question 8

função

function

Answer 8

Um dos tipos de rotina. As funções têm como objectivo calcular e devolver um ou vários valores. As funções não têm, ou não devem ter, efeitos laterais, i.e., não devem agir sobre o mundo que as circunda. Quando as funções não têm efeitos laterais, também se dizem funções puras. Quando as funções devolvem valores booleanos recebem o nome de predicados. Quando as funções devolvem valores booleanos, chamam-se também predicados.

Em C, a palavra «função» é usada no sentido de rotina. Para evitar ambiguidades, sempre que pretendermos referir-nos ao mecanismo do C que suporta a noção de rotina usaremos a expressão «função C».

Exemplo de uma função em C:

int factorial(int n) { if (n == 0) return 1; return n * factorial_of(n - 1); }

Exemplo de um predicado (e por isso também uma função) em C:

int is_odd(int n) { return n % 2 != 0; }

Question 9

instrução de controlo de fluxo

control flow statement

Answer 9

Uma instrução de controlo de fluxo é um tipo específico de instrução que permite controlar o fluxo de controlo de um programa. As instruções de condicionais, as instruções de selecção e os vários tipos de instruções iterativas são instruções de controlo de fluxo.

Em C existem diversas instruções de controlo de fluxo:

• A instrução condicional:

> if (guarda) instrução

• A instrução de selecção:

> if (guarda) instrução1 else instrução2

• A instrução de comutação:

> switch (expressão) { case valor1: instruções1 break; case valor2: instruções2 break; ... case valorn: instruçõesn break; default: instruções break; }

• O ciclo while:

> while (guarda) passo

• O ciclo do-while:

> do passo while (guarda);

• O ciclo for:

> for (inicialização; guarda; progresso) acção

• As instruções de retorno (return), quebra (break), continuação (continue) e salto incondicional (goto, não usar!).

Question 10

instrução iterativa
instrução de iteração

iteration statement

Answer 10

Uma instrução iterativa é um tipo específico de instrução de controlo de fluxo que permite construir ciclos de uma forma estruturada. Há vários tipos possíveis de instruções iterativas. Por exemplo:

• repete [o passo] [n] vezes
• até que 〈a guarda〉, repete [o passo]
• enquanto 〈a guarda〉, repete [o passo]
• repete [o passo] até que 〈a guarda〉
• repete [o passo] enquanto 〈a guarda〉
• repete [o passo] para sempre
• para (i) de (o início] a (o fim), repete [a acção]
• para cada (o item) em [a lista], repete [a acção]

Question 11

linguagem
* de programação

language
programming *

Answer 11

Uma linguagem de programação é uma linguagem artificial concebida para comunicar instruções a uma máquina, em particular a um computador. As linguagens de programação podem ser usadas para criar programas que controlam o comportamento de uma máquina e/ou para exprimir algoritmos com precisão. [Wikipédia]

Ver:

• Comparação entre linguagens (Wikipédia)
• Comparação entre linguagens (Rosetta Code)
• «Olá mundo!» em várias linguagens
• Cálculo do máximo divisor comum em várias línguagens
• Árvore genealógica das linguagens

Question 12

parâmetro

parameter
formal argument

Answer 12

Uma variável (ou possivelmente uma constante, em certas linguagens de programação) local a uma rotina que é inicializada com o valor do argumento correspondente em cada invocação dessa rotina. (Nota: no Snap! os parâmetros são conhecidos por entradas.)

Question 13

passagem de argumentos

argument passing

Answer 13

Acto ou efeito de usar os valores dos argumentos para inicializar os correspondentes parâmetros quando ocorre uma invocação de uma rotina e a sua subsequente execução. A forma mais comum de passar argumentos a uma rotina é a passagem de argumentos por valor.

O Snap! usa passagem de argumentos por valor:

Question 14

procedimento

procedure

Answer 14

Um dos tipos de rotina. Os procedimentos agem sobre o estado do mundo os rodeia, podendo alterá-lo. O objectivo de um procedimento é tipicamente que essas alterações ocorram. A essas alterações é usual chamar-se efeitos laterais, mesmo quando a sua ocorrência é a razão de ser do procedimento. [c2.com]

Em C, a palavra «função» é usada no sentido de rotina. Para evitar ambiguidades, sempre que pretendermos referir-nos ao mecanismo do C que suporta a noção de rotina usaremos a expressão «função C».

Exemplo de um procedimento em C:

void swap(int a[], int i, int j) { const int original_a_i = a[i]; a[i] = a[j]; a[j] = original_a_i;
}

Question 15

programa
* de computador

program
computer *

Answer 15

Um programa de computador (ou simplesmente programa ou aplicação) é uma sequência de instruções concebida para desempenhar uma dada tarefa com um computador. Um computador requer um programa para funcionar, executando tipicamente as instruções do programa num processador central. Um programa pode ter uma forma executável, que o computador usa directamente para executar as instruções, e uma forma legível por humanos, a partir da qual a forma executável pode ser obtida por tradução (conhecida por compilação). A forma legível por humanos está tipicamente escrita numa linguagem de programação de alto nível. A forma executável directamente pelo computador está expressa em linguagem máquina. Há linguagens de programação de alto nível concebidas para serem interpretadas. Ou seja, os programas expressos nessas linguagens não se destinam a serem compilados, mas sim a serem interpretados por um outro programa, que os executa. O código fonte de um programa é muitas vezes escrito por programadores. As linguagens de programação podem classificar-se como suportando um ou mais paradigmas de programação, sendo que três dos principais paradigmas são a programação imperativa, a programação funcional e a programação declarativa. [Wikipédia] (Nota: Ao contrário do que é feito na Wikipédia, consideramos que programação declarativa e programação lógica expressam o mesmo conceito e que a programação funcional não é uma forma de programação declarativa. Estas definições não são consensuais. Ver, por exemplo, [Allen B. Tucker e Robert E. Noonan, Programming Languages: Principles and Paradigms, segunda edição, McGraw-Hill, Boston, 2007].)

Question 16

programação
* de computadores

programming
computer *

Answer 16

A programação de computadores ou simplesmente programação é o processo de concepção, escrita, teste, depuração e manutenção do código fonte de programas de computador. O código fonte é escrito usando uma ou mais linguagens de programação (tais como o Java, o C++, o C#, o Ruby ou o Python). O objectivo da programação é a criação de um conjunto de instruções que são usadas pelos computadores para desempenhar operações específicas ou para apresentarem comportamentos desejados. O processo de escrita de código fonte requer muitas vezes perícia em muitos diferentes assuntos, incluindo conhecimento do domínio de aplicação, de algoritmos especializados e de lógica formal. Até que ponto a escrita de programas é uma forma de arte, um ofício ou uma disciplina da engenharia continua a ser debatido. Em geral, considera-se boa programação uma aplicação equilibrada dessas três práticas com o objectivo de produzir um solução de software eficiente e passível de evolução. [Wikipédia]

Question 17

programação imperativa

imperative programming

Answer 17

A programação imperativa é o mais antigo dos paradigmas de programação, fundando-se no modelo clássico de computação de «von Neumann-Eckert». Neste modelo, o programa e as suas variáveis são armazenados em conjunto, e o programa contém uma sequência de instruções que efectuam cálculos, atribuem valores a variáveis, lêem entradas, produzem saídas ou direccionam o fluxo do controlo para outro local na sequência de instruções. A abstracção procedimental (na forma de procedimentos, ou melhor, de rotinas) é um elemento essencial da programação procedimental, um dos paradigmas de programação incluído na programação imperativa. As sequências de instruções, as instruções iterativas e as instruções condicionais e de selecção são elementos essenciais da programação estruturada, outro dos paradigmas de programação incluído na programação imperativa. [Allen B. Tucker e Robert E. Noonan, Programming Languages: Principles and Paradigms, segunda edição, McGraw-Hill, Boston, 2007] A programação orientada por objectos também pode ser considerada com um dos paradigmas de programação incluído na programação imperativa, embora o seu modelo assente na visão do programa como uma colecção de objectos que interagem entre si, enviando mensagens (i.e., invocando operações) uns aos outros e agindo de acordo com as mensagens recebidas (executando os métodos correspondentes às operações invocadas), assim alterando possivelmente o seu estado [idem].

Abaixo ilustram-se os três principais paradigmas de programação através de implementações do algoritmo de Euclides para o obtenção do máximo divisor comum de dois números em Prolog, Scheme e Java («gcd» é a abreviatura de «greatest common divisor»).

Prolog (programação lógica):

> gcd(X, 0, X):- !. gcd(0, X, X):- !. gcd(X, Y, D):- X > Y, !, Z is X mod Y, gcd(Y, Z, D). gcd(X, Y, D):- Z is Y mod X, gcd(X, Z, D).

Scheme (programação funcional):

> (define (gcd a b) (if (= b 0) a (gcd b (modulo a b))))

Java (programação imperativa):

> public static int gcd(int a,
` int b) { while (b > 0) { int c = a % b; a = b; b = c; } return a; }`

Question 18

programação procedimental

procedural programming

Answer 18

A programação procedimental é um paradigma de programação que deriva da programação estruturada, incluindo-a, e assenta no conceito da invocação de procedimentos, ou melhor, de rotinas. As rotinas, também conhecidas por subrotinas (e a que, quando associadas a uma classe ou objecto na programação orientada por objectos, também se chama métodos), contêm simplesmente uma sequência de instruções (incluindo possivelmente instruções de controlo de fluxo) a executar para atingir um objectivo definido, dado um conjunto de parâmetros de entrada. As rotinas podem ser invocadas em qualquer ponto da execução de um programa, inclusivamente dentro de outras rotinas ou mesmo dentro da própria rotina invocada. Algumas linguagens de programação seguindo o paradigma da programação procedimental são o Fortran, o Basic, o C ou o Pascal. [Wikipédia] A programação procedimental enfatiza a abstracção procedimental, que permite ao programador, enquanto cliente de uma rotina, preocupar-se apenas com a interface entre a rotina e o seu resultado computacional, ignorando os pormenores da sua implementação. [Allen B. Tucker e Robert E. Noonan, Programming Languages: Principles and Paradigms, segunda edição, McGraw-Hill, Boston, 2007] Ou seja, a programação procedimental encoraja simultaneamente o encapsulamento, e por isso uma forma simples do princípio da ocultação de informação, e a modularização, no sentido em que as rotinas podem ser consideradas como módulos reutilizáveis a partir dos quais se constrói o programa. (Nota 1: Considera-se uma boa prática da programação procedimental que uma rotina tenha um único objectivo bem definido. Nota 2: A programação orientada por objectos inclui a programação procedimental. Nota 3: A programação por contrato pode em parte ser vista como uma formalização da programação procedimental em que as interfaces das rotinas passam a ter associados contratos estabelecidos entre os seus produtores e os seus clientes.)

Question 19

rotina
subrotina

routine
subroutine

Answer 19

O nome genérico dado às funções (incluindo os predicados) e aos procedimentos é rotina (ou subrotina). As rotinas são uma das unidades de modularização em programação. Uma rotina abstrai uma acção ou uma computação. Uma rotina expõe uma interface e encapsula uma implementação. A interface consiste no nome da rotina, bem como no número e tipo dos seus argumentos e dos valores que devolve. A sua implementação consiste na declaração dos seus parâmetros, que recebem em cada invocação o valor dos argumentos que são passados à rotina, e no seu corpo, ou seja, na sequência de instruções que realizam a acção pretendida ou que calculam o valor a devolver. As rotinas têm associados contratos, que por vezes não são tornados explícitos. (Nota: A distinção feita aqui entre rotina, procedimento e função não é consensual.)

Em C, a palavra «função» é usada no sentido de rotina. Para evitar ambiguidades, sempre que pretendermos referir-nos ao mecanismo do C que suporta a noção de rotina usaremos a expressão «função C».

Seguem-se alguns exemplos de rotinas em C.

Uma função em C:

int factorial(int n) { if (n == 0) return 1; return n * factorial_of(n - 1); }

Um predicado (e por isso também uma função) em C:

int is_odd(int n) { return n % 2 != 0; }

Um procedimento em C:

void swap(int a[], int i, int j) { const int original_a_i = a[i]; a[i] = a[j]; a[j] = original_a_i;
}

Question 20

variável

variable

Answer 20

Na programação de computadores, uma variável é uma localização na memória associada a um nome simbólico (um identificador) que contém uma quantidade ou uma informação (um valor) conhecida ou desconhecida. O nome da variável é a forma usual de referenciar o valor armazenado. A separação entre nome e conteúdo permite a utilização do nome de forma independente da informação exacta que representa. O identificador presente no código fonte pode ser associado a um valor durante o tempo de execução, o que significa que o valor da variável pode variar durante a execução do programa. As variáveis em programação podem não corresponder directamente ao conceito de variável em matemática. O valor de uma variável computacional não é necessariamente parte de uma equação ou fórmula, como na matemática. Na computação, uma variável pode ser usada num processo repetitivo: pode-se atribuir-lhe um valor num local, usá-la noutro local, atribuir-lhe depois um novo valor e usá-la outra vez da mesma forma que anteriormente (ver iteração). As variáveis computacionais têm frequentemente nomes longos, de modo a torná-las descritivas daquilo que armazenam. Pelo contrário, as variáveis matemáticas tendem a ter nomes breves, com apenas uma ou duas letras (por um lado, tais nomes tornavam mais rápida a sua manipulação e transcrição; por outro lado, o grau de abstracção das variáveis é usualmente muito maior em matemática do que na programação, pelo que a utilização de nomes mais longos não estaria associada a uma maior facilidade de compreensão pelo leitor, ao contrário do que acontece na programação). [Wikipédia] Há vários tipos de variáveis computacionais: as variáveis globais, em geral desaconselháveis, disponíveis em todos os pontos de um programa, as variáveis de instância (ou variáveis de objecto), que fazem parte do estado privado de um objecto (ou seja, da sua implementação) e que, por vezes, correspondem directamente a atributos desse objecto; as variáveis locais, cujo âmbito se restringe tipicamente a uma rotina; e os parâmetros de rotinas, que funcionam como variáveis locais, embora com a particularidade de serem inicializadas à custa dos valores dos argumentos correspondentes. (Nota: Em Snap! chama-se variáveis de objecto ou, por vezes, variáveis de actor, às variáveis de instância e chama-se variáveis de guião às variáveis locais.)

Question 21

acção²

action²

Answer 21

A parte do passo de um ciclo na qual se realiza a acção parcial que cada passo do ciclo deve realizar para que o ciclo atinja o seu objectivo uma vez terminado. Usualmente a acção precede o progresso. A acção tem como objectivo principal garantir que o ciclo atinge o seu objectivo assim que termine.

Question 22

argumento

argument
actual argument

Answer 22

Um argumento é uma expressão usada na invocação de uma rotina e cujo valor é usado para inicializar o parâmetro correspondente. Também se dá o nome argumento ao valor dessa expressão. Diz-se que os argumentos são passados à rotina aquando da sua invocação. (Nota: No Snap! os argumentos são os blocos colocados nas ranhuras ou forquilhas de outros blocos.)

Exemplos de invocações simples em Snap!:

Question 23

atribuição

assignment

Answer 23

Uma atribuição é a acção de alteração do valor de uma dada variável para o valor de uma dada expressão.

O comando Snap! abaixo atribui o valor 1 à variável «o produto»:

Question 24

cápsula

capsula

Answer 24

Pode-se usar o termo cápsula para caracterizar um tipo particular de módulo que suporta o encapsulamento, expondo uma interface aos seus clientes e ocultando e restringindo o acesso à sua implementação.

Question 25

contrato

contract

Answer 25

Compromisso estabelecido entre o produtor de um módulo (tipicamente uma rotina ou bloco) e os seus clientes. Os contratos estabelecem (a) a forma de utilização, (b) as condições a cumprir pelo cliente, ou seja, as pré-condições, e (c) as pós-condições, ou seja, as condições que o produtor garante que serão cumpridas desde que o cliente cumpra a sua parte do contrato.

Por exemplo, um bloco Snap! para o cálculo da raiz quadrada (a) chama-se (√ (x)) e invoca-se colocando o valor, i.e., o argumento, cuja raiz quadrada se pretende obter na única ranhura disponível no bloco, (b) [pré-condição] não pode ser invocado senão com argumentos não negativos e (c) [pós-condição] reporta um valor que, quando multiplicado por si mesmo, está suficientemente próximo do valor do argumento, i.e, tem um erro relativo inferior a 1e-15.

Question 26

**devolução** return (em parte)

Answer 26

Aquilo que acontece quando uma **rotina**, tipicamente uma **função**, **devolve** algo ao **retornar**.

Question 27

**devolver** to return (em parte)

Answer 27

Indicar um **valor** a usar como resultado da **rotina** em **execução**, tipicamente uma **função**, quando esta **retornar**, i.e., quando se abandonar a **rotina** em **execução** e se regressar ao ponto do **código** imediatamente após o local onde a **rotina** foi **invocada** para originar a **execução** corrente. [[Wikipédia](http://en.wikipedia.org/wiki/Return_statement)] Em inglês a palavra **return** é usada tanto para o **retorno** como para a **devolução**, que em português se distinguem. Assim, em português pode-se dizer que «um procedimento não devolve nada ao retornar» e que «uma função tem de devolver um valor apropriado ao retornar». É típico que as **linguagens de programação** seguindo o **paradigma** da **programação imperativa** disponibilizem uma **instrução de retorno**, na qual, dependendo do contexto, se pode ou não indicar o **valor** a **devolver**. Em muitas linguagens o **retorno** é automático se se atingir o final da **sequência de instruções** da **rotina**. Em **linguagens** como o Ruby, o **valor** **devolvido** nessas circunstâncias é o valor da última **instrução**. Em linguagens como o Pascal, o nome da **função** corrente pode ser usado como se se tratasse de uma **variável** cujo **valor** é **devolvido** automaticamente ao **retornar**. (Nota: Em Snap! usa-se o termo *reportar* com o significado de **retornar** **devolvendo**.) [](http://farm9.staticflickr.com/8225/8365738000_80e83fe78b_o.gif "Reportando por Manuel Menezes de Sequeira, no Flickr")

Question 28

**efeito lateral** side effect

Answer 28

Diz-se que uma **função** ou **expressão** tem um **efeito lateral** se, para além de **devolver** um **valor**, também modificar o **estado** do **programa** ou tiver alguma interacção observável com as **rotinas** que a invocaram (directa ou indirectamente) ou com o mundo exterior. Por exemplo, uma **função** pode alterar uma **variável global** ou uma **variável de instância**, alterar um dos seus **argumentos** (no caso da **passagem de argumentos por referência**), escrever algo num ecrã ou num ficheiro, ler dados, ou **invocar** outras **rotinas** com o mesmo tipo de efeito. Na presença de **efeitos laterais**, o comportamento de um **programa** depende do seu histórico, i.e., a ordem de **execução** é relevante. Compreender um **programa** com **efeitos laterais** requer conhecimento acerca do contexto e do seu histórico. Um tal **programa** será, por isso, mais difícil de ler, compreender e **depurar**. Os efeitos descritos acima como laterais são a forma mais comum de fazer um **programa** interagir com o mundo que lhe é exterior (pessoas, sistemas de ficheiros, outros computadores em rede, etc.). O grau de utilização destes efeitos depende do **paradigma de programação**. A **programação imperativa** usa-os com frequência. A **programação funcional** usa-os raramente. [[Wikipédia](http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29)] Em **programação imperativa** considera-se boa prática evitar **funções** com **efeitos laterais** (i.e., prefere-se **funções puras**) e concentrar esse tipo de efeitos em **procedimentos**. Em **programação funcional** considera-se boa prática evitar os **efeitos laterais**. [](http://farm9.staticflickr.com/8055/8364759823_445ce2d3d4_o.gif "Um efeito lateral por Manuel Menezes de Sequeira, no Flickr")

Question 29

**encapsulamento** encapsulation

Answer 29

No contexto das **linguagens de programação**, o termo **encapsulamento** é usado para se referir ao resultado da aplicação de dois mecanismos distintos, embora relacionados, dessas **linguagens**. Por vezes é também usado para se referir ao resultado da aplicação combinada desses dois mecanismos. O primeiro dos mecanismos restringe a visibilidade e o acesso à representação interna dos **objectos**. Essa representação só é acessível indirectamente, através de **rotinas** próprias de cada **objecto** ou **classe** (que nesse contexto recebem o nome de **métodos** ou mesmo de **atributos**, quando se limitam a devolver ou manipular uma qualidade singular desses **objectos**). O segundo dos mecanismos permite o agupamento dos **dados** com as **rotinas** que operam sobre esses **dados**. [[Wikipédia](http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29)] Note-se que ambas as acepções são importantes no contexto da **programação por contrato**. A primeira, porque de outra forma o **produtor** de uma **classe** (ou de um **objecto protótipo**) não poderia dar garantias ao respectivo **cliente**. A segunda porque só agrupando em **objectos** os **dados** e as **rotinas** que os manipulam se pode falar com propriedade acerca de **invariantes** dos **objectos** e de garantias da sua real invariância.

Question 30

**estado** state

Answer 30

Conjunto de todas as **variáveis**, **atributos**, **instâncias** e **objectos**, bem como dos respectivos **valores**, associados a um **programa**, a um **objecto** ou a um outro **artefacto** de um **programa** em execução.

Question 31

**execução** execution

Answer 31

Na **ciência da computação**, a **execução** é o processo através do qual um **computador** leva a cabo as **instruções** de um **programa de computador**. As **instruções** do **programa** desencadeiam sequências de **acções** simples na máquina onde a **execução** decorre. Essas **acções** produzem efeitos de acordo com a semântica dessas **instruções**. O verbo «correr» é usado muitas vezes no mesmo sentido que «executar». [[Wikipédia](http://en.wikipedia.org/wiki/Execution_%28computing%29)]

Question 32

**função pura** pure function

Answer 32

Uma **função** sem **efeitos laterais**. Estas **funções** podem ser modeladas através de funções matemáticas. (Nota: Também se pode dizer que um **predicado** sem **efeitos laterais** é um **predicado puro**. Os **predicados puros** são também **funções puras**.)

Question 33

**guarda** guard

Answer 33

Uma **guarda** é uma condição, i.e., uma **expressão** com valor **booleano**, usada para controlar uma **instrução condicional**, uma **instrução de selecção** ou, sobretudo, uma **instrução iterativa**. Em algumas **instruções iterativas** a **guarda** é implícita. [](http://farm9.staticflickr.com/8195/8364220653_23628a8c76_o.gif "As partes de um ciclo por Manuel Menezes de Sequeira, no Flickr")

Question 34

**implementação** implementation

Answer 34

A parte de uma **cápsula** que se encontra no seu interior, i.e., o seu mecanismo. O acesso do exterior, a partir do qual a **cápsula** é normalmente usada, é realizado através da mediação de uma **interface**. Uma boa **interface** torna a **cápsula** simples de usar e compreender, não deixando transparecer pormenores de **implementação** que são irrelevantes para os **programadores** que são seus **clientes**. É desejável que as **interfaces** sejam estáveis, i.e., que não se obrigue os **clientes** das **cápsulas** a se adaptarem frequentemente a alterações na forma de interagir com elas. A **implementação** de uma **cápsula**, por outro lado, pode ser alterada de forma mais liberal, desde que a **interface** e o **contrato** da **cápsula** se mantenham.

Question 35

**inicialização**² initialization²

Answer 35

A **inicialização** de uma **variável** ou **constante** é a **acção** de pela primeira lhe **atribuir** um valor. Em algumas **linguagens de programação** a **inicialização** pode ocorrer em simultâneo com a declaração (ou melhor, definição) da **variável**, i.e., as **acções** de criação e **inicialização** são simultâneas. (Nota: No Scratch e no Snap! as **variáveis** são sempre **definidas** e **inicializadas** em locais diferentes.) [](http://farm9.staticflickr.com/8498/8366259430_900e1d23ff_o.gif "A inicialização por Manuel Menezes de Sequeira, no Flickr")

Question 36

**instrução instrução simples instrução composta** statement simple statement compound statement

Answer 36

Na **programação de computadores**, uma **instrução** é o menor dos elementos independentes de uma **linguagem de programação** **imperativa**. Um **programa** escrito numa **linguagem** deste tipo consiste numa ou mais **instruções**. As **instruções** podem ter componentes internos, tais como **expressões**. Muitas **linguagens** distinguem entre **instruções**, contendo apenas **código** executável, e **definições**, **declarando** um identificador. Também é usual distinguir entre **instruções simples** e **instruções compostas**, que contêm uma sequência de outras **instruções** como componente. [[Wikipédia](http://en.wikipedia.org/wiki/Statement_%28computer_science%29)] (Nota: No Scratch e Snap! dá-se o nome *comando* às **instruções**, que por isso são na prática indistinguíveis das **invocações** de **procedimentos**. É essa, de resto, uma das características do Snap! necessárias para que seja possível criar novas **instruções iterativas**.)

Question 37

**instrução condicional** conditional statement

Answer 37

Uma **instrução condicional** é um tipo específico de **instrução de controlo de fluxo** que permite **executar** uma dada sequência de **instruções** apenas se uma dada condição se verificar. À condição de controlo chama-se usualmente **guarda**. [](http://farm9.staticflickr.com/8506/8365226337_437befb537_o.gif "O «se» por Manuel Menezes de Sequeira, no Flickr")

Question 38

instrução de devolução

Answer 38

Uma **instrução de devolução** é uma **instrução** usada para estabelecer o **valor** a **devolver** quando a **rotina** em **execução**, tipicamente uma **função**, **retornar**. É típico que as **instruções de devolução** sejam simultaneamente **instruções de retorno**, mas em linguagens como o Pascal isso não acontece. (Nota: No Snap! o *comando* ou **instrução** [reporta [o valor]] é simultaneamente uma **instrução de devolução** e uma **instrução de retorno**.) [](http://farm9.staticflickr.com/8225/8365738000_80e83fe78b_o.gif "Reportando por Manuel Menezes de Sequeira, no Flickr")

Question 39

**instrução de retorno** return statement

Answer 39

Uma **instrução de retorno** é uma **instrução de controlo de fluxo**, disponibilizada tipicamente por **linguagens de programação** seguindo o **paradigma** da **programação imperativa**, cuja **execução** leva o **fluxo de controlo** a **retornar** da **rotina** em **execução**. Em algumas linguagens, como o C, o Java, o C# ou o Ruby, e dependendo do contexto, é possível indicar na **instrução de retorno** qual o **valor** a **devolver**. Nesse caso a **instrução de retorno** é simultaneamente uma **instrução de devolução**. (Nota: No Snap! o *comando* ou **instrução** [reporta [o valor]] é simultaneamente uma **instrução de devolução** e uma **instrução de retorno**.) [](http://farm9.staticflickr.com/8225/8365738000_80e83fe78b_o.gif "Reportando por Manuel Menezes de Sequeira, no Flickr")

Question 40

**instrução de selecção** selection statement

Answer 40

Uma **instrução de selecção** é um tipo específico de **instrução de controlo de fluxo** que permite **executar** uma ou outra de duas diferentes sequências de **instruções** consoante uma condição seja verdadeira ou falsa. À condição de controlo chama-se usualmente **guarda**. [](http://farm9.staticflickr.com/8097/8367299518_d77b660550_o.gif "O «se senão» por Manuel Menezes de Sequeira, no Flickr")

Question 41

**interface** interface

Answer 41

A parte de uma **cápsula** que medeia entre o seu interior, contendo a **implementação** ou mecanismo, e o exterior, a partir do qual a **cápsula** é normalmente usada. Uma boa **interface** torna a **cápsula** simples de usar e compreender, não deixando transparecer pormenores de **implementação** que são irrelevantes para os **programadores** que são seus **clientes**. É desejável que as **interfaces** sejam estáveis, i.e., que não se obrigue os **clientes** das **cápsulas** a se adaptarem frequentemente a alterações na forma de interagir com elas.

Question 42

**invocar chamar** to call

Answer 42

Provocar a **execução** de uma **rotina** de modo a usar o **valor** por ela **devolvido**, no caso de se tratar de uma **função**, ou a realizar determinadas **acções**, no caso de se tratar de um **procedimento**. Para invocar uma **rotina** é necessário **passar**-lhe **argumentos** (ou seja, **expressões**) compatíveis com a sua **interface**. No caso de se usar **passagem de argumentos por valor**, os **valores** dos **argumentos** serão utilizados para **inicializar** os **parâmetros** da **rotina**, que, exceptuando esta forma especial de **inicialização**, funcionam como **variáveis locais** da **rotina** durante a sua **execução**. No caso da **programação orientada por objectos**, as **rotinas** **invocadas** estão normalmente associadas a um **objecto** (possivelmente através da sua **classe**). A esse **objecto** chama-se **receptor**, designação que surge da utilização da expressão «enviar uma mensagem a um objecto» como equivalente à expressão «invocar uma operação sobre um objecto». A **invocação** de uma **operação** sobre um **objecto** leva à execução de um **método**. [](http://farm9.staticflickr.com/8368/8365429716_72bd89a4a1_o.gif "Argumentos - valores e expressões por Manuel Menezes de Sequeira, no Flickr")

Question 43

**módulo modularização** module modularization

Answer 43

Na **concepção de *software***, entende-se por **modularização** o particionamento do ***software*** em **módulos** de modo a facilitar a sua **implementação** e a sua manutenção. A lógica de particionamento pode assentar nas funções desempenhadas pelos **módulos**, em critérios de **implementação**, na quantidade de ligações entre os **módulos**, etc. Usualmente os **módulos** são também **cápsulas**, i.e., expõem uma **interface** e ocultam uma **implementação**. [[Wikipédia](http://en.wikipedia.org/wiki/Modularization)]

Question 44

**objecto**² object²

Answer 44

Na **programação orientada por objectos**, um **objecto** é uma **cápsula** cuja **interface** consiste numa colecção de **atributos**, que correspondem ao **estado** observável do **objecto**, e numa colecção de **operações**, que lhe conferem um comportamento observável. A implementação de um **objecto** consiste essencialmente numa **estrutura de dados** agregada às **rotinas** que a processam. Os **objectos** representam **instâncias** particulares de determinados conceitos reais ou abstractos. Por exemplo, um **objecto** representando um ficheiro consiste numa colecção de **dados** e numa colecção de **rotinas** para operar sobre esses **dados** e para ler e escrever no ficheiro real correspondente. Os **objectos** são usualmente considerados instâncias de uma **classe**, que pode ser explícita (com representação directa na **linguagem de programação**) ou implícita (sem essa representação directa). Por exemplo, no mundo real o Fernando Pessoa foi um poeta e um humano. Num **programa** seguindo o **paradigma** da **programação orientada por objectos**, o Fernando Pessoa será provavelmente uma **instância** da **classe** dos **poetas**, que por sua vez será uma **subclasse** dos **humanos**. Todos os **objectos** de uma **classe** têm os mesmos **atributos** (embora cada **objecto** tenha os seus próprios **valores** para esses **atributos**) e os mesmos comportamentos, conferidos pelas suas **operações**. Os objectos são a fundação do **paradigma** da **programação orientada por objectos**. As **linguagens de programação** que assentam neste **paradigma de programação** suportam sintáctica e semanticamente a manipulação de **objectos**, incluindo possivelmente um **sistema de tipos** hierárquico, notações especiais para declarar **operações** e definir os correspondentes **métodos**, e mecanismos para ocultar dos **clientes** os pormenores de **implementação** de cada **objecto**. Nas **linguagens de programação** que não suportam directamente a noção de **classe**, é comum representar cada **classe** implicitamente através de uma sua **instância** com um estatuto especial: o **objecto protótipo**, a partir do qual todos os restantes **objectos** dessa **classe** são criados, usando **clonagem**. [[Wikipédia](http://en.wikipedia.org/wiki/Object_%28computer_science%29#Object-oriented_programming)]

Question 45

**paradigma de programação** programming paradigm

Answer 45

Um **paradigma da programação** é um estilo fundamental de **programação de computadores**. Há três **paradigmas de programação** principais: **programação imperativa** (incluindo a **programação orientada por objectos**), **programação funcional** e **programação lógica**. Os fundamentos destes três paradigmas são modelos distintos de computação: a máquina de (Alan) Turing, no caso da **programação imperativa**, o cálculo lambda (de Alonzo Church), no caso da **programação funcional**, e a lógica de primeira ordem, no caso da **programação lógica**. [[Wikipédia](http://en.wikipedia.org/wiki/Programming_paradigm)] (Nota 1: Alan Turing e Alonzo Church são duas das maiores figuras da ciência da computação. Nota 2: Ao contrário do que é feito na Wikipédia, consideramos que **programação declarativa** e **programação lógica** expressam o mesmo conceito e que a **programação funcional** não é uma forma de **programação declarativa**. Estas definições não são consensuais. Ver, por exemplo, [Allen B. Tucker e Robert E. Noonan, Programming Languages: Principles and Paradigms, segunda edição, McGraw-Hill, Boston, 2007].) Abaixo ilustram-se os três **paradigmas de programação** através de implementações do **algoritmo** de Euclides para o [obtenção do máximo divisor comum de dois números em Prolog, Scheme e Java](http://rosettacode.org/wiki/Greatest_common_divisor). Prolog (**programação lógica**): > `gcd(X, 0, X):- !. gcd(0, X, X):- !. gcd(X, Y, D):- X > Y, !, Z is X mod Y, gcd(Y, Z, D). gcd(X, Y, D):- Z is Y mod X, gcd(X, Z, D).` Scheme (**programação funcional**): > `(define (gcd a b)   (if (= b 0)       a       (gcd b (modulo a b))))` Java (**programação imperativa**): > `public static int gcd(int a, ` > `                      int b) {     while (b > 0) {         int c = a % b;         a = b;         b = c;     }     return a; }`

Question 46

**passagem de argumentos por valor** pass-by-value call-by-value

Answer 46

A **passagem de argumentos por valor** é a estratégia de **passagem de argumentos** a **rotinas** mais comum, sendo usada em **linguagens de programação** tão diferentes como o C ou o Scheme. Na **passagem de argumentos por valor**, a **expressão** correspondente a cada **argumento** é calculada e o **valor** resultante é usado para **inicializar** o **parâmetro** correspondente. Se a **rotina** puder fazer **atribuições** aos seus **parâmetros**, isso alterará apenas esses **parâmetros**, e não os **argumentos** correspondentes. Note-se que em muitas **linguagens**, tal como no Java (excepto no caso dos tipos primitivos) ou no próprio Snap!, as **variáveis** guardam **referências** para os **valores** ou **objectos** que lhes são **atribuídos**. Nesse caso, a **passagem de argumentos por valor** corresponde na realidade a uma cópia de **referências**, pelo que as entidades referenciadas podem ser alteradas, desde que sejam mutáveis. A este tipo de **passagem de argumentos** pode-se chamar **passagem de referências por valor**. [[Wikipédia](http://en.wikipedia.org/wiki/Pass_by_value#Call_by_value)] **Passagem de argumentos por valor** no Snap!: [](http://farm9.staticflickr.com/8191/8366651953_9fc3bfa4bf_o.png "Passagem de argumentos por Manuel Menezes de Sequeira, no Flickr")

Question 47

**passo** step

Answer 47

Chama-se **passo** ao conjunto de **instruções** executado repetidamente por um **ciclo**. É típico o **passo** consistir na **acção** seguida pelo **progresso** do **ciclo**. No entanto, em alguns tipos de **instruções iterativas** o **progresso** é implícito, podendo também ocorrer num local sintaticamente distinto (e.g., no caso da **instrução iterativa** «for» das **linguagens** derivadas do C). [](http://farm9.staticflickr.com/8195/8364220653_23628a8c76_o.gif "As partes de um ciclo por Manuel Menezes de Sequeira, no Flickr")

Question 48

**predicado** predicate

Answer 48

Um tipo específico de **função** que **devolve** um valor lógico ou **booleano**, ou seja, que **devolve** um dos dois possíveis valores lógicos («verdadeiro» ou «falso»). (Nota: no Snap! os **predicados** são um tipo específico de *repórter*.) [](http://farm9.staticflickr.com/8494/8366786921_5c8f5e7474_o.gif "Os predicados por Manuel Menezes de Sequeira, no Flickr")

Question 49

**programação estruturada** structured programming

Answer 49

A **programação estruturada** é um **paradigma de programação** que surgiu na sequência de uma carta ao editor das *Communications of the ACM* enviada por **Edsger Dijkstra** e intitulada «GoTo Considered Harmful». A **programação estruturada** enquadra-se na **programação imperativa** e assenta na ideia de que os **programas** devem ser concebidos usando apenas três estruturas de **controlo** básicas: a **sequência de instruções**, a **instrução de controlo de fluxo** e a **instrução iterativa**, nomeadamente o ciclo **enquando [guarda] fazer [passo]**. Assim, a **programação estruturada** propõe a rejeição da utilização de qualquer forma de **instrução** goto (ir para), uma vez que esta é desnecessária e encoraja a escrita de **código** incompreensível (conhecido como **código esparguete**). Nos anos 60 do século XX, a principal ferramenta de concepção de **programas** era o **fluxograma**, que encorajava também o **código esparguete**, com uma estrutura entrelaçada em que era difícil discernir estruturas **iterativas** e **condicionais**. [Allen B. Tucker e Robert E. Noonan, *Programming Languages: Principles and Paradigms*, segunda edição, McGraw-Hill, Boston, 2007] (Nota 1: O **paradigma** da **programação estruturada** não é alternativo a outros **paradigmas** importantes da **programação imperativa**, nem tão pouco complementar: na realidade integra-os. De facto, a **programação orientada por objectos**, hoje o mais relevante dos **paradigmas** da **programação imperativa**, inclui nele as ideias chave da **programação procedimental** e da **programação estruturada**, da mesma forma que se pode dizer que a boa **programação procedimental** inclui as ideias chave da **programação estruturada**. Nota 2: **Edsger Dijkstra** é uma das maiores figuras da ciência da computação.) [](http://xkcd.com/292/ "GOTO, no xkcd")

Question 50

**programação orientada por objectos** object-oriented programming

Answer 50

A **programação orientada por/pelos/para/a/aos objectos** é um **paradigma da programação** que assenta no conceito de **objecto** como **cápsula**. A **interface** de cada **objecto** consiste numa colecção de **atributos** (ou **propriedades**), que correspondem ao seu estado observável, e numa colecção de **operações**, que lhe conferem um comportamento observável. A **implementação** de cada **objecto** consiste numa colecção de **variáveis de instância** (ou **variáveis de objecto**), que correspondem ao seu estado interno, e numa colecção de **métodos**, que implementam as **operações** correspondentes. **Operações** e **métodos** podem ser vistos respectivamente como a **interface** e a **implementação** de **rotinas** associadas aos **objectos**. As **operações** são **invocadas** «sobre» um **objecto** dito o **receptor**. O termo **receptor** decorre da utilização da expressão «o **objecto** *A* enviou uma **mensagem** ao **objecto** *B*» para descrever o que acontece quando um **objecto** **invoca** uma **operação** de um outro **objecto**. É típico que os **objectos** sejam considerados **instâncias** de uma **classe**, tendo todos os **objectos** de uma **classe** os mesmos **atributos** (não necessariamente com o mesmo valor, note-se) e as mesmas **operações**. Em algumas **linguagens** as **classes** são representadas explicitamente (e.g., no Java, no C#, no C++, etc.). Noutras, como no Snap!, as **classes** são representadas implicitamente através de um **objecto protótipo**. Diz-se que estas **linguagens** suportam o **paradigma** da **programação baseada em protótipos**. Tanto os princípios da **programação procedimental** como os princípios da **programação estruturada** se aplicam na **programação orientada por objectos**, a primeira na forma como as **operações** e os **métodos** se organizam, a segunda na forma como os **métodos** são implementados. Na **programação orientada por objectos**, as **aplicações** ou **programas** são concebidos como uma interacção entre **objectos**, cada um dos quais responde a **mensagens** (**executa** os **métodos** correspondentes a **operações** suas **invocadas** por outros **objectos**), processa dados (manipula o seu **estado**, através das suas **variáveis de instância**) e envia **mensagens** a outros **objectos** (invoca **operações** de outros **objectos**). Cada **objecto** pode ser visto como uma «máquina» independente com um papel e uma responsabilidade próprias. [[Wikipédia](http://en.wikipedia.org/wiki/Object-oriented_programming)] [](http://faculty.otterbein.edu/PSanderson/COMP325/notes/lecture12.html "Diagrama de colaboração por Peter Sanderson")

Question 51

**progresso** progress

Answer 51

A parte do **passo** de um **ciclo** na qual se actualiza as suas **variáveis de controlo** de modo a, reflectindo a realização da **acção**, garantirem que o **ciclo** se aproxima do seu fim. Usualmente o **progresso** segue-se à **acção**. O **progresso** tem como objectivo principal garantir que o **ciclo** termina em tempo finito. [](http://farm9.staticflickr.com/8195/8364220653_23628a8c76_o.gif "As partes de um ciclo por Manuel Menezes de Sequeira, no Flickr")

Question 52

**protótipo^₂ objecto \*** prototype² \* object

Answer 52

Os **objectos protótipos** são o conceito chave de um tipo especial de **programação orientada por objectos** chamada **programação baseada em protótipos**. Neste tipo de **programação orientada por objectos** o conceito de **classe** é implícito. A reutilização de comportamento é conseguida através da **clonagem** de **objectos** existentes e que têm o papel de **protótipos**. Este tipo de programação assenta numa característica das **linguagens de programação** chamada **delegação**. A primeira **linguagem de programação** **baseada em protótipos** foi o Self, desenvolvido por David Ungar e Randall Smith em meados dos anos 80 e usado para investigar na área da concepção de **linguagens de programação**. A partir dos finais dos anos 90 este tipo de **programação** ganhou popularidade: uma das **linguagens** mais usada hoje em dia, o JavaScript, é um bom exemplo. O Snap! é também uma **linguagem** assente na **programação baseada em protótipos**. [[Wikipédia](http://en.wikipedia.org/wiki/Prototype-based_programming)] (Nota: A palavra «protótipo» deriva do grego πρωτότυπον (prototipon), «forma primitiva», neutro de πρωτότυπος (prototipos), "original, primitivo", de πρῶτος (protos), "primeiro" e τύπος (tipos), "impressão" [[Wikipédia](http://en.wikipedia.org/wiki/Prototype)]. O seu significado, primeiro tipo ou primeiro exemplar [[Priberam](http://www.priberam.pt/dlpo/default.aspx?pal=prot%C3%B3tipo)], é semelhante ao de «arquétipo», pelo menos no contexto da **ciência da computação**, ou seja, modelo ideal, inteligível, do qual se copiou toda a coisa sensível [[Priberam](http://www.priberam.pt/dlpo/default.aspx?pal=arqu%C3%A9tipo)].)

Question 53

**recursividade** recursion

Answer 53

A **recursividade**, na **ciência da computação**, é uma abordagem à resolução de problemas em que a solução de um problema depende de soluções de instâncias menores do mesmo problema. A abordagem recursiva pode ser aplicada a muitos tipos de problemas, sendo uma das ideias centrais da **ciência da computação**. «O poder da **recursividade** assenta evidentemente na possibilidade de definir um conjunto infinito de objectos através de uma afirmação finita. Da mesma forma, um número infinito de computações pode ser descrito por um **programa** recursivo finito, mesmo que esse programa não contenha repetições explícitas.» [Niklaus Wirth, *Algorithms + Data Structures = Programs*, Prentice-Hall, 1976, p. 126] A maioria das **linguagens de programação** suportam a **recursividade**, permitindo que uma **rotina** se **invoque** a si mesma no seu corpo ou **implementação**. Algumas **linguagens de programação** suportando o **paradigma** da **programação funcional** não possuem qualquer mecanismo para definir **ciclos**, recorrendo-se apenas à **recursividade** para executar **instruções** repetidamente. [[Wikipédia](http://en.wikipedia.org/wiki/Recursion_%28computer_science%29)] Exemplo de repórter recursivo em Snap! para calcular o factorial: [](http://farm9.staticflickr.com/8218/8367372077_d2e29d1707_o.gif "A recursividade por Manuel Menezes de Sequeira, no Flickr")

Question 54

**retornar** to return (em parte)

Answer 54

Abandonar a **rotina** em **execução** e regressar ao ponto do **código** imediatamente após o local onde a **rotina** foi **invocada** para originar a **execução** corrente. Este ponto é conhecido como o **endereço de retorno**. Este endereço é guardado, normalmente na **pilha de invocações** do processo, como resultado da realização da **invocação** da **rotina**. Pode ser possível, dependendo da **linguagem** e do contexto exacto (e.g., se se trata de um **procedimento** ou de uma **função**), **devolver** um **valor** ao **código** invocador, que nesse caso pode ser parte de uma **expressão**. [[Wikipédia](http://en.wikipedia.org/wiki/Return_statement)] Em inglês, a palavra *return* é usada tanto para o **retorno** como para a **devolução**, que em português se distinguem. Assim, em português pode-se dizer que «um procedimento não devolve nada ao retornar» e que «uma função tem de devolver um valor apropriado ao retornar». É típico que as **linguagens de programação** seguindo o **paradigma** da **programação imperativa** disponibilizem uma **instrução de retorno**, na qual, dependendo do contexto, se pode ou não indicar o **valor** a **devolver**. Em muitas linguagens o **retorno** é automático se se atingir o final da **sequência de instruções** (ou seja, o final do **corpo**) da **rotina**. Em **linguagens** como o Ruby, o **valor** **devolvido** nessas circunstâncias é o valor da última **instrução**. (Nota: Em Snap! usa-se o termo *reportar* com o significado de **retornar** **devolvendo**.) [](http://farm9.staticflickr.com/8225/8365738000_80e83fe78b_o.gif "Reportando por Manuel Menezes de Sequeira, no Flickr")

Question 55

***software* \* de computadores** software computer \*

Answer 55

O ***software* de computadores** ou simplesmente ***software*** é qualquer colecção de **programas de computador** e **dados** relacionados que fornecem as **instruções** para dizer a um **computador** o que fazer e como fazê-lo. O termo refere-se a um ou mais **programas de computador** e **dados** armazendados no **computador**. Por outras palavras, ***software*** é qualquer conjunto de **programas**, **rotinas**, **algoritmos** e respectiva documentação relacionados com a operação de um sistema de processamento de **dados**. O ***software*** realiza as funções do **programa** que implementa, quer fornecendo directamente instruções à electrónica digital, quer servindo de **entrada** a outro ***software***. O termo foi cunhado de modo a contrastar com o termo mais antigo «*hardware*» (que se aplica a dispositivos físicos). Ao contrário do *hardware*, o ***software*** é intangível (não se lhe pode tocar). [[Wikipédia](http://en.wikipedia.org/wiki/Software)]

Question 56

**tempo de execução** run time

Answer 56

Na **ciência da computação**, **tempo de execução** é o período de tempo durante o qual o **programa** está em **execução**, em contraste com outras fases do ciclo de vida de um **programa**, tais como o **tempo de compilação**, o **tempo de ligação**, o **tempo de carregamento**, etc. Um **erro em tempo de execução**, ou simplesmente **erro de execução**, é um erro detectado durante ou após a **execução** de um **programa**. Um **erro em tempo de compilação**, ou simplesmente **erro de compilação**, é um erro detectado pelo **compilador** antes de o **programa** alguma vez **executar**. A **verificação de tipos**, a **alocação de espaço de armazenagem** (parcialmente), a **geração de código** e a **optimização** são tipicamente realizadas em **tempo de compilação**, embora possam ser realizadas em **tempo de execução**, dependendo da **linguagem** em particular e da sua forma de **execução**. [[Wikipédia](http://en.wikipedia.org/wiki/Run_time_%28program_lifecycle_phase%29)] É típico usar-se o adjectivo **dinâmico** para aquilo que ocorre ou é definido em **tempo de execução**. (Nota: Nas **linguagens de programação** **interpretadas**, por definição, não existe **tempo de compilação**.)

Question 57

**valor** value

Answer 57

Na **ciência da computação**, um **valor** é uma **expressão** que não é passível de cálculo adicional. Por exemplo, a **expressão** 1 + 2 não é um **valor**, uma vez que pode ser reduzida à **expressão** 3. Esta **expressão** não é passível de reduções adicionais, sendo por isso um **valor**. Os membros de um **tipo** são os **valores** desse **tipo**. [[Wikipédia](http://en.wikipedia.org/wiki/Value_%28computer_science%29)]

Question 58

**valor literal literal** literal value literal

Answer 58

Na ciência da computação, um **literal** é uma notação para representar um **valor** fixo no **código fonte**. Quase todas as **linguagens de programação** possuem notações para **literais** inteiros, de vírgula flutuante, cadeias de caracteres (texto) e **booleanos**. Algumas têm também notações para elementos de **tipos enumerados** e para **valores** compostos tais como **listas**, registos e **objectos**. Ao contrário dos **valores literais**, as **variáveis** e as **constantes** são símbolos que podem tomar **valores**, tendo as **constantes** a restrição adicional de não poderem sofrer alterações. [[Wikipédia](http://en.wikipedia.org/wiki/Literal_%28computer_programming%29)] Alguns dos valores literais em Snap!: [](http://farm9.staticflickr.com/8227/8367171915_0b7304e057_o.gif "Os valores literais por Manuel Menezes de Sequeira, no Flickr")

Question 59

**variável global** global variable

Answer 59

Na **programação de computadores**, uma **variável global** é uma **variável** que é acessível a partir de qualquer **escopo** (excepto quando outra entidade com o mesmo nome se interpuser). Os mecanismos de interacção com **variáveis globais** são chamados mecanismos do contexto global ou do **estado** global. O paradigma do contexto global contrasta com o paradigma do contexto local, no qual todas as **variáveis** são **variáveis locais** sem memória partilhada. As **variáveis globais** são geralmente consideradas uma má prática justamente devido à sua não localidade: uma **variável global** pode potencialmente ser alterada a partir de qualquer local e qualquer parte do **programa** pode depender dela. Uma **variável global** tem, por isso, um potencial ilimitado para criar dependências mútuas, o que aumenta a complexidade do **programa**. [[Wikipédia](http://en.wikipedia.org/wiki/Global_variable)] (Nota: A utilização de **constantes globais** é, pelo contrário, considerada uma boa prática.) [](http://farm9.staticflickr.com/8325/8367193605_2e25a8daea_o.png "As variáveis por Manuel Menezes de Sequeira, no Flickr")

Question 60

**variável local** local variable

Answer 60

Na **programação de computadores**, uma **variável local** é uma **variável** com um **escopo** ou **âmbito** local. Uma **variável local** é acessível apenas a partir da **rotina** ou do bloco de **instruções** (nota: não confundir com os *blocos* do Snap!) no qual está declarada. Em **linguagens de programação** com apenas dois níveis de visibilidade, as **variáveis locais** contrastam com as **variáveis globais**. Linguagens como o ALGOL e suas derivadas permitem qualquer número de níveis de **rotinas** aninhadas dentro de outras **rotinas**, com **variáveis** privadas, **rotinas**, **constantes** e **tipos** ocultados dentro deles. Na maioria das **linguagens**, as **variáveis locais** são **variáveis** automáticas, criadas directamente na pilha de invocações (*call stack*). Isso significa que quando uma **rotina** **recursiva** se **invoca** a si mesma, as **variáveis locais** em cada instância da **rotina** em **execução** num dado momento recebem endereços distintos, ou seja, há tantas instâncias (com o mesmo nome) das **variáveis locais** quantas as instâncias da **rotina** recursiva em **execução**. Assim, **variáveis** com este **escopo** podem ser declaradas, escritas e lidas sem qualquer risco de **efeitos laterais** em **rotinas** fora do bloco no qual estão declaradas. Nas **linguagens de programação** que usam a semântica de **passagem de argumentos por valor**, os **parâmetros** de uma **rotina** são tratados como **variáveis locais** dessa **rotina**, embora com a particularidade de serem inicializados com os valores dos **argumentos** usados na sua **invocação**. As **variáveis locais** são usadas para evitar os problemas de **efeitos laterais** que podem ocorrer com as **variáveis globais**. [[Wikipédia](http://en.wikipedia.org/wiki/Local_variable)] (Nota: No Snap! as **variáveis locais** são conhecidas como *variáveis de guião*.) [](http://farm9.staticflickr.com/8325/8367193605_2e25a8daea_o.png "As variáveis por Manuel Menezes de Sequeira, no Flickr")

Question 61

**acção**¹ action¹

Answer 61

Influência ou efeito produzido sobre o estado de um programa.

Question 62

**acumulador** accumulator

Answer 62

Um **acumulador** é uma **variável** utilizada num **ciclo** para acumular o resultado de uma dada operação. É usual os **acumuladores** serem **inicializados** com o elemento neutro da operação em causa. [](http://farm9.staticflickr.com/8054/8364037293_fcc99fe779_o.gif "Um acumulador por Manuel Menezes de Sequeira, no Flickr")

Question 63

**até que 〈a guarda〉, repete [o passo]** until 〈guard〉, do [step]

Answer 63

**Instrução iterativa** que implementa a noção de **ciclo controlado por guarda**. A **guarda** é inicial, o que significa que o **passo** do **ciclo** pode não chegar a ser **executado** nenhuma vez. A iteração dá-se quando a **guarda** é falsa. O **ciclo** termina quando a **guarda** é verdadeira. (Nota: O Snap! possui um *bloco primitivo* deste tipo.) [](http://farm9.staticflickr.com/8194/8364469783_96df89cd89_o.gif "O «até que, repete» por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8094/8432811007_5bf3a85b24_o "O fluxograma do «até que, repete» por Manuel Menezes de Sequeira, no Flickr")

Question 64

**atributo**² attribute²

Answer 64

Um **atributo** ou **propriedade** de um **objecto** é uma qualidade observável desse mesmo **objecto**. Os **atributos**, enquanto qualidade genérica, são normalmente partilhados entre os **objectos** ou **instâncias** de uma **classe**. Por exemplo, todas as cartas de jogar têm um naipe. Os **valores** dos atributos dos diferentes **objectos** de uma **classe** são independentes entre si. Por exemplo, todos os humanos têm altura, mas cada humano tem a sua própria altura (que, naturalmente, pode coincidir com a de outros humanos). Os **atributos** têm normalmente associados um nome (e.g., «altura»), um **tipo** (e.g., «número real») e um **valor** (e.g., 1,72). O nome e o **tipo** são normalmente partilhados por todos os **objectos** de uma **classe**, fazendo parte da definição dessa **classe**, quando ela for explícita. Os **atributos** não têm necessariamente de corresponder a **variáveis de instância**.

Question 65

***bloco*** *block*

Answer 65

Os *blocos* são o tipo básico de **módulo** de decomposição no Scratch e no Snap!. Aos *blocos* fornecidos pelo Snap! chama-se *blocos primitivos*. Aos *blocos* criados pelo **programador** à custa de outros *blocos* chama-se *blocos personalizados*. Há duas formas distintas de olhar para os *blocos*. Quando presentes numa *palete*, representam entidades únicas, i.e., definidas uma única vez por um **produtor**, às quais se pode recorrer nos **guiões**. Quando presentes em **guiões**, são **invocações** ou **execuções** dessas entidades por parte de **código** de um **cliente**. Cada *bloco* pertence a uma de três categorias distintas: a categoria dos *chapéus*, i.e., dos *blocos* que definem as circunstâncias em que um *guião* de um *objecto* inicia a sua **execução**, a categoria dos *comandos*, i.e., dos *blocos* que realizam **acções** quando são **executados**, e a categoria dos *repórteres*, i.e., dos blocos que *reportam* valores calculados quando são **invocados**. Ao subconjunto dos *repórteres* que *reportam* um valor **booleano** chama-se **predicados**. O termo *bloco* é específico do Scratch e do Snap! e significa aproximadamente o mesmo que **rotina**. (Nota: alguns *repórteres* são também *construtores*, pois *reportam* um *objecto* por eles criado, tendo por isso **efeitos laterais** evidentes.) [](http://farm9.staticflickr.com/8329/8364491195_6ece7c8619_o.gif "Os blocos por Manuel Menezes de Sequeira, no Flickr")

Question 66

***bloco personalizado*** *custom block*

Answer 66

Um *bloco personalizado* é um *bloco* criado pelo **programador** ou que por ele pode ser modificado. Os *blocos* não personalizados dizem-se *blocos primitivos*. [](http://farm9.staticflickr.com/8077/8364525851_58fde77f66_o.gif "Um bloco personalizado - definição por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8196/8364526143_49c17b3966_o.gif "Um bloco personalizado - utilização por Manuel Menezes de Sequeira, no Flickr")

Question 67

***bloco primitivo*** *primitive block*

Answer 67

Um *bloco primitivo* é um *bloco* fornecido com o Snap!, i.e., que não foi criado pelo **programador** nem por ele pode ser modificado. Os *blocos* não primitivos dizem-se *blocos personalizados*. [](http://farm9.staticflickr.com/8378/8364536873_230cf1d211_o.gif "Um bloco primitivo por Manuel Menezes de Sequeira, no Flickr")

Question 68

**booleano** boolean

Answer 68

Um **tipo** de dados disponível em quase todas as **linguagens de programação**, inclusive no Scratch e no Snap!. Possui apenas dois valores distintos: «verdadeiro» e «falso».

Question 69

**classe** class

Answer 69

Um conjunto de **objectos** possuindo o mesmo comportamento (mas usualmente diferindo no seu **estado**) [[Wikcionário](http://en.wiktionary.org/wiki/class)]. As **classes** são um conceito importante em muitas **linguagens de programação** suportando o **paradigma** da **programação orientada por objectos**. Noutras destas **linguagens de programação**, porém, tal como no caso do Snap!, as **classes** existem apenas implicitamente, tendo como manifestação concreta um **objecto** especial, chamado **protótipo**, a partir do qual as restantes **instâncias** dessa classe são obtidas. Essas **instâncias** são obtidas por clonagem.

Question 70

**constante constante global** constant global constant

Answer 70

Uma **constante** é um **identificador** cujo **valor** associado tipicamente não pode ser alterado pelo **programa** durante a sua **execução** (embora por vezes esta restrição possa ser ultrapassada). Muitas **linguagens de programação** distinguem sintacticamente entre símbolos **constantes** e símbolos **variáveis**. Apesar de o **valor** de uma **constante** ser especificado uma única vez, uma **constante** pode ser referenciada múltiplas vezes ao longo de um **programa**. A utilização de uma **constante** em vez de um **valor literal** ao longo de um **programa** pode não apenas simplificar a manutenção do **código**, como também fornecer um nome significativo a esse **valor**. [[Wikipédia](http://en.wikipedia.org/wiki/Constant_%28programming%29)] Ao constrário do que se passa com as **variáveis**, que se desaconselha que tenham um âmbito global, é comum que as **constantes** sejam **constantes globais**, visíveis e utilizáveis em qualquer ponto do **programa**. (Nota: O Snap! não suporta a noção de **constante**. No entanto, pode-se definir um *repórter* com um nome apropriado e reportando sempre o mesmo **valor**; o efeito é quase o mesmo que se as **constantes** fossem suportadas nativamente.) [](http://farm9.staticflickr.com/8091/8365667354_43cf0683cf_o.gif "Uma constante global por Manuel Menezes de Sequeira, no Flickr")

Question 71

**definitude** definiteness

Answer 71

Uma das características dos **algoritmos**, segundo Donald Knuth: cada passo de um **algoritmo** tem de ser definido com precisão; as **acções** a realizar têm de ser especificadas rigorosa e não ambiguamente para cada caso [Donald Knuth, *The Art of Computer Programming, Volume 1: Fundamental Algorithms*, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973].

Question 72

**desenvolvimento de *software*** software development

Answer 72

O **desenvolvimento de *software*** (também conhecido como desenvolvimento de aplicações ou aplicacional, concepção ou desenho de *software*, desenvolvimento de aplicações de *software*, desenvolvimento de *software* empresarial ou desenvolvimento de plataformas) é o desenvolvimento de um produto de *software*. O termo **desenvolvimento de *software*** pode referir-se à actividade de **programação de computadores**, que é o processo de escrita e manutenção de **código fonte**, mas num sentido mais alargado refere-se também a qualquer actividade, idealmente realizada de forma planeada e estruturada, desde a idealização do *software* desejado até à sua manifestação final. Assim, o **desenvolvimento de *software*** pode incluir investigação, desenvolvimento, prototipagem, modificação, reutilização, reengenharia, manutenção ou qualquer outra actividade envolvida na produção de produtos de *software*. O *software* pode ser desenvolvido com variados propósitos, sendo que os três mais comuns são suprir as necessidades de um cliente ou negócio específico (caso do *software* personalizado), suprir as necessidades de um conjunto de potenciais utilizadores (caso do *software* comercial ou de código aberto) ou resolver um problema pessoal (e.g., um cientista pode **desenvolver** *software* para automatizar uma tarefa que precisa de realizar repetidamente). A necessidade de um melhor controlo da qualidade do processo de **desenvolvimento de *software*** originou a criação da disciplina da **engenharia do *software***, que se propõe aplicar a esse processo a abordagem sistemática exemplificada pelo paradigma da engenharia. [[Wikipédia](http://en.wikipedia.org/wiki/Software_development)]

Question 73

**dinamicamente tipificada** dynamically typed

Answer 73

Uma **linguagem de programação** com **tipificação dinâmica** diz-se **dinamicamente tipificada**.

Question 74

**dinâmico** dynamic

Answer 74

O adjectivo **dinâmico** aplica-se, na **ciência da computação**, a algo que ocorre ou se define apenas em **tempo de execução**. Este adjectivo contrapõe-se normalmente a **estático**, que se refere a algo que ocorre ou se define apenas em **tempo de compilação**.

Question 75

**eficácia**¹ effectiveness

Answer 75

Uma das características dos **algoritmos**, segundo Donald Knuth: em geral espera-se que um **algoritmo** seja **eficaz**, i.e., que todas as operações a **executar** no **algoritmo** sejam suficientemente básicas para poderem ser realizadas com exactidão e num intervalo de tempo finito por uma pessoa usando um papel e um lápis [Donald Knuth, *The Art of Computer Programming, Volume 1: Fundamental Algorithms*, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973].

Question 76

**enquanto 〈a guarda〉, repete [o passo]** while 〈guard〉, do [step]

Answer 76

**Instrução iterativa** que implementa a noção de **ciclo controlado por guarda**. A **guarda** é inicial, o que significa que o **passo** do **ciclo** pode não chegar a ser executado nenhuma vez. A iteração dá-se quando a **guarda** é verdadeira. O **ciclo** termina quando a **guarda** é falsa. (Nota: O Snap! não possui um *bloco primitivo* deste tipo. No entanto, pode-se facilmente criar um *bloco personalizado* para este efeito.) [](http://farm9.staticflickr.com/8195/8364220653_23628a8c76_o.gif "As partes de um ciclo por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8094/8366189058_0c9d025138_o.png "O fluxograma do «enquanto, repete» por Manuel Menezes de Sequeira, no Flickr")

Question 77

**entrada**^₁ input¹

Answer 77

Uma das características dos **algoritmos**, segundo Donald Knuth: um **algoritmo** tem zero ou mais **entradas**, i.e., quantidades que lhe são fornecidas inicialmente antes de o **algoritmo** começar [Donald Knuth, *The Art of Computer Programming, Volume 1: Fundamental Algorithms*, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973].

Question 78

**estaticamente tipificada** statically typed

Answer 78

Uma **linguagem de programação** com **tipificação estática** diz-se **estaticamente tipificada**.

Question 79

**estático** static

Answer 79

O adjectivo **estático** aplica-se, na **ciência da computação**, a algo que ocorre ou se define apenas em **tempo de compilação**. Este adjectivo contrapõe-se normalmente a **dinâmico**, que se refere a algo que ocorre ou se define apenas em **tempo de execução**.

Question 80

**finitude** finiteness

Answer 80

Uma das características dos **algoritmos**, segundo Donald Knuth: um **algoritmo** tem de terminar sempre após um número finito de passos [Donald Knuth, *The Art of Computer Programming, Volume 1: Fundamental Algorithms*, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973].

Question 81

**fortemente tipificada** strongly typed

Answer 81

Uma **linguagem de programação** com **tipificação forte** diz-se **fortemente tipificada**.

Question 82

**fracamente tipificada** weakly typed

Answer 82

Uma **linguagem de programação** com **tipificação fraca** diz-se **fracamente tipificada**.

Question 83

**índice indexar indexação** index to index indexing

Answer 83

O **índice** de um **item** numa sequência, por exemplo, numa **lista**, é um número inteiro que identifica univocamente a sua posição. À operação de obter um **item** de uma sequência a partir do seu **índice** chama-se indexação. Em algumas **linguagens de programação**, e.g., no C e nas **linguagens** dele derivadas, o **índice** do primeiro **item** de uma sequência é 0 (zero). Noutras **linguagens**, e.g., no Snap!, o **índice** do primeiro **item** é 1 (um). Finalmente, há **linguagens** em que os **índices** dos **itens** de uma sequência podem pertencer a um qualquer conjunto enumerado, pelo que o **índice** do primeiro **item** pode ser qualquer número inteiro. [](http://farm9.staticflickr.com/8496/8366317917_f16690009b_o.gif "Listas, itens e indexação por Manuel Menezes de Sequeira, no Flickr")

Question 84

**inicialização**¹ initialization¹

Answer 84

Conjunto de **instruções** que precede um **ciclo** e estabelece as condições para que este possa iniciar-se. Pode, por exemplo, **atribuir** um valor inicial a uma **variável de controlo**, atribuir a um **acumulador** o elemento neutro da operação a acumular durante a **acção** do **ciclo**, etc. [](http://farm9.staticflickr.com/8195/8364220653_23628a8c76_o.gif "As partes de um ciclo por Manuel Menezes de Sequeira, no Flickr")

Question 85

**instância** instance

Answer 85

Um caso ou exemplar de uma **classe** (que tanto pode ser definida explicitamente como pode ser definida implicitamente através de um **protótipo**). Em **programação orientada por objectos**, os **objectos** são **instâncias** de **classes** obtidos por **instanciação** a partir da sua **classe** ou por **clonagem** a partir do seu **protótipo**.

Question 86

**invocação chamada** call

Answer 86

Acção de **invocar** ou **chamar** uma **rotina**.

Question 87

**item** item

Answer 87

Um **item** é um elemento de uma **lista**. Os **itens** de uma **lista** são indexáveis. O **índice** de um **item** é a sua posição na **lista**. (Nota: Em Scratch e em Snap! o **índice** do primeiro item de uma **lista** é 1.) [](http://farm9.staticflickr.com/8496/8366317917_f16690009b_o.gif "Listas, itens e indexação por Manuel Menezes de Sequeira, no Flickr")

Question 88

**lista** list

Answer 88

Uma **lista** é uma sequência de elementos (os **itens**), indexáveis usando **índices** inteiros, e sobre a qual se podem realizar operações típicas das **listas**, tais como remover ou inserir **itens**, substituir **itens**, obter o seu comprimento, obter o **item** correspondente a um dado **índice**, etc. [](http://farm9.staticflickr.com/8496/8366317917_f16690009b_o.gif "Listas, itens e indexação por Manuel Menezes de Sequeira, no Flickr")

Question 89

**ocultação de informação** information hiding

Answer 89

Na **ciência da computação**, a **ocultação de informação** é o princípio da segregação das decisões de desenho mais prováveis de sofrerem alterações num **programa de computador**, protegendo assim outras partes do **programa** da necessidade de modificações extensas no caso de essas decisões serem alteradas. A protecção envolve disponibilizar uma **interface** estável que isola o resto do **programa** da respectiva **implementação**, já que são justamente os pormenores de **implementação** que sofrem alterações mais frequentes. Dito de outra forma, a **ocultação de informação** é prevenção do acesso a certos aspectos de uma **classe** ou dos respectivos **objectos** pelos seus **clientes**. Essa prevenção pode ser conseguida recorrendo a mecanismos da **linguagem de programação** tais como a privacidade de **variáveis de instância** e de **métodos** de uma **classe** ou **objecto**. Pode-se dizer que a **ocultação de informação** é o princípio e que o **encapsulamento** é a técnica que suporta esse princípio. [[Wikipédia](http://en.wikipedia.org/wiki/Information_hiding)]

Question 90

**para cada (o item) em [a lista], repete [a acção]** for each (item) in [list], do [action]

Answer 90

**Instrução iterativa** que implementa a noção de **ciclo controlado por colecção**. A **acção** é realizada repetidamente, uma vez para **item** da **lista** dada, do início até o fim, tomando a **variável** «o item» em cada instante o valor do **item** corrente da **lista**. Neste tipo de **ciclo**, quer a **guarda**, quer o **progresso** são implícitos. (Nota: O Snap! não possui um *bloco primitivo* deste tipo. No entanto, pode-se facilmente criar um *bloco personalizado* para este efeito.) [](http://farm9.staticflickr.com/8079/8368047462_acf1a1b185_o.gif "O «para em, repete» por Manuel Menezes de Sequeira, no Flickr")

Question 91

**para (i) de (o início) a (o fim), repete [a acção]** for (i) from (first) to (last), do [action]

Answer 91

**Instrução iterativa** que implementa a noção de **ciclo controlado por contador**. A **acção** é realizada repetidamente, para valores sucessivos da **variável de controlo** entre o início e o fim indicados. O comportamento exacto deste tipo de ciclos depende da **linguagem de programação** em causa ou da **biblioteca** que os define. Alguns dos pontos de variação são se o início e o fim têm de ser números inteiros, se o fim é dado de forma inclusiva ou exclusiva, ou o que acontece quando o fim é menor do que o início. Neste tipo de **ciclo**, quer a **guarda**, quer o **progresso** são implícitos. (Nota: O Snap! não possui um *bloco primitivo* deste tipo. No entanto, pode-se facilmente criar um *bloco personalizado* para este efeito.) [](http://farm9.staticflickr.com/8511/8368031782_200538104c_o.gif "O «para de a, repete» por Manuel Menezes de Sequeira, no Flickr")

Question 92

**passagem de argumentos por referência** pass-by-reference call-by-reference

Answer 92

Na **passagem de argumentos por referência**, uma **rotina** recebe uma **referência** implícita a uma **variável** usada como **argumento**, e não uma cópia do seu valor. Isto significa que a **rotina** pode modificar, através de uma **atribuição**, a **variável** usada como **argumento**, **acção** essa que é visível pelo **código** que **invocou** a rotina. A **passagem de argumentos por referência** pode, assim, estabelecer um canal de comunicação adicional entre o **código** **invocador** e a **rotina** **invocada**. Este tipo de **passagem de argumentos** dificulta o rastreio das alterações provocadas por uma **invocação** de uma **rotina** e pode levar a erros subtis. Muitas **linguagens** suportam a **passagem de argumentos por referência** de alguma forma, mas são poucas as **linguagens** (e.g., o Perl) em que este é o tipo de **passagem de argumentos** por omissão. Em algumas linguagens, como o C++, o PHP ou o C#, a **passagem de argumentos** é feita por **valor**, mas é possível usar uma sintaxe especial na declaração dos **parâmetros** das **rotinas** para obter **passagem de argumentos por referência**. Quando as entidades **referenciadas** são **imutáveis**, a **passagem de argumentos por referência** é indistinguível da **passagem por valor** simples. Nas **linguagens de programação** do **paradigma** da **programação funcional** não há diferença semântica entre a **passagem de argumentos por valor** e a **passagem de argumentos por referência**, pois todas as **estruturas de dados** são **imutáveis**. Note-se que em muitas **linguagens**, tal como no Java (excepto no caso dos tipos primitivos) ou no próprio Snap!, as **variáveis** guardam **referências** para os **valores** ou **objectos** que lhes são atribuídos. Nesse caso, a **passagem de argumentos por valor** corresponde na realidade a uma cópia de **referências**, pelo que as entidades referenciadas podem ser alteradas, desde que sejam **mutáveis**. A este tipo de **passagem de argumentos** pode-se chamar **passagem de referências por valor**. [[Wikipédia](http://en.wikipedia.org/wiki/Pass-by-reference#Call_by_reference)] (Nota: A **passagem de argumentos por referência** não existe no Snap!, que tem apenas **passagem de referências por valor**.) Exemplo de **passagem de argumentos por valor** e de **passagem de argumentos por referência** (usando o símbolo `&` para o indicar) em C++: `  $ cat swap.c++ ``  ``#include ` `  ``using namespace std;` `  ``void swapNot(int m, int n) {   ``  ``  int const temporary = m;     ``  ``m = n;     ``  ``n = temporary; ``  ``}` `  ``void swap(int& m, int& n) {   ``  ``  int const temporary = m;     ``  ``m = n;     ``  ``n = temporary; ``  ``}` `  ``int main() {   ``  ``  int a = 3, b = 7;     ``  ``cout << a << " " << b << endl;     ``  ``swapNot(a, b); ``    ``  ``cout << a << " " << b << endl;` `    ``  ``swap(a, b); ``    ``  ``cout << a << " " << b << endl;` `  ``} ``  ``$ c++ swap.c++ -o swap ``  ``$ ./swap ``  ``3, 7 ``  ``3, 7 ``  ``7, 3` `  ``$ `` `

Question 93

**passagem de referências por valor** passing of references by value

Answer 93

A **passagem de referências por valor** ocorre em **linguagens** como o Java (excepto no caso dos tipos primitivos) ou o Snap! que usam **passagem de argumentos por valor**, mas em que as **variáveis** não guardam directamente **valores**, **instâncias** ou **objectos**, mas sim **referências** para eles, sendo por isso possível alterar as entidades referenciadas, desde que **mutáveis**, a partir do interior da **rotina** **invocada**, de forma semelhante ao que acontece quando se usa **passagem de argumentos por referência**. [[Wikipédia](http://en.wikipedia.org/wiki/Pass-by-reference#Call_by_reference)] (Nota: Quando as entidades **referenciadas** são **imutáveis**, a **passagem de referências por valor** é indistinguível da **passagem por valor** simples.) [](http://farm9.staticflickr.com/8494/8367838224_843e8231fc_o.png "Passagem de referências por valor por Manuel Menezes de Sequeira, no Flickr")

Question 94

**programação declarativa programação lógica** declarative programming logic programming

Answer 94

A **programação declarativa** ou **programação lógica** é um **paradigma de programação** que permite que um **programa** modele um problema declarando o resultado que o **programa** deve atingir, e não a forma como esse resultado deve ser atingido. Por vezes estas **linguagens** são apelidadas de **linguagens baseadas em regras**, pois as declarações feitas pelos **programas** assemelham-se mais a um conjunto de regras ou a restrições sobre o problema do que a uma sequência de **instruções** a **executar**. A **programação declarativa** ou **programação lógica** surgiu com um **paradigma** distinto nos anos 70 do século XX. A **programação declarativa** distingue-se dos restantes **paradigmas** por requerer que o **programador** declare os objectivos da computação, e não o **algoritmo** pormenorizado através do qual esses objectivos podem ser atingidos. Os objectivos são expressos como uma colecção de asserções (afirmações) ou regras acerca dos resultados e das restrições da computação. [Allen B. Tucker e Robert E. Noonan, *Programming Languages: Principles and Paradigms*, segunda edição, McGraw-Hill, Boston, 2007] Abaixo ilustram-se os três principais **paradigmas de programação** através de implementações do **algoritmo** de Euclides para o [obtenção do máximo divisor comum de dois números em Prolog, Scheme e Java](http://rosettacode.org/wiki/Greatest_common_divisor) («gcd» é a abreviatura de «greatest common divisor»). Prolog (**programação lógica**): > `gcd(X, 0, X):- !. gcd(0, X, X):- !. gcd(X, Y, D):- X > Y, !, Z is X mod Y, gcd(Y, Z, D). gcd(X, Y, D):- Z is Y mod X, gcd(X, Z, D).` Scheme (**programação funcional**): > `(define (gcd a b)   (if (= b 0)       a       (gcd b (modulo a b))))` Java (**programação imperativa**): > `public static int gcd(int a, ` > `                      int b) {     while (b > 0) {         int c = a % b;         a = b;         b = c;     }     return a; }`

Question 95

**programação funcional** functional programming

Answer 95

A **programação funcional** é um **paradigma de programação** que modela os problemas computacionais como colecções de **funções**, cada uma com um domínio e um contra-domínio. Este facto distingue claramente as **linguagens funcionais** das **linguagens** que possuem uma **instrução** de **atribuição**. As **funções** interagem e combinam-se através da composição funcional, de condicionais e da **recursividade**. As principais **linguagens funcionais** incluem o Lisp, o Scheme, o Haskell e o ML. A **programação funcional** surgiu como um **paradigma** distinto no início dos anos 60 do século XX. A sua criação foi motivada pelas necessidades dos investigadores da **inteligência artificial** e respectivos ramos – computação simbólica, demonstração de teoremas, sistemas baseados em regras e processamento de línguas naturais. Essas necessidades não eram bem supridas pelas **linguagens imperativas** da época. A **linguagem funcional** original foi o **Lisp**, criada por John McCarthy. A sua descrição é notavelmente clara e breve, tendo o manual original apenas 106 páginas. [Allen B. Tucker e Robert E. Noonan, *Programming Languages: Principles and Paradigms*, segunda edição, McGraw-Hill, Boston, 2007] Abaixo ilustram-se os três principais **paradigmas de programação** através de implementações do **algoritmo** de Euclides para o [obtenção do máximo divisor comum de dois números em Prolog, Scheme e Java](http://rosettacode.org/wiki/Greatest_common_divisor) («gcd» é a abreviatura de «greatest common divisor»). Prolog (**programação lógica**): > `gcd(X, 0, X):- !. gcd(0, X, X):- !. gcd(X, Y, D):- X > Y, !, Z is X mod Y, gcd(Y, Z, D). gcd(X, Y, D):- Z is Y mod X, gcd(X, Z, D).` Scheme (**programação funcional**): > `(define (gcd a b)   (if (= b 0)       a       (gcd b (modulo a b))))` Java (**programação imperativa**): > `public static int gcd(int a, ` > `                      int b) {     while (b > 0) {         int c = a % b;         a = b;         b = c;     }     return a; }`

Question 96

**referência** reference

Answer 96

Uma entidade que se refere a uma outra entidade. Em **linguagens de programação** como o Java ou o Snap!, as **variáveis** guardam **referências** para **valores** ou **objectos** de diversos possíveis **tipos**. As **referências** implementam a noção de «indirecção»: como uma **referência** não é o **objecto** referenciado e o mesmo **objecto** pode ser referenciado por diferentes **referências**, alterações ao **objecto** referenciado por uma **referência** são visíveis através de qualquer outra **referência** para esse **objecto**. (Nota 1: Às **referências** também se pode chamar «ponteiros», embora haja **linguagens**, como o C++, que distinguem os dois termos, redefinindo-os. Nota 2: Em Java as **variáveis** de **tipos primitivos** não guardam **referências**: guardam directamente **valores** do **tipo** correspondente. Nota 3: Quando **objecto** referenciado é **imutável**, não há diferença observável entre o caso em que as **variáveis** guardam directamente os **valores** e o caso em que as **variáveis** guardam **referências** para esses **valores**.)

Question 97

**repete [o passo] até que 〈a guarda〉** do [step] until 〈guard〉

Answer 97

**Instrução iterativa** que implementa a noção de **ciclo controlado por guarda**. A **guarda** é final, o que significa que o **passo** do **ciclo** é sempre **executado** pelo menos uma vez. A iteração dá-se quando a **guarda** é falsa. O **ciclo** termina quando a **guarda** é verdadeira. (Nota: O Snap! não possui um *bloco primitivo* deste tipo. No entanto, pode-se facilmente criar um *bloco personalizado* para este efeito.) [](http://farm9.staticflickr.com/8510/8365038757_cbea01543d_o.gif "O «repete até que» por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8466/8434184309_8e5b7f2b90_o.png "O fluxograma do «repete até que» por Manuel Menezes de Sequeira, no Flickr")

Question 98

**repete [o passo] enquanto 〈a guarda〉** do [step] while 〈guard〉

Answer 98

**Instrução iterativa** que implementa a noção de **ciclo controlado por guarda**. A **guarda** é final, o que significa que o **passo** do **ciclo** é sempre **executado** pelo menos uma vez. A iteração dá-se quando a **guarda** é verdadeira. O **ciclo** termina quando a **guarda** é falsa. (Nota: O Snap! não possui um *bloco primitivo* deste tipo. No entanto, pode-se facilmente criar um *bloco personalizado* para este efeito.) [](http://farm9.staticflickr.com/8369/8365060915_c657fc61f1_o.gif "O «repete enquanto» por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8354/8434190147_a3e8237ff6_o.png "O fluxograma do «repete enquanto» por Manuel Menezes de Sequeira, no Flickr")

Question 99

**repete [o passo] para sempre** repeat [step] forever loop [step]

Answer 99

**Instrução iterativa** que implementa a noção de **ciclo infinito**. Salvo alguma **instrução** intermédia que force a terminação do **ciclo**, o **passo** é realizado um número infinito de vezes. Note-se que é típico que o **progresso** seja indicado explicitamente, embora não tenha real influência sobre a **guarda**, que é implícita e cujo valor é **constante**. Este tipo de **ciclo**, por forma a terminar, obriga à utilização de uma ou várias **instruções** intermédias, controladas por **instruções condicionais**, que forcem a sua terminação. Quando isso acontece, as guardas do **ciclo** são, na realidade, as **guardas** dessas **instruções condicionais** (Nota: O Snap! possui um *bloco primitivo* deste tipo. A terminação destes **ciclos** em Snap! faz-se usando os *comandos* de paragem de *guiões* ou o *comando* de *reporte* dentro de um *repórter*.) [](http://farm9.staticflickr.com/8463/8368124874_92298a9d1b_o.gif "O «repete para sempre» por Manuel Menezes de Sequeira, no Flickr") O fluxograma genérico do ciclo: [](http://farm9.staticflickr.com/8507/8434202415_6b04d6cc05_o.png "O fluxograma do «repete para sempre» por Manuel Menezes de Sequeira, no Flickr") O fluxograma do exemplo mais acima, com uma saída intermédia: [](http://farm9.staticflickr.com/8236/8435286650_ee8843dbc6_o.png "O fluxograma do «repete para sempre» com saída intermédia por Manuel Menezes de Sequeira, no Flickr")

Question 100

**saída** output

Answer 100

Uma das características dos **algoritmos**, segundo **Donald Knuth:** um **algoritmo** tem uma ou mais **saídas**, i.e., quantidades que têm uma relação especificada com as **entradas** [Donald Knuth, *The Art of Computer Programming, Volume 1: Fundamental Algorithms*, 2.ª edição, Addison-Wesley, Reading, Massachusetts, E.U.A., 1973].

Question 101

**tempo de compilação** compile time

Answer 101

Na **ciência da computação**, **tempo de compilação** é o tempo durante o qual podem agir ferramentas de análise, incluindo o próprio **compilador**, que incidem sobre o **código fonte**. A expressão pode ser usada para adjectivar as operações realizadas por um compilador (**operações em tempo de compilação**), os requisitos da **linguagem** que têm de ser cumpridos para que o **programa** possa ser **compilado** com sucesso (**requisitos de tempo de compilação**), ou as propriedades do **programa** que podem ser analisadas em **tempo de compilação**. As operações realizadas em **tempo de compilação** incluem normalmente a **análise sintática**, vários tipos de **análise semântica** (e.g., **verificação de tipos**, em linguagens **estaticamente tipificadas**) e **geração de código**. [[Wikipédia](http://en.wikipedia.org/wiki/Compile_time)] É típico usar-se o adjectivo **estático** para aquilo que ocorre ou é definido em **tempo de compilação**. (Nota: Nas **linguagens de programação** **interpretadas**, por definição, não existe **tempo de compilação**.)

Question 102

**tipificação** typing

Answer 102

Por **tipificação** entende-se a forma de aplicação da noção de **tipos** a uma dada **linguagem de programação**, especialmente no que respeita à sua validação. Assim, pode-se dizer que a **tipificação** do C# é **tipificação forte** e **tipificação estática**, e que a **tipificação** do Snap! é **tipificação forte** e **tipificação dinâmica**.

Question 103

**tipificação dinâmica** dynamic typing

Answer 103

Diz-se que uma **linguagem de programação** usa **tipificação dinâmica** quando a verificação de **tipos** é realizada sobretudo em **tempo de execução**, e não em **tempo de compilação**. Na **tipificação dinâmica** as **variáveis** têm apenas uma característica fixa durante a **execução** do programa: o seu nome. As **variáveis**, assim, não têm **tipo**, que por isso não precisa de ser declarado. Os **tipos** estão associados, não às **variáveis**, mas sim aos **valores**, **instâncias** ou **objectos**. Assim, uma **variável** pode **referir-se** a um **valor**, **instância** ou **objecto** de qualquer **tipo**. As seguintes **linguagens**, por exemplo, são **dinamicamente tipificadas**: Erlang, Groovy, JavaScript, Lisp, MATLAB, PHP, Python, Ruby e Smalltalk. [[Wikipédia](http://en.wikipedia.org/wiki/Type_system#Dynamic_typing)] (Nota: O Snap! é **dinamicamente tipificado**.)

Question 104

**tipificação estática** static typing

Answer 104

Diz-se que uma **linguagem de programação** usa **tipificação estática** quando a **verificação de tipos** é realizada durante o **tempo de compilação**, e não durante o **tempo de execução**. As seguintes **linguagens**, por exemplo, são **estaticamente tipificadas**: Ada, C, C++, Eiffel, Fortran, Go, Haskell, Java, Objective-C, Pascal e Scala. Nos **programas** escritos em **linguagens** com **tipificação estática**, as **variáveis** são de declaração obrigatória, exigindo-se que o **compilador** possa determinar o seu **tipo**, quer porque este é indicado explicitamente na **declaração** da **variável**, quer porque é possível inferir esse **tipo** a partir do contexto em que a **variável** se encontra. Assim, nas **linguagens** com **tipificação estática**, as **variáveis** têm duas características que se mantêm fixas durante a **execução** do **programa**: o seu nome e o seu **tipo**. A **tipificação estática** é uma forma limitada de **verificação de programas**, permitindo a detecção de muitos tipos de erros logo no início do ciclo de **desenvolvimento**. Os verificadores **estáticos** de **tipos** avaliam apenas a informação sobre **tipos** que pode ser determinada em **tempo de compilação**. No entanto, as verificações que realizam são válidas para todas as possíveis **execuções** do **programa**, o que elimina a necessidade de repetir essas verificações sempre que o **programa** é **executado**. A **execução** do **programa** pode assim ser feita de forma mais eficiente (e.g., mais rapidamente ou consumindo menos **memória**), pois eliminam-se verificações em **tempo de execução** e tornam-se possíveis outros tipos de optimização. [[Wikipédia](http://en.wikipedia.org/wiki/Type_system#Static_typing)] (Nota: O Snap! não é **estaticamente tipificado**, mas sim **dinamicamente tipificado**.)

Question 105

**tipificação forte** strong typing

Answer 105

Na **ciência da computação** e na **programação de computadores**, um **sistema de tipos** diz-se **forte** quando especifica uma ou mais restrições na forma como podem ser combinadas operações envolvendo valores de diferentes **tipos**. O antónimo de **tipificação forte** é **tipificação fraca**. Em geral, a **tipificação forte** implica que a **linguagem de programação** restringe fortemente as combinações permitidas entre **valores** de diferentes **tipos**, impedindo a **compilação** ou a **execução** de **código fonte** que use os dados de forma considerada inválida. Por exemplo, a operação da adição pode não permitir adicionar um número inteiro a uma **cadeia de caracteres**, uma **rotina** que opere sobre **listas** não pode ser usada para operar sobre **números**, etc. A natureza e força das restrições são, no entanto, muito variáveis entre as **linguagens de programação** **fortemente tipificadas** (e.g., o C#, o Java, o Ruby ou o Snap!). [[Wikipédia](http://en.wikipedia.org/wiki/Strong_typing)] (Nota: O Snap! é **fortemente tipificado**.)

Question 106

**tipo tipo de dados** type data type

Answer 106

Na ciência da computação e na **programação de computadores**, um **tipo de dados** ou simplesmente **tipo** é uma classificação identificando um de vários tipos de **dados**, tais como de vírgula flutuante, inteiro ou booleano, que determina os possíveis **valores** para esse **tipo**, as **operações** que podem ser realizadas usando **valores** desse **tipo**, o significado dos **dados** e a forma de armazenagem dos **valores** desse **tipo**. Os **tipos de dados** são usados no contexto de **sistemas de tipos** que fornecem formas variadas de os definir e utilizar. Diferentes **sistemas de tipos** garantem diferentes graus de **segurança de tipos**. Quase todas as **linguagens de programação** incluem a noção explícita de **tipo de dados**, embora diferentes **linguagens de programação** usem diferente terminologia. [[Wikipédia](http://en.wikipedia.org/wiki/Datatype)] Alguns dos tipos do Snap!: [](http://farm9.staticflickr.com/8474/8368225528_613126d9ed_o.gif "Os tipos por Manuel Menezes de Sequeira, no Flickr")

Question 107

**variável de controlo** control variable

Answer 107

Na **programação de computadores**, uma **variável de controlo** é uma variável que é usada para regular o **fluxo do controlo** de um **programa**. Por exemplo, uma **variável de controlo** de um **ciclo** é usada para regular o número de vezes que o «corpo» desse **ciclo** é executado, sendo actualizada (e.g., incrementada ou decrementada) em cada **iteração** (repetição). [[Wikipédia](http://en.wikipedia.org/wiki/Control_variable)] Quando se consegue distinguir claramente entre a **acção** e o **progresso** (partes do **passo** de um **ciclo**), é usual que no **progresso** esteja envolvida apenas a **variável de controlo**. [](http://farm9.staticflickr.com/8087/8367337655_af2a89682c_o.gif "Uma variável de controlo por Manuel Menezes de Sequeira, no Flickr")

Question 108

**variável de instância** instance variable

Answer 108

Na **programação orientada por objectos**, uma **variável de instância** ou **variável de objecto** é uma variável associada a um **objecto** ou **instância** em particular. Nas **linguagens** suportando a noção explícita de **classe**, é usual que as **variáveis de instância** sejam **declaradas** na **classe** dos **objectos** ou **instâncias** em causa. Nas **linguagens** suportando a **programação baseada em protótipos**, as **variáveis de instância** são criadas usualmente nos **objectos protótipo**, sendo duplicadas durante a operação de clonagem (alternativamente, cada **clone** poderá partilhar a **variável de instância** com o **protótipo** até o momento em que tente alterar o seu **valor**, altura em que a duplicação será realizada). [](http://farm9.staticflickr.com/8325/8367193605_2e25a8daea_o.png "As variáveis por Manuel Menezes de Sequeira, no Flickr")

Question 109

***actor*** *sprite*

Answer 109

Um dos dois tipos de *objectos* cuja representação visual pode ser manipulada no Scratch e no Snap!, e ao qual podem ser associados *guiões*, *blocos personalizados* e **variáveis**. Ao contrário do que acontece no caso do *palco*, que é estático e do qual não existe senão uma **instância**, não há qualquer limitação quanto ao número de *actores*, que além disso são dinâmicos, podendo mover-se sobre o *palco*. [](http://farm9.staticflickr.com/8357/8365104812_bc4c549752_o.png "Um actor por Manuel Menezes de Sequeira, no Flickr")

Question 110

**ambiente integrado de desenvolvimento** integrated development environment

Answer 110

Um **ambiente integrado de desenvolvimento** (IDE) é uma aplicação de *software* que disponibiliza aos **programadores** um conjunto abrangente de ferramentas de **desenvolvimento de *software***. Um IDE consiste normalmente num editor de **código fonte**, ferramentas de automatização da construção e um **depurador**. [[Wikipédia](http://en.wikipedia.org/wiki/Integrated_development_environment)]

Question 111

***atributo***¹ *attribute*¹

Answer 111

Os *atributos* são qualidades que qualquer *objecto* (*actor* ou *palco*) tem automaticamente. Os *atributos* incluem o nome de um *actor*, o número do seu *traje* corrente, a sua orientação, etc. As *variáveis* dos *objectos* não são considerados *atributos*, no Snap! (Nota: Tanto os *atributos* como as *variáveis* de um *objecto* podem ser considerados como **atributos** no sentido mais lato deste termo em informática, particularmente em **programação orientada por objectos**.) [](http://farm9.staticflickr.com/8509/8364388705_984364226e_o.gif "Um atributo por Manuel Menezes de Sequeira, no Flickr")

Question 112

**biblioteca** library

Answer 112

Uma **biblioteca** é um conjunto coerente de ferramentas disponibilizadas num formato tal que podem ser usadas no código durante o desenvolvimento de outros **programas**. (Nota: No Snap! não há **bibliotecas** propriamente ditas, podendo no entanto recorrer-se à importação de projectos para dentro de outros como boa alternativa.)

Question 113

***chapéu*** *hat*

Answer 113

Um dos tipos de *bloco* no Scratch e no Snap!. Os *chapéus* são *blocos* especiais que marcam o início de *guiões* indicando as condições em que cada *guião* será **executado**. Por exemplo, o Snap! suporta *chapéus* que iniciam os seus *guiões* quando se clicar sobre a bandeira verde, quando uma dada tecla for premida, quando se clicar sobre a representação no *palco* de um dado *actor* ou quando se receber uma dada *mensagem difundida*. [](http://farm9.staticflickr.com/8360/8365617134_67b7711199_o.gif "Um chapéu por Manuel Menezes de Sequeira, no Flickr")

Question 114

**cliente** client

Answer 114

O termo **cliente** aplica-se a **programadores** humanos, enquanto utilizadores de ferramentas (tipicamente **módulos**) desenvolvidos por outros **programadores** ou desenvovidos por si mesmos anteriormente. As ferramentas são produzidas por um **produtor** e consumidas ou utilizadas por um **cliente**. O termo **cliente** também se aplica a troços de **código** que fazem uso de ferramentas desenvolvidas noutros locais. Por exemplo, ao desenvolver uma **função** para calcular a raiz quadrada, o **programador** assume o papel de **produtor** dessa função e o papel de **cliente** da **função** de cálculo de potências a que recorre para implementar a raiz quadrada. Nesse caso pode-se também dizer que o **código** de **implementação** da raiz quadrada é **cliente** da **função** de cálculo da potência. A distinção entre os papéis de **cliente** e **produtor** é fundamental para compreender a **programação por contrato**.

Question 115

***comando*** *command*

Answer 115

Um dos tipos de *bloco* no Scratch e no Snap!. Os *comandos* realizam acções, i.e., agem e têm efeito sobre o **estado** do mundo que lhes é exterior. Os *comandos* não *reportam* qualquer valor. O termo *comando* é específico do Scratch e do Snap! e significa o mesmo que **procedimento**. [](http://farm9.staticflickr.com/8361/8366002270_ebcb75c37b_o.gif "Os comandos por Manuel Menezes de Sequeira, no Flickr")

Question 116

***construtor*** *constructor*

Answer 116

Um *construtor* é um *repórter* que constrói um novo *objecto*. O *repórter* operador (um clone) é um construtor. Os contrutores têm efeitos laterais, nomeadamente a construção do novo objecto. [](http://farm9.staticflickr.com/8225/8365676308_200c0b46a3_o.gif "Um construtor por Manuel Menezes de Sequeira, no Flickr")

Question 117

**depurador** debugger

Answer 117

Um **depurador** ou ferramenta de depuração é um **programa** que é usado para testar e depurar outros **programas**, ditos **programas** «alvo». Os **depuradores** usualmente disponibilizam um conjunto de funções avançadas, tais como a **execução** de um **programa** passo a passo (**execução** de cada passo a pedido do utilizador ou animação de **programas**), paragem ou interrupção (colocação do **programa** em pausa para examinar o seu **estado** corrente), através de um ponto de paragem, quando ocorre algum evento ou se atinge uma dada **instrução** e rastreio dos valores de **variáveis**. [[Wikipédia](http://en.wikipedia.org/wiki/Debugger)]

Question 118

**desenvolvedor \* de *software*** developer software \*

Answer 118

Um **desenvolvedor de *software*** ou simplesmente **desenvolvedor** é uma pessoa com intervenção em aspectos do processo de **desenvolvimento de *software***. O seu trabalho inclui investigar, **conceber** ou **desenhar**, **implementar** e **testar** *software*. Um **desenvolvedor de *software*** pode estar envolvido na **concepção** ou **desenho**, na **programação** ou na **gestão de projectos de *software***. A sua contribuição pode ser feita ao nível aplicacional, e não necessariamente ao nível dos componentes ou das tarefas de **programação** individuais. Outras designações que também se utilizam em sentido muito semelhante são **programador**, **analista de *software*** e **engenheiro de *software***. [[Wikipédia](http://en.wikipedia.org/wiki/Software_developer)]

Question 119

**desenvolver \* *software*** to develop \* software

Answer 119

Estar envolvido, enquanto **desenvolvedor de *software***, no **desenvolvimento de *software*.**

Question 120

***difundir*** *to broadcast*

Answer 120

Quando os objectos do Scratch pretendem comunicar uns com os outros fazem-no através da *difusão* de *mensagens*. As *mensagens* são *difundidas*, o que significa que o emissor não pode impedir que sejam ouvidas por qualquer *objecto*. (Nota: O Snap! possibilita uma forma mais direccionada de comunicação, nomeadamente a *invocação* de *repórteres* ou *execução* de *comandos* no contexto de um dado *objecto*.) [](http://farm9.staticflickr.com/8075/8365798716_5a8c41ab84_o.gif "Difundindo por Manuel Menezes de Sequeira, no Flickr")

Question 121

**eficácia**² efficacy

Answer 121

Propriedade do que é **eficaz**, i.e., do que é capaz de produzir um determinado efeito. Note-se que a **eficácia** e a **eficiência** são conceitos distintos. Por exemplo, pode dizer-se que usar uma colher de chá é uma forma simultaneamente **eficaz** e muito pouco **eficiente** de esvaziar uma banheira.

Question 122

**eficiência algorítmica** algorithmic efficiency

Answer 122

Na **ciência da computação**, a palavra **eficiência** é usada para descrever propriedades de um **algoritmo** relacionadas com a quantidade de recursos de vários tipos que consome. Os recursos mais relevantes são usualmente o tempo consumido pela **execução** do **algoritmo** e a memória por ele exigida. [[Wikipédia](http://en.wikipedia.org/wiki/Algorithmic_efficiency)]

Question 123

***entrada***² *input*²

Answer 123

Termo usado no Snap! em vez do termo mais usual **parâmetro**. As *entradas* são **variáveis locais** a um dado *bloco* que são **inicializadas** com os valores dos correspondentes **argumentos** quando o *bloco* é *executado* ou *invocado*. As *entradas* são definidas no cabeçalho ou **protótipo** do *bloco*. No Snap! o termo *entrada* também é por vezes usado no sentido de **argumento**, i.e., valor passado a um *bloco* e que serve para inicializar a *variável* de *entrada* ou **parâmetro** correspondente. [](http://farm9.staticflickr.com/8497/8364970521_2881001b84_o.gif "As entradas - um parâmetro por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8221/8366042098_04fdb7e36f_o.gif "As entradas - um argumento por Manuel Menezes de Sequeira, no Flickr")

Question 124

**fluxograma** flowchart

Answer 124

Um **fluxograma** é um tipo de diagrama que representa um **algoritmo** ou um processo, apresentado os seus passos como caixas de vários tipos e evidenciando a ordem desses passos através de setas conectando as caixas. Esta representação em diagrama pode apresentar uma solução passo a passo para um dado problema. É possível usar **fluxogramas** para evidenciar o **fluxo de controlo** de um **programa** ou de uma **rotina**. Os **fluxogramas** são usados na análise, concepção, documentação e gestão de processos ou de **programas** em várias áreas do conhecimento, incluindo a **ciência da computação**. [[Wikipédia](http://en.wikipedia.org/wiki/Flowchart)] Fluxograma do ciclo [enquanto 〈a guarda〉, repete [o passo]]: [](http://farm9.staticflickr.com/8094/8366189058_0c9d025138_o.png "O fluxograma do «enquanto, repete» por Manuel Menezes de Sequeira, no Flickr")

Question 125

***forquilha*** *c-shape*

Answer 125

Representação visual de um tipo específico de *entrada* do Snap! que aceita *guiões* sem necessidade de os envolver no *repórter* (o guião). Esta representação visual é semelhante à usada, por exemplo, no *comando* [se 〈a guarda〉, então [o guião]]. [](http://farm9.staticflickr.com/8045/8365136023_1594bcb09a_o.gif "A forquilha por Manuel Menezes de Sequeira, no Flickr")

Question 126

***fundo*** *background*

Answer 126

Uma das possíveis imagens com as quais o *palco* se pode apresentar no Scratch e no Snap!. [](http://farm9.staticflickr.com/8514/8366440529_2381e3117a_o.png "Os fundos por Manuel Menezes de Sequeira, no Flickr")

Question 127

***guião*** *script*

Answer 127

Uma qualquer sequência de *comandos* encaixados uns nos outros. Um *guião* pode consistir num único *comando*. Os *guiões* podem criados em dois contextos: na *área de guiões* de um *objecto* (i.e., de um *actor* ou do *palco*) e dentro de um *bloco personalizado*. No primeiro caso são usualmente encabeçados por um *bloco* *chapéu* que define em que circunstâncias esse *guião* será executado. Os *guiões* dos *objectos* conferem-lhes comportamento. No segundo caso os *guiões* são encabeçados pelo *protótipo* do *bloco* e consistem na sua *implementação*. [](http://farm9.staticflickr.com/8328/8365176167_96a7a8569c_o.gif "Os guiões - de actor por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8465/8365176113_b1cd3fbd69_o.gif "Os guiões - de bloco por Manuel Menezes de Sequeira, no Flickr")

Question 128

***mensagem*** *broadcast*

Answer 128

Uma instância da única forma de comunicação entre *objectos* disponível no Scratch. No Snap! as *mensagens* são apenas uma das duas possíveis formas de comunicação entre *objectos*, sendo também possível um *objecto* pedir a um outro para **executar** um *guião* ou para *reportar* o resultado da **invocação** de um *repórter* no contexto desse outro *objecto*. Esta forma alternativa de comunicação disponível no Snap! permite a um *objecto* seleccionar um único parceiro de comunicação, algo que não é possível quando se recorre a mensagens, que sendo difundidas, podem ser ouvidas por qualquer *objecto*. Exemplo de comunicação através de mensagens: [](http://farm9.staticflickr.com/8215/8366397055_c0fc3a182c_o.png "Mensagens - o palco por Manuel Menezes de Sequeira, no Flickr") [](http://farm9.staticflickr.com/8374/8366397091_529832867d_o.png "Mensagens - o Alonzo por Manuel Menezes de Sequeira, no Flickr")

Question 129

***objecto***¹ *object*¹

Answer 129

No Snap!, *objecto* é o nome genérico que se dá aos *actores* e ao *palco*. Os *objectos* do Snap! são claramente **objectos**, no sentido em que suportam o **paradigma** da **programação orientada por objectos**, tendo **atributos** e **operações**, suportados por **variáveis de instância** (conhecidas, no Snap!, por *variáveis de actor*) e por **métodos** (correspondentes, no Snap!, a *blocos* e a *guiões* iniciados pela recepção de *mensagens*). É possível enviar **mensagens** aos *objectos*, quer através do mecanismo de *difusão* de *mensagens*, quer através da **invocação** de *repórteres* ou da **execução** de *comandos* no contexto de um outro *objecto*. Embora no contexto do Snap! não recebam o nome de *objecto*, há outras entidades no Snap! que também podem ser consideradas como **objectos**, incluindo as *listas* e os próprios *blocos*. Exemplo com três *objectos* (dois *actores* e um *palco*): [](http://farm9.staticflickr.com/8372/8366410593_60ac9181ca_o.png "Os objectos por Manuel Menezes de Sequeira, no Flickr")

Question 130

palco stage

Answer 130

Um dos dois tipos de *objectos* cuja representação visual pode ser manipulada no Scratch e no Snap!, e ao qual podem ser associados *guiões*, *blocos personalizados* e **variáveis** (ditas *variáveis de objecto*). Ao contrário do que acontece no caso dos *actores*, que são dinâmicos e dos quais podem existir múltiplas **instâncias**, há apenas um *palco*, que além disso é estático. Assim, os vários *actores* movem-se sobre o único *palco* existente. (Nota 1: No Snap! 3.1.1 não é possível associar *variáveis de objecto* ao palco. Nota 2: Há outros tipos de entidade com representação visual sobre o palco, no Snap!: as *variáveis de objecto* e as **variáveis globais**, bem como vários dos *atributos* dos *objectos*.) [](http://farm9.staticflickr.com/8331/8366423235_26945e5d45_o.png "O palco por Manuel Menezes de Sequeira, no Flickr")

Question 131

**primitivo** primitive

Answer 131

Um artefacto diz-se **primitivo** quando faz parte de uma **linguagem de programação** despida de quaisquer **bibliotecas**, incluindo as **bibliotecas** padrão (i.e., aquelas que acompanham a **linguagem**). [](http://farm9.staticflickr.com/8360/8367863740_03544d7bf5_o.gif "Primitivo e não primitivo por Manuel Menezes de Sequeira, no Flickr")

Question 132

**produtor** producer

Answer 132

O termo **produtor** aplica-se a **programadores** humanos, enquanto criadores de ferramentas (tipicamente **módulos**) para utilização por outros **programadores** ou por si mesmos no futuro. As ferramentas são consumidas ou utilizadas por um **cliente** e produzidas por um **produtor**. O termo **fornecedor** também se aplica a entidades (e.g., **bibliotecas**) que fornecem ferramentas para utilização noutros locais. Por exemplo, ao desenvolver uma **função** para calcular a raiz quadrada, o **programador** assume simultaneamente o papel de **produtor** dessa função e o papel de **cliente** da **função** de cálculo de potências a que recorre para implementar a raiz quadrada. Nesse caso pode-se também dizer que o **código** de **implementação** da raiz quadrada é **cliente** da **função** de cálculo da potência. A distinção entre os papéis de **cliente** e **produtor** é fundamental para compreender a **programação por contrato**.

Question 133

**programador \* de computadores** programmer computer \*

Answer 133

Um **programador**, **programador de computadores**, **desenvolvedor** ou codificador é uma pessoa que escreve **programas de computador**. O termo **programador de computadores** pode referir-se a um especialista numa área da **programação de computadores** ou a um generalista que escreve **código** para muitos tipos de *software*. Alguém que pratica ou professa uma abordagem formal à **programação** também pode ser conhecido como analista programador. A principal **linguagem de programação** do programador (C, C++, Java, Lisp, Python, etc.) é muitas vezes acrescentada às designações anteriores, o mesmo acontecendo com a palavra Web, no caso de **programadores** que trabalhem num ambiente Web. O termo **programador** pode ser usado para designar um **desenvolvedor de *software***, um desenvolvedor Web, um desenvolvedor de aplicações móveis, um desenvolvedor de *firmware* embebido, um engenheiro de *software*, um cientista da computação ou um analista de *software*. No entanto, os membros destas profissões possuem outras competências na área da engenharia do *software*, para além da **programação**, pelo que o termo **programador** é muitas vezes considerado como uma simplificação insultuosa ou depreciativa dessas profissões. [[Wikipédia](http://en.wikipedia.org/wiki/Programmer)]

Question 134

***protótipo***¹ *prototype*¹

Answer 134

O *protótipo* de um *bloco personalizado* corresponde à sua **interface**, definindo a sua categoria (*comando*, *repórter* ou *predicado*), a *palete* em que consta, o texto que nele surge, o número de **parâmetros** e **nome** e **tipo** de cada um deles, etc. O *protótipo* de um *bloco* é apresentado visualmente dentro do editor de *blocos*, acima do guião e incluído num *chapéu*. [](http://farm9.staticflickr.com/8494/8367967758_a60c605362_o.gif "Um protótipo por Manuel Menezes de Sequeira, no Flickr")

Question 135

***ranhura*** *slot*

Answer 135

Uma *ranhura* é um espaço disponível num dado *bloco* para colocação de **argumentos**, que podem tomar a forma de *valores literais* ou de outros *blocos* (e, em alguns casos, de selecções num menu). A cada *ranhura* corresponde uma *entrada* do *bloco* (ou um *item* numa *lista de entradas).* [](http://farm9.staticflickr.com/8326/8368002334_17fb229b38_o.gif "As ranhuras por Manuel Menezes de Sequeira, no Flickr")

Question 136

**repete [o passo] (n) vezes** repeat [step] [n] times

Answer 136

**Instrução iterativa** que implementa a noção de **ciclo controlado por contador**. O **passo** é realizado exactamente o número de vezes indicado. Note-se que é típico que o **progresso** seja indicado explicitamente, embora não tenha real influência sobre a **guarda**, que é implícita. Ou melhor, é típico que este tipo de **ciclo** tenha de ser complementado com uma **variável de controlo** e que o **progresso** se limite a fazer essa **variável** evoluir. (Nota: O Snap! possui um *bloco primitivo* deste tipo.) [](http://farm9.staticflickr.com/8055/8368071070_a6c532b21f_o.gif "O «repete vezes» por Manuel Menezes de Sequeira, no Flickr")

Question 137

***reportar*** *to report*

Answer 137

Termo específico do Snap! e que signfica **retornar** de um *repórter* **devolvendo** (ou *reportando*) um dado **valor** como resultado. [](http://farm9.staticflickr.com/8225/8365738000_80e83fe78b_o.gif "Reportando por Manuel Menezes de Sequeira, no Flickr")

Question 138

***repórter*** *reporter*

Answer 138

Um dos tipos de *bloco* no Snap!. Os *repórteres* não têm (ou não devem ter) *efeitos laterais*, limitando-se a calcular e *reportar* um **valor**. Um *repórter* bem construído não tem **efeitos laterais**, sendo por isso uma **função pura**. O termo *repórter* é específico do Scratch e do Snap! e significa o mesmo que **função**. Aos *repórteres* que *reportam* um novo *actor*, acabado de construir, e que por isso têm **efeitos laterais**, chama-se **construtores**. [](http://farm9.staticflickr.com/8358/8367088763_8634466733_o.gif "Os repórteres por Manuel Menezes de Sequeira, no Flickr")

Question 139

**retorno** return (em parte)

Answer 139

Aquilo que acontece quando uma **rotina** **retorna**.

Question 140

Scratch

Answer 140

O Scratch é uma **linguagem de programação** visual e um ambiente de aprendizagem da **programação** que permite aos iniciados obter resultados rapidamente sem terem de lidar com a complicação adicional de escreverem **código** sintacticamente correcto. Foi criado pelo MIT Media Lab e destina-se a motivar a aprendizagem através da experimentação lúdica e da criação de projectos envolvendo animações interactivas, jogos, etc. [[Wikipédia](http://en.wikipedia.org/wiki/Scratch_%28programming_language%29)]

Question 141

Snap!

Answer 141

O Snap! é uma versão avançada do Scratch, uma **linguagem de programação** visual e um ambiente de aprendizagem da **programação**. O Scratch é adequado para crianças e principiantes e foi desenvolvido pelo Lifelong Kindergarten Group no MIT Media Lab. O Snap! foi desenvolvido por Jens Mönig com contribuições de Brian Harvey, e é uma tentativa de estender a brilhante acessibilidade do Scratch para utilizadores um pouco mais avançados, embora sem o tornar inacessível à sua audiência original. O Snap! inclui **listas** e **actores** de primeira classe, bem como **blocos personalizados** suportando **recursividade**. [[Snap! na UCB](http://snap.berkeley.edu/)]

Question 142

**tipificação fraca** weak typing

Answer 142

O antónimo de **tipificação forte**.

Question 143

***traje*** *costume*

Answer 143

Uma das possíveis imagens com as quais um *actor* se pode apresentar no Scratch e no Snap!. [](http://farm9.staticflickr.com/8517/8366446569_b846c5043a_o.png "Os trajes por Manuel Menezes de Sequeira, no Flickr")

Question 144

***variável de actor*** *sprite variable*

Answer 144

O mesmo que *variável de objecto*, no Snap!.

Question 145

***variável de guião*** *script variable*

Answer 145

Nome dado no *Snap!* a uma **variável local**.

Question 146

***variável de objecto***¹ *object variable*¹

Answer 146

Nome dado no Scratch e no Snap! a uma **variável de objecto**² ou **variável de instância** de um *objecto*, ou seja, de um *actor* ou do *palco*. (Nota: No Snap! 3.1.1 o *palco* não pode ter as suas próprias variáveis, pelo que é comum chamar *variável de actor* a uma *variável de objecto*.) [](http://farm9.staticflickr.com/8325/8367193605_2e25a8daea_o.png "As variáveis por Manuel Menezes de Sequeira, no Flickr")

Question 147

**Alan Turing**

Answer 147

**Alan Turing** (nascido a 23 de Junho de 1912 e falecido a 7 de Junho de 1954) foi um matemático, lógico, analista criptográfico e cientista da computação britânico. Teve uma enorme influência no desenvolvimento da **ciência da computação**, formalizando os conceitos de **algoritmo** e **computação** através da chamada **máquina de Turing**, que pode ser considerada como um modelo de computador genérico. Turing é considerado como o pai da **ciência da computação** e da **inteligência artificial**. Durante a 2.ª Guerra Mundial, Turing trabalhou no centro de decifração britânico, tendo durante algum tempo chefiado a secção responsável por quebrar as cifras germânicas, onde desenvolveu várias técnicas de decifração. Depois da guerra, criou um dos primeiros desenhos de computador com os **programas** armazenados na memória, o ACE. A homossexualidade de Turing resultou no seu julgamento em 1952, numa altura em que os actos homossexuais eram ilegais no Reino Unido, tendo aceitado um «tratamento» com hormonas femininas (castração química) como alternativa à prisão. Morreu em 1954, a duas semanas do seu 42.º aniverário, envenenado por cianeto. Um inquérito determinou ter-se tratado de suicídio, embora a sua mãe e algumas outras pessoas tenham acreditado ter-se tratado de um acidente. A 10 de Setembro de 2009, após uma campanha na Internet, o primeiro-ministro britânico Gordon Brown apresentou um pedido de desculpas oficial em nome do governo britânico pela «forma chocante como foi tratado». [[Wikipédia](http://en.wikipedia.org/wiki/Alan_Turing)] [](http://en.wikipedia.org/wiki/File:Alan_Turing_photo.jpg "Imagem de Alan Turing, na Wikipédia")

Question 148

**Alonzo Church**

Answer 148

**Alonzo Church** (nascido a 14 de Junho de 1903 e falecido a 11 de Agosto de 1995) foi um matemático e lógico americano com contribuições importantes para a lógica matemática e para os fundamentos da ciência da computação teórica. Entre as suas contribuições mais famosas estão o **cálculo lambda** e a tese de Church–Turing. [[Wikipédia](http://en.wikipedia.org/wiki/Alonzo_Church)] [](http://en.wikipedia.org/wiki/File:Alonzo_Church.jpg "Imagem de Alonzo Church, na Wikipédia")

Question 149

**BYOB**

Answer 149

Antigo nome do Snap!.

Question 150

**Donald Knuth**

Answer 150

Donald Ervin Knuth (nascido a 10 de Janeiro de 1938) é um cientista da computação e Professor Emérito na Universidade de Stanford. É o autor da obra fundamental *A Arte da Programação de Computador*es, em múltiplos volumes. Knuth costuma ser designado como o «pai» da análise de **algoritmos**, pois contribuiu para o desenvolvimento da análise rigorosa da complexidade computacional dos **algoritmos**, tendo sistematizado técnicas formais matemáticas para esse efeito. Durante esse processo popularizou a **notação assimptótica**. Para além de contribuições fundamentais em vários ramos da **ciência da computação**, Knuth criou o sistema de tipografia computacional TeX, a linguagem de definição e sistema de apresentação de fontes tipográticas METAFONT e a família de fontes tipográficas Computer Modern. Como escritor e académico, Knuth criou os sistemas de **programação de computadores** WEB e CWEB, concebidos para encorajar e facilitar a **programação literária**, e concebeu as arquitecturas de conjuntos de instruções MIX e MMIX. [[Wikipédia](http://en.wikipedia.org/wiki/Donald_Knuth)] [](http://en.wikipedia.org/wiki/File:KnuthAtOpenContentAlliance.jpg "Imagem de Donald Knuth, na Wikipédia")

Question 151

**Edsger Dijkstra**

Answer 151

**Edsger Dijkstra** [ler «daicstra»] (nascido a 23 de Maio de 1930 e falecido a 6 de Agosto de 2002) foi um cientista da computação holandês. Em 1972 recebeu o Prémio Turing por contribuições fundamentais para o desenvolvimento das **linguagens de programação**. Pouco antes da sua morte em 2002, recebeu o Prémio Artigo Influente do ACM PODC em **computação distribuída**. Em sua honra, no ano seguinte à sua morte esse prémio anual passou a chamar-se Prémio Dijkstra. [[Wikipédia](http://en.wikipedia.org/wiki/Edsger_Dijkstra)] [](http://en.wikipedia.org/wiki/File:Edsger_Wybe_Dijkstra.jpg "Imagem de Edsger Dijkstra, na Wikipédia")

Question 152

IDE

Answer 152

Ver **ambiente integrado de desenvolvimento**.

Question 153

**papel e lápis** paper and pencil

Answer 153

Bons amigos durante a resolução de problemas. Deixe de olhar esgaseado para ecrã e faça um esquema, um desenho, um diagrama. Verá que pensa melhor. [](http://compsci.ca/blog/super-paper-programming/ "Papel e lápis, no CompSci.ca Blog")

Question 154

**programação aos pares** pair programming

Answer 154

A **programação aos pares** é uma técnica do **desenvolvimento ágil de *software*** na qual dois **programadores** trabalham juntos numa única estação de trabalho. Um dos **programadores**, designado condutor (ou Holmes), escreve o **código** enquanto o outro, designado observador (ou Watson, ou ainda navegador), revê cada linha de **código** à medida que é escrita. Os dois **programadores** alternam os papéis com frequência. Enquanto revisor, o observador também considera a direcção estratégica do trabalho, dando ideias para melhorias e apontando possíveis futuros problemas a considerar. Isto liberta o condutor, permitindo-lhe focar toda a sua atenção nos aspectos tácticos da tarefa corrente, usando o observador como uma rede de segurança e como guia. [[Wikipédia](http://en.wikipedia.org/wiki/Pair_programming)] [](http://en.wikipedia.org/wiki/Agile_software_development "Desenvolvimento ágil de software, na Wikipédia")

Question 155

**programar** to program

Answer 155

Ver **programação**.

Question 156

**quadro branco** whiteboard

Answer 156

Melhor ainda que o **papel e lápis**. Pode escrever sobre o quadro, prender cartões sobre ele usando ímanes, prender ganchos com ventosas para pendurar coisas variadas :-), prender post-it, etc. Pense com o quadro e no quadro, acompanhado pelos seus colegas. [](http://sebastien-arbogast.com/2009/09/24/software-development-and-the-whiteboard-paradigm/ "Quadro branco, no blogue de Sébastien Arbogast")

Question 157

**variável de objecto**² object variable²

Answer 157

O mesmo que **variável de instância**.