Main logo La Página de DriverOp

Técnicas de Programación

El éxito está en el diseño.

Los programadores noveles, aquellos que recién se inician en esta actividad, ya sea egresados de alguna carrera universitaria o simplemente a base de conocimientos adquiridos empíricamente desarrollan un gran conocimiento de programación técnica, es decir, se saben todos los trucos y vericuetos del lenguaje en el que programan, suelen conocer a fondo cada algoritmo y cada secuencia de sentencia que le harán realizar programas muy bien hechos desde el punto de vista funcional y estético, la mayoría de las veces cuando alguien tiene una duda sobre programación es precisamente alguna cosa como "poner linda la pantalla" o bien la técnica adecuada para burlar alguna limitación (real o simplemente por falta de ese conocimiento) del lenguaje en cuestión. Sin embargo muy pocas veces alguien tiene una duda acerca del diseño de un programa, saben qué es lo que quieren lograr, conocen las técnicas para hacerlo pero no saben cómo aplicar esas técnicas.

En Internet se hace muy evidente para mi ver que está plagado de cosas y trucos para programadores que resuelven problemas sumamente puntuales, a veces complejos, a veces no tanto pero muy pocas veces he visto textos de cómo resolver problemas de diseño. Esto, a mi parecer es grave, porque el diseño de software o la Ingeniería detrás de un proyecto de software es aún mas importante que la codificación del mismo. Es común ver que al plantearsele un problema a un programador este gire inmediatamente hacia el computador y empiece a tipear el código fuente de un programa casi de inmediato antes de siquiera tomar un trozo de papel y hace un bosquejo del problema. Es que el diseño suele ser algo aburrido para un programador. No pasa esto con quienes tenemos años de experiencia en esta actividad. Luego de plateado el problema generalmente nos pegamos a un pizarrón, crayola en mano a dibujar toda suerte de cuadros, flechas, círculos y anotaciones, esto es así porque sabemos que por mas buenos codificadores que seamos, por mas depurado y rápido que sea el programa resultante si está mal diseñado es un programa que no sirve.

Esto se crucial a la hora de tratar de vender un programa por nosotros realizado, es casi imposible tener éxito con un software que se ve bien pero "no hace lo que se le pide". Al momento de escribir esto (año 2001) todavía veo que muchos clientes aún usan programas hechos en DOS, ejecutado bajo Windows si, pero DOS al fin, ¿y por qué?, simplemente porque si ese programa era muy bueno hace 6 años atrás nada hizo que aún no lo sea y no importa si ahora el S. O. es con interfase de realidad virtual, el viejo programita en DOS "hace lo que se le pide y lo hace bien", y lo hace así porque en su momento el o los programadores comprendieron muy bien la importancia del análisis y diseño del software en cuestión.

El diseño es la base del éxito de un programa. Por eso, al mismo tiempo que se aprende a escribir código es muy importante aprender a diseñar software.

Se distinguen cuatro etapas en el diseño de un software en particular

  • Factibilidad.
  • Estimación de Recursos.
  • Recopilación de información.
  • Diagramación y modelado.

Factibilidad: es el proceso inicial en el cual se determina el ámbito de aplicación del software a realizar y a partir de ahí determinar a su vez si el software es realizable.

Estimación de recursos: se contabiliza (ya sea de forma empírica o con mediciones) los recursos que serán necesarios involucrar en el proyecto, sean tiempo, cantidad de personas, etc. y las herramientas necesarias para comenzar a desarrollar el proyecto.

Recopilación de información: debe tenerse a mano toda la información relevante al proyecto ANTES de empezar a diagramar y modelar un software. Esta información pueden ser, qué es lo que hará el software mas que cómo lo hará (eso se analiza en la etapa siguiente). Aquí es muy útil hacer una serie de cuestionarios o visitas al lugar de implementación del software, o bien estudiar qué cosas deben incluirse (o no) en el software.

Diagramación y modelado: aquí se confecciona un esquema general del software, se describen módulos, entidades y todas las relaciones que serán luego codificadas. En el caso de trabajar en equipos aquí es buen momento para dividir el trabajo en cada uno de los componentes de equipo, y bien establecer un orden de confección del código fuente teniendo especial cuidado en las interdependencias del mismo.

Solo cuando se concluye la etapa de Diagramación y Modelado es posible pasar a la etapa de codificación, hay muchas técnicas bien documentadas que nos ayudarán en la etapas del diseño, tales como DER, DFD o GANT.

Capas vs Módulos.

Un software con diseño por capas se define como una serie de programas que tienen dependencia vertical donde se tiene un programa o conjunto de definiciones de datos que son la base del mismo y sobre el cual se apilan o apoyan otros programas. Este tipo de diseño es el mas sencillo de implementar, además es el mas antiguo ya que nació junto con el concepto de Sistema Operativo a finales de los 50 (antes de eso no existía tal cosa porque solo había un software en ejecución al mismo tiempo) donde tenemos al S. O. en la parte mas baja interactuando con el hardware y un programa de aplicación que se comunica hacia abajo mientras que el S O devuelve respuestas hacia arriba. De hecho el programa base no hace nada por si mismo mas que servir a los programas que se le ejecutan encima de él.

La gran ventaja que tiene este método es, como ya mencioné, la facilidad del diseño, la gran desventaja es que hace que el sistema todo se vuelva monolítico, es decir que para mejorar la base debe modificarse a su vez la cima. Como ejemplo vaya esto: si armamos un sistema de facturación y en un momento dado reformamos la definición de la estructura de archivos debemos reformar a su vez todos los programas que usan esa nueva definición. Un ejemplo concreto de este diseño es Windows mismo.

Por otro lado el software diseñado en módulos es mas flexible ya que la comunicación es horizontal. En este caso se diseña primero un modulo el cual es el principal y el cual se sirve de una serie de módulos que están al mismo nivel que este. De esta manera el cambio de algún aspecto dentro de un modulo es totalmente transparente al resto. Como desventaja diré que la programación es mucho mas complicada que en el caso anterior ya que se hace sumamente necesario definir muy bien el ámbito de cada modulo sin que en ningún momento se superponga con otros módulos (lo que lleva a la temida redundancia de código) y un aumento considerable de la interdependencia entre modulos.

A pesar de estas dos filosofías no existe software que sea totalmente modular ni totalmente monolítico. Solo basta pensar que siempre necesitaremos una definición de bases de datos (lo que sería la capa base) y siempre necesitaremos de algún programa externo que por su constante uso no conviene repetir el código en todos los programas que lo usemos (lo que se convertiría en un módulo). Un ejemplo de software con diseño modular es Linux.

Mi consejo es tratar de diseñar todo el software que hagamos de forma modular porque si bien el modelo monolítico es mas rápido de implementar (traducido, el producto de software lo tendremos más rápido en la calle) después es demasiado trabajoso de mantener y actualizar y eso a veces es mas determinante que el tiempo de salida a la calle. Por otro lado el diseño modular hace que el software sea mas flexible y adaptable a cualquier circunstancia futura no prevista en la etapa de diseño.

El secreto de la programación modular está en la parametrización, los parámetro terminan de definir el software al momento de ponerlo a trabajar. Supongamos que tenemos un sistema de facturación, el cual tiene, por diseño, dos módulos, uno de confección de facturas, el otro de mantenimiento de cuentas corrientes, en un momento dado la factura que se está haciendo necesitará de un cliente al cual cargarle la factura, entonces primero consultará un archivo de parámetros (o el registro de Windows dado el caso) para saber si el modulo de cuentas corrientes, encargado de administrar todo lo que tenga que ver con clientes, está instalado, si es así invocará un proceso en ese modulo que le presentará al usuario un listado de los clientes, el usuario elegirá uno, el modulo cuentas corrientes pasará al modulo de facturación el código del cliente seleccionado y facturará. Al final el modulo de facturación comunicará (siempre horizontalmente) al modulo de cuentas corrientes que al cliente elegido se le cargue la factura recién hecha, el modulo de cuentas corrientes hará lo que tenga que hacer al respecto. Véase que he mencionado la consulta a un parámetro, en la practica el proceso descrito implica muchos parámetros mas tales como limite de deudas admitidas, tipo de facturación para el cliente dado, forma de confeccionar la factura, etc... y dependiendo de la complejidad del sistema pueden estar involucrados otros muchos módulos mas.

Diego Romero -

Comentarios

Agregar comentario

No hay comentarios aún.

cerrar
Espera un momento...
Cargando...
Ups!, algo anda mal.