Ir al contenido

UD01 · Ejercicios

Las soluciones están plegadas. Intenta el ejercicio antes de abrirlas: leer una solución y entenderla no es lo mismo que ser capaz de escribirla.

Responde con tus palabras, sin copiar de los apuntes.

  1. ¿Cuál es la diferencia entre un algoritmo y un programa?
  2. Un algoritmo debe ser preciso, definido y finito. Pon un ejemplo de instrucción que incumpla cada una de las tres.
  3. ¿Qué necesita tener instalado un ordenador para ejecutar un programa Java, y por qué?
  4. ¿Por qué se dice que Java es compilado e interpretado a la vez?
  5. Ordena estas fases y explica qué pasa si te saltas la segunda: codificación, análisis, pruebas, diseño.
Ver solución
  1. El algoritmo es la idea: los pasos para resolver el problema, independientes del lenguaje y de la máquina. El programa es esa idea escrita en un lenguaje de programación concreto para que un ordenador la ejecute. Un mismo algoritmo puede dar lugar a programas en Java, Python o Scratch.

  2. Ejemplos posibles:

    • No preciso: «añade un poco de sal» — ¿cuánta?
    • No definido: «elige un número cualquiera y súmalo» — dos ejecuciones darían resultados distintos.
    • No finito: «repite mientras 1 sea menor que 2» — nunca termina.
  3. La máquina virtual de Java (JVM), que viene con el JDK. El compilador no genera código máquina del procesador, sino bytecode; hace falta una JVM que traduzca ese bytecode al lenguaje máquina concreto de ese ordenador.

  4. Porque el proceso tiene dos etapas: el código fuente .java se compila a bytecode .class, y ese bytecode lo va interpretando (y compilando con el JIT) la JVM durante la ejecución.

  5. Análisis → diseño → codificación → pruebas. Saltarte el diseño significa ponerte a escribir código sin tener claro el algoritmo: acabas reescribiendo el programa varias veces, y encima con la sensación de estar avanzando mientras lo haces.

Para cada enunciado indica entradas, salidas y proceso. Todavía no escribas el algoritmo: solo el análisis.

  1. Un programa que diga si un número es múltiplo de 3. Solo se aceptan números positivos del 1 al 1000.
  2. Un programa que calcule la media de tres notas. Solo se aceptan valores del 0 al 10.
  3. Un conversor de euros a dólares, usando un cambio fijo de 1 € = 1,08 $.
Ver solución

1. Múltiplo de 3

  • Entradas: un número entero.
  • Salidas: un mensaje indicando si es múltiplo de 3, o un aviso si el número no es válido.
  • Proceso: comprobar que está entre 1 y 1000; calcular el resto de dividirlo entre 3; si el resto es 0, es múltiplo.

2. Media de tres notas

  • Entradas: tres números reales (las notas).
  • Salidas: la media, o un aviso si alguna nota está fuera del rango.
  • Proceso: validar que las tres están entre 0 y 10; sumarlas y dividir entre 3.

3. Conversor de euros a dólares

  • Entradas: una cantidad en euros (número real).
  • Salidas: la cantidad equivalente en dólares.
  • Proceso: multiplicar la cantidad por 1,08.

Fíjate en que en dos de los tres casos aparece validar la entrada. Es la parte que más se olvida y la que más fallos provoca: un programa tiene que sobrevivir a que le metan cualquier cosa.

Escribe el pseudocódigo de estos dos programas.

  1. Nómina. Se piden las horas base trabajadas y las horas extra. Las horas base se pagan a 10 € si son 150 o menos; a partir de 151 horas se pagan a 11 €. Las horas extra se pagan siempre a 13 €. El programa muestra el salario total.

  2. Figuras. El usuario escribe cuadrado, rectángulo o círculo. Según lo que escriba, se le piden las medidas necesarias y se calculan área y perímetro.

Ver solución

1. Nómina

INICIO
Leer horasBase, horasExtra
Si horasBase <= 150 entonces
pagoBase = horasBase * 10
Si no
pagoBase = horasBase * 11
Fin_si
pagoExtra = horasExtra * 13
salario = pagoBase + pagoExtra
Escribir "Salario total: ", salario
FIN

Ojo al enunciado: cuando se superan las 150 horas, todas las horas base se pagan a 11 €, no solo las que pasan de 150. Es justo el tipo de ambigüedad que hay que aclarar preguntando en la fase de análisis, no decidir por tu cuenta.

2. Figuras

INICIO
Leer figura
Según figura sea
"cuadrado":
Leer lado
area = lado * lado
perimetro = 4 * lado
"rectángulo":
Leer base, altura
area = base * altura
perimetro = 2 * (base + altura)
"círculo":
Leer radio
area = 3.1416 * radio * radio
perimetro = 2 * 3.1416 * radio
Si no:
Escribir "Figura no reconocida"
FIN
Fin_según
Escribir "Área: ", area
Escribir "Perímetro: ", perimetro
FIN

Di qué hace cada fragmento. En todos ellos hay algo que no funciona: encuéntralo.

Fragmento A

VARIABLES: Cadena: nombre; Real: precio, descuento, pagoFinal; Entero: tipo
INICIO
Leer nombre, tipo, precio
Según tipo sea
1: descuento = precio * 0.3
pagoFinal = precio - descuento
2: descuento = precio * 0.2
pagoFinal = precio - descuento
3: descuento = precio * 0.1
pagoFinal = precio - descuento
Si no:
Escribir "Tipo de cliente no reconocido"
descuento = 0
Fin_según
Escribir "Total a pagar: ", pagoFinal
FIN

Fragmento B

VARIABLES: Entero: i, num
INICIO
Si (num >= 1 y num <= 10) entonces
Para i = 1 hasta 10 hacer
num = num * i
Escribir num, " * ", i, " = ", num * i
Fin_para
Fin_si
FIN

Fragmento C

VARIABLES: Real: a, b, c
INICIO
Leer a, b, c
Si (c < a y a > b) entonces
Escribir "El número mayor es: ", a
Si no si (a < b y b > c) entonces
Escribir "El número mayor es: ", b
Si no si (a < c y c > b) entonces
Escribir "El número mayor es: ", c
Si no
Escribir "No se puede determinar cuál es el número mayor"
Fin_si
FIN
Ver solución

Fragmento A — descuento por tipo de cliente. Aplica un 30 %, 20 % o 10 % de descuento según el tipo de cliente y muestra el total.

El fallo: si el tipo no es 1, 2 ni 3, se avisa y se pone descuento = 0, pero nunca se calcula pagoFinal. La última línea intenta mostrar una variable que no tiene valor. Habría que asignar pagoFinal = precio en ese caso.

Fragmento B — pretende ser la tabla de multiplicar del número num.

Tiene dos fallos:

  • num nunca se lee. Se usa una variable que no tiene valor.
  • num = num * i machaca el número en cada vuelta, así que a partir de la segunda iteración ya no multiplica el número original. Y la línea siguiente escribe num * i con num ya modificado, con lo que ni el enunciado ni el resultado que se muestran son correctos.

Corregido:

INICIO
Leer num
Si (num >= 1 y num <= 10) entonces
Para i = 1 hasta 10 hacer
Escribir num, " * ", i, " = ", num * i
Fin_para
Fin_si
FIN

Fragmento C — el mayor de tres números. Funciona mientras los tres sean distintos, pero falla en cuanto hay empates: con a = 5, b = 5 y c = 2, ninguna condición se cumple y responde que no puede determinarlo, cuando el mayor es 5.

Se arregla usando >= en lugar de > en las comparaciones, o con una solución mucho más simple: guardar el primero como mayor provisional e ir comparándolo con los otros dos.

Este es el diagrama de flujo de la teoría. Hazle una traza: recórrelo con los valores 4, 7, 0 y 150, anotando por dónde sale en cada caso.

Diagrama de flujo que comprueba si un número entre 1 y 100 es par o impar

  1. ¿Qué responde el diagrama para cada uno de esos cuatro valores?
  2. Uno de los resultados no es el que pretendía el diseño. ¿Qué condición está mal escrita y cómo debería ser?
Ver solución
  1. Traza:

    • 4 → no es 0, pasa el control de rango, resto de 4/2 = 0 → «Número Par». Correcto.
    • 7 → no es 0, pasa el control de rango, resto de 7/2 = 1 → «Número impar». Correcto.
    • 0 → la primera decisión lo caza → «Valor incorrecto». Correcto.
    • 150se cuela, y acaba respondiendo «Número Par» cuando debería avisar de que está fuera de rango.
  2. La condición del segundo rombo dice Número < 0 o Número > 0, y eso es cierto para cualquier número que no sea 0 — precisamente el caso que ya se ha filtrado en el rombo anterior. Según el mensaje que hay a su derecha, el rango válido es 1-100, así que debería ser:

    Número < 1 o Número > 100

    Es un error de una sola tecla, invisible leyendo por encima y evidente en cuanto haces la traza con un dato fuera de rango. Para eso sirve la traza.

Dibuja el diagrama de flujo de estos procesos. No hace falta pensar en código: piensa en los pasos, las decisiones y por dónde continúa cada camino.

  1. Registro de un usuario en una web.
  2. Inicio de sesión de un usuario en una web.
  3. Añadir un producto al carrito de una tienda online.
  4. Pagar los productos que hay en el carrito.
  5. Dar el cambio con el menor número de monedas posible en una máquina expendedora.
  6. Emparejar a un jugador con otro de nivel similar al empezar una partida.
  7. Reservar una mesa en un restaurante para una fecha y una hora concretas.
  8. Reservar plaza en una clase colectiva de un gimnasio.

Puedes dibujarlos a mano, con draw.io o con cualquier herramienta parecida.

Ver orientación

No hay una única solución correcta, pero un diagrama bien planteado contempla los caminos que salen mal, que son justo los que se olvidan:

  • Registro: ¿el correo ya existe? ¿la contraseña cumple los requisitos? ¿coinciden las dos contraseñas?
  • Inicio de sesión: ¿existe el usuario? ¿la contraseña es correcta? ¿cuántos intentos fallidos permites antes de bloquear la cuenta?
  • Carrito: ¿hay stock? ¿el producto ya estaba en el carrito (entonces sumas cantidad, no lo añades otra vez)?
  • Pago: ¿el carrito está vacío? ¿el pago ha sido rechazado? ¿sigue habiendo stock en el momento de pagar?
  • Cambio de la máquina: se recorren las monedas de mayor a menor valor, repartiendo mientras quede cambio por dar. Es un bucle, y esconde una decisión importante: ¿qué haces si no te quedan monedas suficientes?
  • Emparejamiento: ¿y si no hay ningún jugador de nivel parecido? ¿esperas, amplías el margen o juegas contra la máquina?
  • Reservas: ¿hay hueco a esa hora? ¿está cerrado ese día? ¿la fecha ya ha pasado?

Si tu diagrama solo tiene el camino feliz, está incompleto.

  1. Programa en Scratch los tres problemas del ejercicio 2 (múltiplo de 3, media de tres notas y conversor de euros). Necesitarás preguntar y esperar, variables y condicionales.
  2. Programa también la nómina del ejercicio 3.
  3. Haz un juego tipo Flappy Bird. Hay tutoriales de sobra en YouTube: sigue uno y luego cámbiale algo — la dificultad, los gráficos, un marcador de récord.
Pistas para el 1
  • Para leer un dato: preguntar [¿Qué número?] y esperar y, justo después, dar a numero el valor (respuesta). El bloque respuesta se sobrescribe en cuanto vuelves a preguntar, así que guárdalo en una variable enseguida.
  • El resto de una división está en Operadores: () módulo ().
  • Para validar el rango: si <(numero < 1) o (numero > 1000)> entonces … si no ….
  • Para la media, cuidado con el orden de las operaciones: tienes que anidar los bloques de suma dentro del de división, no ponerlos en fila.

Sobre el juego que construimos en clase (lo tienes paso a paso en la presentación de la unidad), añade lo siguiente. Están ordenados de menos a más dificultad.

  1. Cambia el número de enemigos que hay que derrotar para que aparezca el enemigo final.
  2. Cambia las vidas del enemigo final.
  3. Programa la explosión de nuestra nave cuando la toca el enemigo final.
  4. Haz que suene una música de fondo durante la partida.
  5. Crea una pantalla de Game Over a tu gusto: puedes cambiar el escenario, sacar otro personaje, poner letras…
  6. Crea una pantalla de Victoria.
  7. Haz aparecer un tesoro cuando te quedes con 0 torpedos; si la nave lo toca, recupera los 3 torpedos.
  8. Haz que los torpedos quiten tres vidas al enemigo final, en lugar de una.
  9. Añade un segundo nivel con otro escenario y los mismos objetos, más difícil. Al terminar el primer nivel debe aparecer un mensaje de nivel completado y empezar el segundo.
Pistas
  • Los ejercicios 1 y 2 son de una sola tecla: busca dónde se le da valor a las variables enemigos y vidasmalo al empezar la partida. Que sean tan fáciles de cambiar es la gracia de haber usado variables en lugar de escribir los números sueltos por ahí.
  • Para el 3, fíjate en cómo la nave gestiona ya el mensaje de fin de partida: necesitas exactamente lo mismo, pero disparado por otro objeto.
  • Para el 5 y el 6, lo más limpio es un objeto nuevo que esté escondido durante la partida y aparezca al recibir el mensaje correspondiente.
  • Para el 7 necesitas que el tesoro esté vigilando el valor de la variable de torpedos: un esperar hasta que (torpedos = 0) te lo resuelve.
  • El 9 es el más largo: piensa antes qué tiene que reiniciarse al cambiar de nivel (posiciones, marcadores, variables) y qué debe conservarse. Diséñalo en papel antes de tocar un bloque.

© 2026 Carlos Barroso · Contenido bajo CC BY-NC-SA 4.0