Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 17 — #55
✐
1.9. Análisis y diseño
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 7 . 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 8 . 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
7 Un ejemplo excelente es UML Distilled, de Martin Fowler (Addison-Wesley 2000), que reduce el, a
menudo, insoportable proceso UML a un subconjunto manejable.
8 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.
17
✐
✐
✐
✐