El libro de referencia para el método de Jackson es el “Principles of program Design”. Supongo que buscando en la red por este título (con Jackson para acotar los resultados) se debería encontrar el libro, no sé si pagando o libre, en PDF o algo así.

En la Wikipedia (española e inglesa) hay una bibliografía muy interesante, siempre en inglés, me temo.

Aunque ahora no esté de moda, sigue siendo la mejor metodología de diseño de programas por lotes, con enoooorme diferencia. Aunque con tanto objeto y tanta clase desmandada, parece que no hay que preocuparse de diseñar los programas. Pero sí. Y si no, no hay más que mirar tantas y tantas aplicaciones con un diseño nefasto que hay por ahí…

Saludos

No estoy exactamente de acuerdo con lo que dices, lo siento.

Una cosa es que el software que se pone en marcha sea de mejor calidad, y otra que el software que se escribe lo sea.

Sobre la primera proposición, es posible que tengas razón, aunque se siguen cometiendo montañas de errores y fallos de aplicaciones en producción que los viejos del lugar vemos como inaceptables. Por ejemplo, un conocido banco por internet estuvo hace unos meses dos días completos sin servicio porque se había caído su sistema y tardaron 48 horas en conseguir que funcionara de nuevo. Eso, en mis buenos tiempos, hubiera sido motivo de despido para media plantilla de informática: es inconcebible que un banco por internet, o sea, basado exclusivamente en la tecnología, puesto que no tiene (casi) oficinas, no pueda operar dos días porque falla su tecnología.

Si “parece” que el software que se pone en producción es de buena calidad es por la reutilización. Ahora se reutiliza muchísimo, y se supone que lo que se reutiliza son piezas de software probadas una y otra vez, y que deben estar bien escritas y funcionar en todo momento y condición… aunque desgraciadamente también hay casos en que se demuestra al cabo de los años que ese “superprobado software” no funciona bien: recientemente se ha descubierto que un cierto software usado para procesar las imágenes de las resonancias magnéticas nucleares no catalogaba bien ciertos casos, es decir, hemos estado años y años diagnosticando mal porque una pieza de software estaba mal escrita…

Ahora bien, amigo Monton1999, no estoy nada, pero nada de acuerdo, en que el software que hoy se “escribe”, o sea, se programa, se crea como nuevos programas, tenga mejor calidad que antes… Los programadores de ahora no tienen la preparación, ni mucho menos la motivación que teníamos los de hace cuarenta años para crear software, algoritmos que funcionen bien siempre y en todo caso. Ya sabes que hoy el rey del concepto informático es el “Mínimo Producto Viable”, o como se diga, es decir, que “parezca” que nuestro producto hace algo, y ya lo iremos arreglando si conseguimos que algún pringao nos lo pague… y casi nunca queda arreglado del todo, claro.

En mis tiempos todo el software que había en las empresas era escrito por nosotros: no había nada que reutilizar. O funcionaba perfectamente o la empresa se iba al garete. Así de simple. Eramos mucho más cuidadosos, probábamos mucho más y, también, teníamos menos presiones para acabar el programa mañana porque si no la cuenta de resultados se resentía: no se subcontrataba casi nada, todo lo hacíamos los profesionales de la empresa.

En fin, formas distintas de ver las cosas, muy interesantes, en cualquier caso…

Saludos

Obviamente es sabido que, desde un punto de vista puramente formal o lógico/matemático, todo algoritmo puede codificarse utilizando únicamente las estructuras más básicas, pero es igualmente evidente que el hecho de que los modernos lenguajes y entornos nos ofrezcan (además de las básicas) estructuras de una riqueza semántica muy superior facilita la creación de código más complejo, mas correcto y más fácil de mantener. Estas estructuras no existían, o aún no eran ampliamente conocidas, cuando se concibió Warnier y, por lo tanto, esa metodología no es adecuada para los lenguajes modernos, del mismo modo que Fortran no es adecuado para aplicaciones de bases de datos…

Sencillamente, no es posible (o, como mínimo, resulta antinatural) expresar relaciones más complejas como herencia, hilo, proceso, prototipo, proxy, … en una metodología como Warnier.

Es muy parecido al caso de los lenguajes de alto nivel en comparación con el ensamblador. Evidentemente todo se puede codificar directamente en ensamblador, pero la mayor riqueza semántica de los lenguajes de alto nivel nos facilita la creación de código más complejo y, a la vez, más mantenible.

Sí, es cierto lo que dices. Nadie se preocupa ya de planificar sus programas. No hay tiempo: los directores de la subcontrata de turno exigen que el software se escriba muuuy deprisa para así cumplir plazos y ganar dinero. Lo que pase después cuando haya que mantener el software… eso ya no importa: será responsabilidad de otra subcontrata.

Pero una cosa sigue siendo cierta desde que Bohm y Jacopini lo demostraron hace centurias: todo algoritmo, cualquiera, se puede resolver en base a las tres estructuras de toda la vida: secuencia, iteración, selección. Sea un módulo batch escrito en Cobol, una clase Java o el núcleo de un sistema operativo.

Por muy sofisticadas que sean las herramientas modernas, por muy atómicos que sean los generadores de código… al final siempre está el “if … then … else” y el “do until” (o while, a elegir). Y no debería olvidársenos nunca. Es la base.

Fuera de ahí, y en un contexto que no sea puramente académico, su utilidad es limitadísima y, de hecho, no conozco ningún caso de uso fuera de ese entorno. A nadie se le ocurre utilizar esas metodologías para diseñar el núcleo de un sistema operativo, por poner un ejemplo. Y no lo hacen porque, sencillamente, te imponen un corsé formal que es totalmente contraproducente para el desarrollo de otro tipo de aplicaciones en otro tipo de lenguajes… Los lenguajes modernos permiten la creación de estructuras mucho más complejas que los lenguajes existentes cuando se desarrolló Warnier y los entornos de desarrollo modernos ofrecen herramientas mucho más potentes y más adecuadas para el diseño, creación y mantenimiento de dichas estructuras.

Los programadores que usaban Assembler debieron sentir una pena similar cuando se inventó PL/I o COBOL o RPG…

Hay que adaptarse a los tiempos, por muy revueltos o de plástico que estos sean. Digo yo.

Saludos.

Cuando hay un proceso en lotes (aunque sea en una transacción online) entonces sí hay que tener en cuenta la estructura del flujo de entrada y el de salida. Y si no, puede que pongas los accesos a las tablas en sitios equivocados, etc. En fin, ahora parece que con el java y los objetos todo está medio hecho, y casi nadie se preocupa de afinar bien los diseños… total, si no va bien, metemos más máquina, más memoria y yastá. Y muchas veces no está. En fin, es claro que la informática ha cambiado…