Ejercicios propuestos de la Unidad 1

En la unidad 1 del libro de Leobardo López Román viene al final una lista de ejercicios propuestos para ir calentando en esto de los algoritmos. Bueno, voy a tratar de dar mis respuestas a los ejercicios.

A. Elaborar un algoritmo para hacer palomitas de maíz en una cacerola puesta al fuego, usando sal y maíz.

1. Abrir la bolsa de maíz.

2. Vaciar la bolsa en la cacerola que está al fuego.

3. Agregar sal a la cacerola.

4. Tapar la cacerola.

5. Esperar hasta que los granos de maíz hayan reventado.

6. Apagar el fuego.

7. Esperar a que se enfríe la cacerola.

8. Fin

Este algoritmo parece estar incompleto o no, pero sucede que tampoco nos da muchos datos y suponemos muchas cosas. Con la práctica supongo que haré unos más detallados pero al parecer no es objetivo del ejercicio que detalle tan a fondo.

B. Elaborar un algoritmo que permita cambiar un vidrio roto de una ventana.

Suponemos que ya tenemos el vidrio de repuesto, el pegamento y que no hay que subir a ningún lado.

1. Despegamos el vidrio roto.

2. Quitamos el vidrio roto.

3. Tomamos el vidrio de repuesto.

4. Colocamos el vidrio de repuesto.

5. Pegamos el vidrio de repuesto.

6. Fin

C. Elaborar un algoritmo para cambiar un neumático pinchado.

1. Orillarse.

2. Detener el auto.

3. Poner el freno de mano y encender las señales de peligro.

4. Apagar el auto.

3. Bajar del auto.

4. Cerrar la puerta.

5. Abrir la cajuela.

6. Sacar la llave de cruz.

7. Sacar un plástico o cartón

8. Sacar la llanta de refacción.

9. Sacar el gato hidráulico.

10. Poner el cartón o plástico cerca de la llanta ponchada para tener área limpia de trabajo.

11.  Tomar la llave de cruz.

12.  Con la llave de cruz dar dos vueltas a cada birlo en contra de las manecillas del reloj para aflojarlos.

13. Dejar la llave de cruz

14. Tomar el gato.

15. colocar el gato en detrás de la llanta delantera o enfrente de la llanta trasera

16. Gire la manija del gato en el sentido de las manecillas del reloj, hasta que la llanta ponchada esté 5 ó 6 centimetros por encima del suelo.

17. Tome de nuevo la llave de cruz.

18. Quite un birlo completamente

19. Póngalo en un lugar seguro.

20 Haga lo mismo con el resto de los birlos.

21. Deje la llave de cruz.

22. Sostenga la llanta ponchada con firmeza.

23. Jale derecho hacia afuera.

24. Ponga la llanta ponchada debajo de la carrocería o suspensión del automóvil, por si el gato se desliza todavía será soportado.

25.Tome la llanta de refacción y colóquela en el tambor.

26. Tome un birlo y colóquelo donde le corresponde.

27. Apriételo manualmente.

28. Haga lo mismo con el resto de los birlos.

29. Gire el gato de manera opuesta hasta que el auto baje al suelo.

30. Cuando el peso ya no esté en el gato, remuévalo de abajo del auto.

31. Ponga a un lado el gato.

32. Tome la llave de cruz.

33. Apriete completamente un birlo.

34. Repita la operación con el resto de los birlos.

35. Saque la llanta ponchada que está debajo del auto.

36. Guarde la llanta ponchada en la cajuela.

37. Guarde el gato en la cajuela.

37. Guarde la llave de cruz en la cajuela.

38. Guarde el plástico o cartón en la cajuela

39. Cierra la cajuela.

40. Fin

D. Elaborar un algoritmo para hacer una llamada telefónica. Supongo que ya estoy parado en frente de un teléfono público y las monedas las tengo en la mano derecha.

1. Descolgar auricular con mano izquierda

2. Llevar el auricular a la oreja izquierda.

3. Esperar a escuchar el tono de marcado.

4. Con la mano derecha introducir las monedas en la ranura del teléfono.

5. Con la mano derecha marcar el número

6. Esperar a que conteste es destinatario.

7. Dar el mensaje.

8. Colgar con mano izquierda el auricular en el lugar en donde se descolgó.

9. Fin.

E. Definir «su» robot, es decir, lo que sabe hacer tomando como referencia lo que usted hace, y elaborar un algoritmo que lo lleve desde que se despierta por la mañana hasta que llega a la escuela, trabajo o algún otro lugar.

Supongo que el robot sabe identificar rutas visualmente y además que en el cuarto de baño hay ropa para cambiarse.

El robot sabe.

a. Levantarse de la cama.

b. caminar.

c. detenerse.

d. ponerse sandalias.

e. quitarse sandalias.

f. Abrir puerta y entrar.

g. desvestirse.

h. vestirse y guardar ropa sucia.

i. abrir el refrigerador.

j. sacar alimentos del refrigerador.

h. preparar desayuno.

i. sentarse.

j. comer.

l. bajar escaleras.

m. cerrar puerta.

n. bañarse.

ñ. secarse.

o. cepillarse los dientes.

p. bajar escaleras.

q. cruzar la calle.

r. pagar importe de pasaje.

s. subir al transporte.

t. verificar si hay lugar para sentarse en transporte.

u. levantarse de asiento o silla.

v. bajar de transporte.

w. lavarse los dientes.

x. peinarse.

y. rasurarse.

z. aplicar complementos de aseo (desodorante, loción, etc.).

z1. Tomar cartera y celular.

z2. Esperar el transporte.

Algoritmo.

Para ahorrar tiempo lo haré con claves:

1. a; 2. d; 3. b hasta la puerta; 4; c; 4.1. 4.2. m; 5. b hasta la puerta del baño; 6. c frente a la puerta del baño; 6.1. f; 7. b hacia el interior del baño; 8. c; 9. e; 10. g; 11. d; 12. b hasta el área de la regadera; 13. n; 14. ñ; 15.h; 16. x, y; 17. b hasta la puerta del baño; 18. c; 19. f; 20. b hasta el refrigerador que está en el comedor; 21. c; 22. i; 23. j; 24. h; 25. i en una silla frente a la mesa del comedor; 26. j; 27. u al terminar de comer; 28. b hasta el lugar del aseo personal; 29. c. 30.  o; 31. z. 32. b hasta la sala; 33. c; 34. z1; 35. b hasta la puerta principal. 36. c; 37. f; 38. m; 39. l hasta llegar a la salida del inmueble; 40. b hasta la parada del bus; 41. c; 42. z2; 43. s; 44. r; 45. t; 46. En caso de encontrar lugar b hasta el asiento vacío; 47. en caso de 46 c sino b hasta la puerta de descenso, c  y esperar al lugar destino; 47. En caso de 46 i en asiento vació hasta llegar al destino; 48. En caso de 47 al llegar al lugar destino u, b hasta la puerta de descenso y v; 49. En caso e no 47 v en el lugar de destino; 50. b hasta puerta del trabajo; 51. c; 52. f; 53. Fin

Bueno, este es el algoritmo, la verdad es que así sin estructuras de camino alternativo, secuencia, etcétera es muy complicado. Por supuesto es erróneo en varios puntos pero como ejercicio me fue interesante. Pienso que es muy importante hacer la lista de requerimientos muy bien porque si no van a hacer como yo, ir metiendo puntos extra aunque supongo que a la hora de codificar es común pero más si no se planea ya que puede ser que se eche a perder el esfuerzo. Bueno, sigo aún en la unidad dos. Suerte.

POO parte 1

En el programa de la ESAD de Ingeniería en Desarrollo de Software se le da énfasis a la programación orientada a objetos (POO) y no a la programación estructurada. El primer lenguaje de programación que se enseña es el C++. Pues bien, los dos libros que comenté anteriormente (y seguiré comentando) están orientados a la programación estructurada, pero adquirí uno que en esencia también trata sobre la lógica del desarrollo de software pero enfocada a la POO. Me ha gustado el libro, tiene un enfoque distinto a los otros dos y al menos a mi parecer tiene mucho mejor organización y su redacción está muy acabada. El libro a la vez que enseña la POO a nivel prelenguaje de programación, hace un simulacro acerca de la vida como ingenieros en software, es decir, en él están las áreas en las que habitualmente un ingeniero se desenvolverá desde su incorporación a un equipo hasta su ascenso a líder de proyecto. Al menos por lo que toca a la introducción (y coprobaré si es verdad) en el libro se tocarán problemas reales y completos del exigente mundo del desarrollo de productos de software; concretamente se habla de un proyecto de un videojuego. Les paso los datos del libro:

INGENIERÍA DE SOFTWARE. Una perspectiva orientada a objetos. La editorial es ALFAOMEGA y el escritor es Eric J. Braude quién imparte cátedra en la Boston University.

Vamos a poner unas citas como lo hemos hecho con otros libros.

• «Este libro no es sólo acerca de ingeniería de software, también se refiere a cómo hacer ingeniería de software».

El autor dice que esto novedoso porque no se había hecho algo así en el pasado pues no había un enfoque técnico ampliamente aceptado. Esta podría ser la razón del por qué los libros que aparentemente tratan de lo mismo son a la vez tan distintos. Algo así no ocurre por ejemplo en Derecho o en Economía porque sus campos de conocimiento están ya muy desarrollados y tienen corrientes bien definidas. Sin embargo para la Ingeniería de Software parece que este proceso no está todavía acabado, sobre todo en lo concerniente a la POO.

• «Durante la década de 1990, la comunidad de análisis y diseño orientado a objetos dio forma a un enfoque para el diseño de aplicaciones junto con una notación correspondiente: el lenguaje de modelo unificado.»

Quiere decir esto que en campo es relativamente joven pero el autor se siente en la confianza de plantear un modelo de ingeniería de software, una columna vertebral de ella.

• «Cualquier libro que muestre cómo hacer ingeniería de software debe incluir un caso de estudio. Por otro lado como la ingeniería de software maneja un alto grado de complejidad, un libro de texto para esta disciplina necesita un caso de estudio sustancial y no uno sencillo. Por último, el caso de estudio debe tener el interés suficiente para los estudiantes de manera que puedan visualizar su construcción, sólo por diversión. Por estas razones, todo el libro muestra cómo se aplican los principios de ingeniería de software a la construcción de un videojuego de personajes.»

• «Un equipo de ingenieros de software y no un sólo individuo construye el producto de software típico»

Lo que ya mencionaba en otra entrada, para casi todo se necesita un equipo. Las tareas son tan altamente especializadas y complejas en muchos campos del saber que se necesitan desde un par de hombres hasta cientos o tal vez miles de hombres para llevar a cabo un proyecto.

El libro también tiene sus pasos típicos para el desarrollo de software lo mismo que los otros dos, como es obvio y viene esbozados en la introducción:

1. Análisis de requerimientos (qué debe producirse).

2. Diseño de productos y cómo se expresan los diseños.

3. Programación en el contexto de la ingeniería de software.

4. Proceso de pruebas.

5. Actividades requeridas una vez que se libera el producto.

Aunque esbozadas son claras las etapas y parecidas como es lógico a los otros dos libros. Ya más adelante comentaré las particularidades de este.

En la misma introducción dice algo muy importante. La secuencia lógica de producir aplicaciones en la práctica es análisis de requerimientos/diseño/programación/pruebas. Sin embargo es típico que en la práctica esta secuencia lógica se repita casi siempre, al menos una vez.

El autor plantea formas de cómo el libro debe ser estudiado y me gustó particularmente la que el autor denomina forma de escalera. Esta forma hace alusión a la típica trayectoria de la carrera de un ingeniero de software (lo que decía al principio). Esta trayectoria sería la siguiente: programador-arquitecto-líder de proyecto; el autor nos dice qué capítulos debemos seguir para seguir la trayectoria.

Seguiremos en otra entrada.

Bye