Lenguaje C++

6. Diseño evolutivo

ÍNDICE

1. Introducción 192

1.1 El método de trabajo 193

Primero, lo esencial 193

Hacer justo, lo necesario 194

Software cerrado y abierto 194

Definiciones flexibles 195

2. Diseño de un cajero automático simple 197

2.1 Introducción 197

2.2 Extracción sobre una cuenta 197

Tarea inicial: hacer una sola extracción sobre una cuenta. 197

Diagrama de Clases de una extracción sobre una cuenta 200

Código Java de una extracción sobre una cuenta 202

2.3 Primera Ampliación. Hacer varias extracciones sobre una cuenta 205

Diagrama de secuencia de muchas extracciones sobre una cuenta 207

2.4 Segunda Ampliación. Varias extracciones sobre una cuenta de varias posibles 212

2.4 Tercera Ampliación: Control de Acceso 216

Escena de acceso 216

Código Java ACCESO 218

Integración de acceso y extracción 219

Estudio de alternativas de unión 221

2.4.1 Una iteración. Otra forma de unión 224

2.4.2 Otra iteración 225

2.4.3 Otra iteración más 226

Interpretación Arquitectónica del Sistema 230

2.5 Cuarta Ampliación: Ingreso de Dinero 232

Ejercicio 233

Diseño del mecanismo de ingreso 234

Código Java INGRESO 236

Integración de ingreso al sistema 237

Código Java Selector 240

Diagrama de clases del sistema completo 241

2. 6 Recapitulemos 242

1. Introducción

Después de haber hecho un recorrido por los cimientos del modelo orientado a objetos, por sus conceptos y por partes de su código, debemos comenzar a ver cómo se pueden conseguir desarrollo y software evolutivo.

Una forma de desarrollo evolutivo es el llamado desarrollo iterativo e incremental. Iterativo en el sentido amplio de corrección. Es decir, en el sentido de reducir el error, de aproximarse más. Se trata de corregir el rumbo del proyecto al evaluar los resultados con el cliente, de eliminar las equivocaciones detectadas durante las pruebas y de mejorar las cualidades internas del software, por ejemplo su consistencia. Incremental en el sentido de añadir capacidades y funciones al software de acuerdo con el crecimiento de las necesidades. Lo incremental y lo iterativo van juntos, aunque no siempre se presentan los dos.

Hay muchas formas de desarrollo iterativo e incremental, con sus técnicas y métodos respectivos. Probablemente, casi todas son buenas o, al menos, tienen muchos aspectos buenos. Por tanto, lo más importante es crear una actitud evolutiva hacia el diseño y su modo de hacerlo, que se enriquezca después con la diversidad de fuentes disponibles. Este es el objetivo central del capítulo.

Las palabras iterativo e incremental se utilizan en los procesos de aproximaciones sucesivas. Se han tomado de ahí porque tienen una finalidad semejante: resolver problemas con incertidumbre. Tanto el desarrollo de software iterativo e incremental como los procesos de aproximaciones sucesivas buscan un valor desconocido. Pero, en el desarrollo de software ese valor desconocido es, además, inestable; se desplaza con el tiempo. Es como disparar a una diana poco visible que se mueve con una componente de imprevisilidad.

Esa distinción establece una diferencia cualitativa entre el desarrollo evolutivo y los procesos de aproximaciones sucesivas, sobre todo al acentuarse la componente futura de la incertidumbre. Por tanto, son diferentes. No obstante, podemos aprovechar sus similitudes, al menos en primera instancia.

Los sistemas software se pueden considerar como sistemas complejos alejados del equilibrio que se organizan con una estabilidad transitoria, gracias al trabajo de los desarrolladores. En cierto sentido hay una analogía con las denominadas estructuras disipativas, presentes en la naturaleza viva e inanimada. De este parecido se pueden obtener diversas ideas para el diseño software. Una de las más interesantes es la ruptura y restablecimiento de la simetría, como veremos en este capítulo.

Un sistema software con capacidad de evolución deberá tener holguras para adaptarse a la incertidumbre. Si todo está rígidamente definido, difícilmente se podrá amoldar a los cambios. Por tanto, deberá tener holguras en sus definiciones, que son uno de los elementos adversos para la evolución. Aunque necesite definiciones exactas y concretas para funcionar, el sistema debe operar con definiciones flexibles. Es decir, con definiciones parciales, definiciones diferidas e, incluso, con definiciones ausentes, para conseguir libertad de modificación. En este capítulo veremos cómo se pueden utilizar las cualidades del modelo de software orientado a objetos para conseguir definiciones flexibles en el sentido de evolución y de reutilización.

El capítulo tiene como hilo conductor la construcción de dos aplicaciones software sencillas, pero relevantes. En la primera nos concentraremos en ver un método de diseño evolutivo, suponiendo incertidumbre y en la segunda, al tema de la reutilización, técnica común en las ingenierías.

1.1 El método de trabajo

Primero, lo esencial

Como el objetivo primordial de la evolución del software es la supervivencia del software, nos debemos ocupar primero de los aspectos de mayor riesgo del proyecto. Donde el riesgo debe evaluarse por la incertidumbre y las consecuencias de esa incertidumbre.

La secuencia evolutiva debe ser acordada con el cliente después de un estudio de los riesgos del proyecto; estudio que nunca será exhaustivo. Si no hay elementos inciertos en la técnica de desarrollo, se deben desarrollar primero las prioridades más altas del cliente, porque de no cumplirlas, el proyecto fracasa. En general, las prioridades más altas del proyecto se refieren al comportamiento esencial del sistema, a sus operaciones más frecuentes. Las excepciones y los detalles, dependiendo del riesgo, se pueden dejar para después.

Hacer justo, lo necesario

Los procesos evolutivos son costosos porque se enfrentan a la carga adicional de complejidad que representa la incertidumbre. Por tanto, conviene conducirlos justo con lo necesario para ahorrar recursos y, también, para no dilapidar. Es decir, para perder lo menos posible cuando obtenemos resultados negativos. De aquí que, generalmente, se postergue el desarrollo de las excepciones hasta comprobar el rumbo adecuado de la esencia del sistema.

Sin embargo, no debemos confundir la chapucería, ni la negligencia, con el delicado balance de hacer justo lo necesario, expuesto en el párrafo anterior. Construir software escribiendo su código directamente, tiene malas consecuencias sobre la capacidad evolutiva del software. El código está hecho para

...