Sesion 14

Cierre teorico de Unidad 2: analisis iterativo y simulacro

Unidad 2 · Ciclos, contadores/acumuladores y estructuras de almacenamiento

Navegacion: ← → · Home / End · F pantalla completa · Tactil: desliza

Cerrar Unidad 2 sin vacios conceptuales

Consolidar los cuatro saberes nucleares de la unidad en problemas de analisis y correccion de codigo.
Ejercitar prediccion de salida en for, while y do-while.
Reforzar seleccion de estructura de almacenamiento segun el problema (array vs List<T>).
Aplicar una actividad evaluativa en clase (Ejercicio B) y separar la correccion extensa de errores (Ejercicio A) en actividad aparte.

Saber de Unidad 2	Sesiones previas	Refuerzo final en Sesion 14
Ciclos y su utilidad	9, 10, 12, 13	Prediccion de salida y seleccion del ciclo correcto por caso.
Contadores y acumuladores	10, 12, 13	Deteccion de inicializacion incorrecta y reinicio entre iteraciones.
Operaciones con estructuras de datos	11, 12, 13	Recorridos, busquedas, max/min y promedios con condiciones seguras.
Estructuras para almacenamiento	11, 12	Justificacion tecnica: cuando usar array y cuando usar List<T>.

Conclusion: no hay saberes faltantes; esta sesion funciona como integracion y verificacion final de dominio.

for

Cuando conoces inicio, fin y paso.
Ideal para recorrer arrays y listas por indice.
Reduce errores de control cuando el limite es claro.

for (int i = 0; i < datos.Count; i++) { suma += datos[i]; }

while / do-while

while: valida antes de entrar.
do-while: ejecuta al menos una vez.
Util para menus de aplicacion y validaciones de reintento.

string op; do { Console.Write("Menu: "); op = Console.ReadLine(); } while (op != "0");

Errores frecuentes

Inicializar acumulador dentro del ciclo (se pierde el historico).
No reiniciar variables entre ejecuciones de menu.
Incrementar contador en rama equivocada.

// Error: suma se reinicia en cada iteracion for (int i = 0; i < n; i++) { int suma = 0; suma += datos[i]; }

Patron correcto

int contador = 0; double suma = 0; for (int i = 0; i < datos.Count; i++) { if (datos[i] >= 0) { contador++; suma += datos[i]; } }

Regla: inicializar fuera del ciclo, actualizar dentro del ciclo, usar al final.

Criterio	Array	List<T>
Tamano	Fijo al crear	Dinamico (crece/disminuye)
Uso recomendado	Cuando N es conocido y estable	Cuando N depende de entradas de usuario
Operacion tipica	Recorrido por indice	Add, Remove, Count y recorrido
Riesgo comun	Desborde por limite mal calculado	Asumir elementos sin validar Count

Decision para la prueba: si el enunciado habla de cantidad variable de registros, la opcion natural es List<T>.

Operaciones obligatorias

Registrar datos.
Recorrer y acumular.
Buscar maximo y minimo.
Calcular promedio con validacion de vacio.

Esqueleto robusto

if (datos.Count == 0) { Console.WriteLine("Sin datos"); } else { double suma = 0; double max = datos[0]; double min = datos[0]; for (int i = 0; i < datos.Count; i++) { suma += datos[i]; if (datos[i] > max) max = datos[i]; if (datos[i] < min) min = datos[i]; } }

int suma = 0; for (int i = 1; i <= 4; i++) { suma += i; } Console.WriteLine(suma); int c = 0; while (c < 3) { Console.Write(c + " "); c++; }

Respuesta esperada: primera linea = 10. Segunda salida = 0 1 2. Explica por que el while no imprime 3.

Fragmento con fallas

List<double> notas = new List<double>(); string op; do { Console.Write("Nota: "); double n = double.Parse(Console.ReadLine()); notas.Add(n); Console.Write("Continuar? (s/n): "); op = Console.ReadLine(); } while (op == "s"); double prom = 0; for (int i = 0; i <= notas.Count; i++) prom += notas[i]; Console.WriteLine(prom / notas.Count);

Hallazgos esperados

Parse sin validacion.
Condicion i <= notas.Count provoca desborde.
Falta guardia cuando la lista esta vacia.
No hay validacion de rango de nota.

Situacion

Debes registrar ventas del dia. No conoces cuantas ventas habra. Se pide total, promedio y mayor venta.

Pregunta: ¿array o List<double>?

Justificacion esperada

Como N es desconocido, conviene List<double>.
Permite Add por cada venta sin redimension manual.
Para pruebas con N fijo conocido, array tambien es valido.

Este criterio evalua el saber de utilidad de estructuras, no solo sintaxis.

Condiciones

Duracion: 35 minutos.
Formato: 2 ejercicios de codigo + 1 pregunta de justificacion tecnica.
Trabajo individual, con VS Code y depurador habilitado.
Entrega: commit local + evidencia de ejecucion en clase.

Esta actividad es evaluativa y aporta evidencia directa del dominio de Unidad 2.

Actividad independiente de deteccion y correccion

El Ejercicio A se trabaja en una pagina separada con:

Un codigo grande con minimo 12 errores (sintaxis, ejecucion y logica).
Registro de cantidad de errores encontrados y justificacion de cada correccion.

Abre la actividad en: sesiones/ejercicioA_unidad2.html

Negocio: minimercado de barrio con menu iterativo

Contexto de negocio: Eres el desarrollador del sistema de caja de un minimercado. Debes construir un menu para registrar ventas del dia y generar reportes. Requisitos: 1) Menu do-while con opciones: 1. Registrar venta (nombre producto + cantidad + valor unitario) 2. Mostrar reporte del dia - total vendido - promedio por venta - venta de mayor valor - cantidad de ventas registradas 0. Salir 2) Almacenamiento en List<double> para valores de venta. 3) Validar entradas numericas con TryParse (cantidad y valor unitario). 4) Si no hay ventas, el reporte debe mostrar advertencia y no fallar. 5) Incluir al menos un acumulador y un contador bien inicializados. 6) Usar nombres de variables claros y mensajes orientados al negocio.

Criterio de logro: funcionalidad completa del menu de negocio + ausencia de excepciones por entrada invalida o lista vacia.

Criterio	Si	No
Selecciono correctamente entre for, while y do-while segun el enunciado.
Uso contadores y acumuladores sin errores de inicializacion o reinicio.
Recorro arrays o listas sin off-by-one.
Implemento validaciones para entradas invalidas y coleccion vacia.
Justifico tecnicamente cuando usar array y cuando usar List<T>.

Resultado de cobertura

Ciclos: cubiertos y verificados en analisis de salida.
Contadores/acumuladores: reforzados con correccion de errores.
Operaciones con estructuras: practicadas en actividad evaluativa de negocio.
Estructuras de almacenamiento: criterio de eleccion explicitado.

Decisiones para la semana adicional

Mantener practica de depuracion con casos frontera.
Enfocar evaluacion en correctitud + robustez.
No introducir temas nuevos; solo evidenciar dominio.

Lo que sigue despues de evaluar Unidad 2

El codigo iterativo construido se convertira en materia prima de refactorizacion modular.
En Unidad 3 se separara el codigo en funciones con responsabilidad unica.
La calidad lograda hoy en ciclos, validacion y estructuras facilitara ese salto.

Sesion 14 cierra el bloque teorico de Unidad 2. Las tareas y evaluaciones se gestionan en paralelo/semana adicional segun planeacion.