|
1.8. Gestión de excepciones: tratamiento de errores |
|
1.9.2. Fase 1: ¿Qué estamos haciendo? |
|
El paradigma orientado a objetos es una nueva forma de pensar sobre programación y mucha gente tiene problemas la primera vez que escucha cómo se aborda un proyecto POO. Una vez que se sabe que, supuestamente, todo es un objeto, y cómo aprender a pensar al estilo orientado a objetos, puede empezar a crear «buenos» diseños que aprovechen las ventajas de todos los beneficios que ofrece la POO.
Un método (llamado a menudo metodología) es un conjunto de procesos y heurísticas usados para tratar la complejidad de un problema de programación. Desde el comienzo de la programación orientada a objetos se han formulado muchos métodos. Esta sección le dará una idea de cuál es el objetivo que se intenta conseguir cuando se usa una metodología.
Especialmente en POO, la metodología es un campo de muchos experimentos, así que antes de elegir un método, es importante que comprenda cuál es el problema que resuelve. Eso es particularmente cierto con C++, en el que el lenguaje de programación pretende reducir la complejidad (comparado con C) que implica expresar un programa. De hecho, puede aliviar la necesidad de metodologías aún más complejas. En cambio, otras más simples podrían ser suficientes en C++ para muchos tipos de problemas grandes que podría manejar usando metodologías simples con lenguajes procedurales.
También es importante darse cuenta de que el término «metodología» a menudo es demasiado grande y prometedor. A partir de ahora, cuando diseñe y escriba un programa estará usando una metodología. Puede ser su propia metodología, y puede no ser consciente, pero es un proceso por el que pasa cuando crea un programa. Si es un proceso efectivo, puede que sólo necesite un pequeño ajuste para que funcione con C++. Si no está satisfecho con su productividad y con el camino que sus programas han tomado, puede considerar adoptar un método formal, o elegir trozos de entre muchos métodos formales.
Mientras pasa por el proceso de desarrollo, el uso más importante es éste: no perderse. Eso es fácil de hacer. La mayoría de los análisis y métodos de diseño pretenden resolver los problemas más grandes. Recuerde que la mayoría de los proyectos no encajan en esta categoría, normalmente puede tener un análisis y diseño exitoso con un subconjunto relativamente pequeño de lo que recomienda el método [17] . Pero muchos tipos de procesos, sin importar lo limitados que sean, generalmente le ofrecerán un camino mucho mejor que simplemente empezar a codificar.
También es fácil quedarse estancado, caer en análisis-parálisis, donde sentirá que no puede avanzar porque en la plataforma que está usando no está especificado cada pequeño detalle. Recuerde, no importa cuánto análisis haga, hay algunas cosas sobre el sistema que no se revelan hasta el momento del diseño, y más cosas que no se revelarán hasta que esté codificando, o incluso hasta que el programa esté funcionando. Por eso, es crucial moverse bastante rápido durante del análisis y diseño, e implementar un test del sistema propuesto.
Este punto merece la pena enfatizarlo. Debido a nuestra experiencia con los lenguajes procedurales, es encomiable que un equipo quiera proceder con cuidado y entender cada pequeño detalle antes de pasar al diseño y a la implementación. Desde luego, cuando crea un SGBD (Sistema Gestor de Bases de Datos), conviene entender la necesidad de un cliente a fondo. Pero un SGBD está en una clase de problemas que son muy concretos y bien entendidos; en muchos programas semejantes, la estructura de la base de datos es el problema que debe afrontarse. El tipo de problema de programación tratado en este capítulo es de la variedad «comodín» (con mis palabras), en el que la solución no es simplemente adaptar una solución bien conocida, en cambio involucra uno o más «factores comodín» -elementos para los que no hay solución previa bien entendida, y para los que es necesario investigar [18] . Intentar analizar minuciosamente un problema comodín antes de pasar al diseño y la implementación provoca un análisis-parálisis porque no se tiene suficiente información para resolver este tipo de problema durante la fase de análisis. Resolver estos problemas requiere interacción a través del ciclo completo, y eso requiere comportamientos arriesgados (lo cual tiene sentido, porque está intentando hacer algo nuevo y los beneficios potenciales son mayores). Puede parecer que el riesgo está compuesto por «prisas» en una implementación preliminar, pero en cambio puede reducir el riesgo en un proyecto comodín porque está descubriendo pronto si es viable un enfoque particular para el problema. El desarrollo del producto es gestión de riesgos.
A menudo se propone que «construya uno desechable». Con la POO, todavía debe andar parte de este camino, pero debido a que el código está encapsulado en clases, durante la primera iteración inevitablemente producirá algunos diseños de clases útiles y desarrollará algunas ideas válidas sobre el diseño del sistema que no necesariamente son desechables. De esta manera, la primera pasada rápida al problema no produce sólo información crítica para la siguiente iteración de análisis, diseño, e implementación, sino que además crea el código base para esa iteración.
Es decir, si está buscando una metodología que contenga detalles tremendos y sugiera muchos pasos y documentos, es aún más difícil saber cuándo parar. Tenga presente lo que está intentando encontrar:
¿Cuáles son los objetos? (¿Cómo divide su proyecto en sus partes componentes?)
¿Cuáles son sus interfaces? (¿Qué mensajes necesita enviar a otros objetos?)
Si sólo cuenta con los objetos y sus interfaces, entonces puede escribir un programa. Por varias razones podría necesitar más descripciones y documentos, pero no puede hacerlo con menos.
El proceso se puede realizar en cinco fases, y una fase 0 que es simplemente el compromiso inicial de usar algún tipo de estructura.
Primero debe decidir qué pasos va a dar en su proceso. Parece fácil (de hecho, todo esto parece fácil) y sin embargo la gente a menudo no toma esta decisión antes de ponerse a programar. Si su plan es «ponerse directamente a programar», de acuerdo (a veces es adecuado cuando es un problema bien conocido). Al menos estará de acuerdo en que eso es el plan.
También debe decidir en esta fase si necesita alguna estructura de proceso adicional, pero no las nueve yardas completas. Bastante comprensible, algunos programadores prefieren trabajar en «modo vacaciones» en cuyo caso no se impone ninguna estructura en el proceso de desarrollo de su trabajo; «Se hará cuando se haga». Eso puede resultar atractivo durante un tiempo, pero se ha descubierto que tener unos pocos hitos a lo largo del camino ayuda a enfocar e impulsar sus esfuerzos en torno a esos hitos en lugar de empezar a atascarse con el único objetivo de «finalizar el proyecto». Además, divide el proyecto en piezas más pequeñas y hace que dé menos miedo (y además los hitos ofrecen más oportunidades para celebraciones).
Cuando empecé a estudiar la estructura de la historia (por eso algún día escribiré una novela) inicialmente me resistía a la idea de una estructura, sentía que cuando escribía simplemente permitía que fluyera en la página. Pero más tarde me di cuenta de que cuando escribo sobre computadoras la estructura es bastante clara, pero no pienso mucho sobre ello. Pero aún así estructuro mi trabajo, aunque sólo semi-inconscientemente en mi cabeza. Si aún piensa que su plan es sólo ponerse a codificar, de algún modo, usted pasará por las posteriores fases mientras pregunta y responde ciertas cuestiones.
Cualquier sistema construido, no importa cuan complicado sea, tiene un propósito fundamental, el negocio que hay en él, la necesidad básica que satisface. Si puede ver la interfaz de usuario, el hardware o los detalles específicos del sistema, los algoritmos de codificación y los problemas de eficiencia, finalmente encontrará el núcleo de su existencia, simple y sencillo. Como el así llamado concepto de alto nivel de una película de Hollywood, puede describirlo en una o dos frases. Esta descripción pura es el punto de partida.
El concepto de alto nivel es bastante importante porque le da el tono a su proyecto; es una declaración de principios. No tiene porqué conseguirlo necesariamente la primera vez (podría tener que llegar a una fase posterior del proyecto antes de tenerlo completamente claro), pero siga intentándolo hasta que lo consiga. Por ejemplo, en un sistema de control de tráfico aéreo puede empezar con un concepto de alto nivel centrado en el sistema que está construyendo: «El programa de la torre sigue la pista a los aviones». Pero considere qué ocurre cuando adapta el sistema para un pequeño aeropuerto; quizá sólo haya un controlador humano o ninguno. Un modelo más útil no se preocupará de la solución que está creando tanto como la descripción del problema: «Llega un avión, descarga, se revisa y recarga, y se marcha».
[17] Un ejemplo excelente es UML Distilled, de Martin Fowler (Addison-Wesley 2000), que reduce el, a menudo, insoportable proceso UML a un subconjunto manejable.
[18] Mi regla general para el cálculo de semejantes proyectos: Si hay más de un comodín, no intente planear cuánto tiempo le llevará o cuánto costará hasta que haya creado un prototipo funcional. También hay muchos grados de libertad.
