La complejidad en el software.

1.3 La POO y la Complejidad del Software
De manera general, podemos definir a la complejidad como la dificultad que
tenemos los humanos para ordenar el conocimiento.
Así, un tema nos parecerá más complejo en cuanto sea más difícil entenderlo y
explicarlo en un contexto determinado.
La complejidad en el software.
En un sistema, la complejidad es directamente proporcional al número de
elementos involucrados y a la complejidad de cada elemento.
La mayoría de las aplicaciones que son especificadas, desarrolladas, mantenidas
y utilizadas por una sola persona no son complejas.
Por otro lado, las aplicaciones que forman parte del software de dimensión
industrial exhiben un conjunto muy rico de comportamientos, y son propensas a
tener un ciclo de vida muy largo.
Estas aplicaciones son complejas y no pueden ser desarrolladas por una sola
persona. Su mantenimiento y su utilización también involucran a varios individuos.
La complejidad es parte esencial de los sistemas de software de gran tamaño. Se
puede manejar, pero no se puede eliminar.
Según Grady Booch, la complejidad de los sistemas de software se deriva de
cuatro elementos:
1.
2.
3.
4.
la complejidad del dominio del problema,
la dificultad de gestionar el proceso de desarrollo,
la flexibilidad que se puede alcanzar a través del software y
los problemas de caracterizar el comportamiento de sistemas discretos.
1.- La complejidad del dominio del problema.
Los problemas que se intentan resolver son inherentemente complejos, con una
gran cantidad de requisitos que compiten entre sí.
2.- La dificultad de gestionar el proceso de desarrollo.
Los desarrolladores de software enfrentan el reto de dar a los usuarios la
impresión de simplicidad, esto es reducir al mínimo la complejidad externa. Este
reto les obliga a incrementar el tamaño de los sistemas, a inventar mecanismos
ingeniosos, o a reutilizar diseños y código ya existentes.
3.- La flexibilidad que se puede alcanzar a través del software.
La elaboración de software es una actividad muy laboriosa porque empuja al
desarrollador a construir por sí mismo prácticamente todos los bloques
fundamentales sobre los que se apoyan las abstracciones de más alto nivel. Esto
es propiciado, en gran medida, por la existencia de pocos estándares para el
control de calidad.
4.- Los problemas de caracterizar el comportamiento de sistemas discretos.
Los comportamientos de la mayoría de los objetos se representan por sistemas
analógicos en los que, a través de funciones continuas, pequeños cambios en las
entradas siempre producen pequeños cambios en las salidas.
Por el contrario, puesto que el software se ejecuta en computadoras digitales, se
tienen sistemas con un número finito de estados discretos. En sistemas
grandes, este número puede crecer a cantidades enormes. Como no existen
herramientas matemáticas para modelar el comportamiento completo de los
grandes sistemas discretos, se debe aceptar la pérdida de cierto grado de
confianza en cuanto a que las salidas sean correctas.
El papel de la descomposición.
Si la complejidad de los grandes sistemas de software no se puede eliminar,
¿cómo se puede manejar?
Desde tiempos remotos, el ser humano ha enfrentado la complejidad por medio de
la descomposición de un gran problema original en problemas más y más
pequeños.
Este precepto, que ha sido aplicado en diversos ámbitos, también se aplica en el
diseño de sistemas de software complejos, descomponiéndolos hasta llegar a un
nivel tal que puedan manejarse como problemas independientes.
Para manejar la descomposición es importante definir el criterio básico de
descomposición eligiendo un modelo o paradigma.
Descomposición algorítmica.
En este proceso de descomposición cada módulo del sistema representa alguna
parte de un proceso global, centrándose en la funcionalidad de los objetos y
dejando aparte los datos que representan sus atributos.
La mayoría de los de los desarrolladores han sido adiestrados en el diseño
estructurado descendente; y por eso suelen afrontar la descomposición como un
proceso de descomposición algorítmica.
Descomposición orientada a objetos.
En este tipo de descomposición el problema no se resuelve centrándose en el
código, sino que se modela como un conjunto de agentes autónomos, llamados
objetos, que colaboran para generar la solución.
Cada objeto sabe realizar ciertas tareas que otros objetos, a través de mensajes,
les piden realizar.
El criterio de descomposición orientado a objetos es mejor para ayudar a organizar
la complejidad innata de los sistemas de software, porque modela mejor a los
objetos del mundo real.