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

Lógica de Programación (parte 2)

«Una vez que se han introducido instrucciones en el ordenador y traducido al lenguaje máquina, un programa se puede arrancar o ejecutar.» p 8.

«La tarea de un programador se puede dividir en seis pasos de programación:

1. Entender el problema.

2. Plantear la lógica.

3. Codificar el programa.

4. Traducir el programa a lenguaje máquina.

5. Probar el programa.

6. Poner el programa en producción.» p. 10.

Entender el problema es importante no sólo para cuestiones de programación sino para cualquier tipo de cuestión. Entender el problema es más de la mitad del proceso para su resolución. Los programadores cobran por hacer programas que ayudan a otros a realizar ciertas tareas obteniendo ciertos resultados pero no es raro encontrarse con que el cliente del programador no sabe en sí qué quiere obtener. El programador es igual en cierto sentido que otros diseñadores, le va dando consejos al cliente así como va también tratando de entenderlo. Nosotros como futuros programadores tenemos que ser muy cuidadosos en este punto porque el cliente es el que paga. Hay qué hacer lo que el cliente pida ni más ni menos.

En lo que toca a plantear la lógica del programa es cuando se ve quién es el verdadero programador. Aquí hay que plantear los pasos que se van a seguir para la resolución del problema como el orden de ellos. Es lo que muchos llaman como «desarrollar el algoritmo» que es una secuencia de pasos necesaria para resolver un problema. Hay dos formas típicas de plantear la lógica del problema: con pseudocódigo y con diagramas de flujo.

Aquí el programador no se preocupa por la sintaxis, no se preocupa por el lenguaje de programación, sólo se preocupa por plantear la secuencia de sucesos que le llevarán a los datos de salida deseados dado unos determinados datos de entrada.

Codificar el programa se refiere a escribirlo en un lenguaje de programación. Aquí si que seremos cuidadosos en la sintaxis.

Para traducir el programa a lenguaje máquina se utiliza un traductor (como en el caso de los lenguajes JAVA o Basic, «sólo gracias a que alguien ha escrito un programa traductor (un compilador o intérprete) que cambia el lenguaje de alto nivel (similar al inglés) con el que el programador escribe a lenguaje de bajo nivel que el ordenador entiende». Un compilador no razona, vamos que no siempre sabe qué le queremos decir ni cuál sería la corrección adecuada en caso de tener un error en la sintaxis, pero sí sabe cuando esta última tiene algo erróneo.

Por último hay que probar el programa. Puede que nuestro programa esté libre de todo error de sintaxis, pero como ya dijimos, puede que aún así tenga errores lógicos y entonces nos dará algo a la salida diferente de lo que queríamos. Hay que probar el programa con muchos datos y hay que saber elegir qué datos utilizaremos para probar.

Y ya una vez probado el programa, el cliente lo podrá usar. Este proceso puede ser de un instante o tardar meses o años, cuando hay que sustituir a programas viejos en grandes organizaciones y hay que hacer todo tipo de adaptaciones, incluida la incorporación de nuevo hardware.