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