La relevancia de proyectarse – o hacer diseño

de software – puede ser explicada por la

complejidad creciente de los sistemas de
software. Debido a esa comple- jidad, el riesgo
de construirse un sistema que no alcance sus
objetivos es emi- nente. Para evitar tal riesgo,
la práctica común de cualquier ingeniería para
construir un artefacto complejo, un sistema de
software complejo en nuestro caso, es
cons- truirlo de acuerdo con un plan. En otras
palabras, proyectar el sistema antes
de construirlo. El resultado de esa actividad,
también conocida como actividad dediseño, es
también llamado diseño. El diseño facilita dos
actividades que son esenciales en el ciclo de
vida de un sistema de software. Primero, él
posibilita la evaluación del sistema contra sus
objetivos antes aún de ser construido. De
esa manera, aumenta la confianza de que el
sistema construido, de acuerdo con el
di- seño, alcanzará sus objetivos. Obviamente,
una vez que en ese punto está sólo el modelo
del sistema – el diseño –, la evaluación no será
completa, pero eso tam- poco quiere decir
que ella no ofrezca resultados importantes
que lleven al éxito del sistema. De esta forma,
otra actividad beneficiada por el diseño es la
propia construcción del sistema, dado que
también sirve como guía para la
implemen- tación del software. A continuación,
mostramos un ejemplo de como el diseño
permite la evalua- ción del software. Se
muestra parte de la primera versión del
diseño de un sistema distribuido de
almacenamiento, el HBase y, a través de una
breve eva- luación de ese diseño, observamos
una grave limitación del software. EJEMPLO:
El HBase es un sistema de
almacenamiento distribuido. Eso quiere decir
que los datos sometidos a él no serán
guardados en un único ser- vidor, sino en
varios. De forma simplificada, el diseño del
HBase define dos tiposde entidades en el
sistema: el data nodo, que es el subsistema
que almacena los datos, y el master nodo, que
es el subsistema que sabe en que data
nodos los datos fueron escritos y pueden
ser recuperados. En la primera versión
del HBase, sólo existía un master nodo que
coordinaba todos los data nodos. Así, para
recuperar o escribir datos en el HBase, un
cliente realizaba los siguientes pasos:
primero, el cliente se comunicaba con el
master nodo a fin de conseguir, de acuerdo
con una clave, la dirección del data nodo en
que él puede realizar la operación deseada
(lectura o escritura). Enseguida, el master
nodo, que coordina donde los datos deben
quedar, devuelve la dirección del data nodo
que debería poseer los datos para la referida
clave. A partir de ahí, el cliente, ya con
la dirección, se comunicaba directamente
con el data nodo y realizaba la operación
deseada (escritura o lectura). Si evaluáramos
este diseño, podemos percibir dos
características del HBase. La primera, es que
no adopta el uso de un cliente flaco (thin
client). Con eso, la implementación y
configuración del cliente se hace más
compleja, una vez que el cliente necesita
conocer el protocolo de escritura y lectura del
HBase, además de necesitar acceder tanto al
master nodo como a los data nodos. Esto
dificulta el
diseño, es también llamado diseño. El diseño facilita dos actividades que son
esenciales en el ciclo de vida de un sistema de software. Primero, él posibilita la
evaluación del sistema contra sus objetivos antes aún de ser construido. De esa
manera, aumenta la confianza de que el sistema construido, de acuerdo con el
diseño, alcanzará sus objetivos. Obviamente, una vez que en ese punto está sólo el
modelo del sistema – el diseño –, la evaluación no será completa, pero eso tampoco
quiere decir que ella no ofrezca resultados importantes que lleven al éxito del
sistema. De esta forma, otra actividad beneficiada por el diseño es la propia
construcción del sistema, dado que también sirve como guía para la implementación
del software.
A continuación, mostramos un ejemplo de como el diseño permite la evaluación del
software. Se muestra parte de la primera versión del diseño de un sistema
distribuido de almacenamiento, el HBase y, a través de una breve evaluación de ese
diseño, observamos una grave limitación del software.
EJEMPLO: El HBase es un sistema de almacenamiento distribuido. Eso quiere
decir que los datos sometidos a él no serán guardados en un único servidor, sino en
varios. De forma simplificada, el diseño del HBase define dos tipos
de entidades en el sistema: el data nodo, que es el subsistema que almacena los
datos, y el master nodo, que es el subsistema que sabe en que data nodos los
datos fueron escritos y pueden ser recuperados. En la primera versión del HBase,
sólo existía un master nodo que coordinaba todos los data nodos. Así, para
recuperar o escribir datos en el HBase, un cliente realizaba los siguientes pasos:
primero, el cliente se comunicaba con el master nodo a fin de conseguir, de
acuerdo con una clave, la dirección del data nodo en que él puede realizar la
operación deseada (lectura o escritura). Enseguida, el master nodo, que coordina
donde los datos deben quedar, devuelve la dirección del data nodo que debería
poseer los datos para la referida clave. A partir de ahí, el cliente, ya con la
dirección, se comunicaba directamente con el data nodo y realizaba la
operación deseada (escritura o lectura).
Si evaluáramos este diseño, podemos percibir dos características del HBase. La
primera, es que no adopta el uso de un cliente flaco (thin client). Con eso, la
implementación y configuración del cliente se hace más compleja, una vez que el
cliente necesita conocer el protocolo de escritura y lectura del HBase, además de
necesitar acceder tanto al master nodo como a los data nodos. Esto dificulta el
QUE ES EL DISEÑO DE SOFTWARE Para
definir el diseño de software, algunos autores
lo hacen en dos sentidos dis- tintos: cuando el
diseño de software es usado como producto y
cuando es usado como proceso. Cuando es
usado en el primer sentido, el término diseño
de so- ftware indica el producto que emerge
del acto (o proceso) de proyectar un
sistema de software y siendo así algún
documento u otro tipo de representación del
deseo del director de proyecto (o diseñador).
Ese producto es el resultado de las
deci- siones del diseñador para formar una
abstracción del sistema que es deseado en
el mundo real. Existen diversas formas de
representar esa abstracción del sistema.
Podemos citar, por ejemplo, dibujos usando
cajas y flechas, textos descriptivos, o incluso
el uso de lenguajes o herramientas creadas
para este propósito, como len- guajes de
modelado de software, redes, pseudocódigo,
etc. Por otro lado, cuando el término es usado
en el segundo sentido, hacer diseño indica el
proceso seguido para obtenerse un proyecto.
Ese es un proceso que forma parte del
proceso de las diversas partes interesadas en
el desarrollo y que es orientado a los objetivos
del software. Él debe ser realizado teniendo en
mente el sistema y debe ser fundamentado en
el conocimiento del diseñador sobre el
domi- nio del problema. A partir de la visión de
diseño como artefacto, podemos observar que
él debe describir diversos aspectos del
software para que, así, posibilite su
construcción. Entre estos aspectos, están:
•la estructura estática del sistema, incluyendo
la jerarquía de sus módulos;
•la descripción de los datos a ser usados;
•los algoritmos a ser usados;
•el empaquetamiento del sistema, en
términos de como los módulos están
CARACTERÍSTICAS DEL DISEÑO DE
SOFTWARE Proyectar los diversos aspectos
de un sistema de software es un proceso
muy trabajoso. Sin embargo, puede
proporcionar diversos
beneficios. El diseño de software permite la e
valuación previa. Como desarrollar software
cuesta tiempo y dinero, no parece sensato
para alguien invertir sus recursos en
el desarrollo de un sistema que no soluciona
los problemas propuestos por los
in- teresados. De esa manera, la evaluación
previa del sistema se hace
imprescindible para garantizar que este
alcance los objetivos de esos interesados.
Como el diseño describe diversos aspectos
que estarán presentes en el sistema cuando
esté cons- truido, permite ese tipo de
evaluación. Además de eso, hacer el diseño de
un sis- tema es, generalmente, más barato
que construirlo.
EJEMPLO: Considerando un sistema y que uno
de sus objetivos fuera la alta disponibilidad,
podemos evaluar que el diseño presentado no
sería la mejor solu- ción para el objetivo
propuesto. Eso ocurre porque su diseño posee
un punto único de fallos, que es una
característica indeseable para sistemas que
buscan alta disponibilidad. Observe que no fue
necesario tener el HBase desarrollado
para conocer ese problema (en la época en
que se implementaba tal diseño, poseía cerca
de cien mil líneas de código y algunos años
de desarrollo y, por lo tanto, no estaba siendo
un software de desarrollo trivial), bastó sólo
con estudiar su diseño.