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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 19 — #57
✐
1.9. Análisis y diseño
Declaración de objetivos
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».
1.9.2. Fase 1: ¿Qué estamos haciendo
En la generación previa de diseño de programas (llamado diseño procedural), esto
se llamaba «crear el análisis de requisitos y especificación del sistema». Éstos, por supuesto,
eran lugares donde perderse; documentos con nombres intimidantes que podrían
llegar a ser grandes proyectos en sí mismos. Sin embargo, su intención era buena. El
análisis de requisitos dice: «Haga una lista de las directrices que usará para saber
cuándo ha hecho su trabajo y el cliente estará satisfecho». La especificación del sistema
dice: «Hay una descripción de lo que hará el programa (no cómo) por satisfacer los
requisitos». El análisis de requisitos es realmente un contrato entre usted y el cliente
(incluso si el cliente trabaja dentro de su compañía o es algún otro objeto o sistema).
Las especificaciones del sistema son una exploración de alto nivel del problema y en
algún sentido un descubrimiento de si se puede hacer y cuánto se tardará. Dado que
ambos requerirán consenso entre la gente (y porque suelen cambiar todo el tiempo),
creo que es mejor mantenerlos todo lo escueto posible -en el mejor de los casos, listas
y diagramas básicos- para ahorrar tiempo. Podría tener otras restricciones que
le exijan ampliarla en documentos más grandes, pero manteniendo el documento
inicial pequeño y conciso, puede crearse en algunas sesiones de tormentas de ideas
de grupo con un líder que cree la descripción dinámicamente. Esto no sólo solicita
participación de todos, también fomenta aprobación inicial y llegar a acuerdos entre
todos. Quizá lo más importante sea empezar el proyecto con mucho entusiasmo.
Es necesario no perder de vista lo que está intentando conseguir en esta fase:
determinar el sistema que se supone que quiere hacer. La herramienta más valiosa
para eso es una colección de los llamados «casos de uso». Los casos de uso identifican
características clave en el sistema que pueden revelar algunas de las clases
fundamentales que se usarán. En esencia son respuestas descriptivas a preguntas
como: 9 :
1. «¿Quién usará el sistema»
2. «¿Qué pueden hacer estos actores con el sistema»
9 Gracias a James H Jarrett por su ayuda.
19
✐
✐
✐
✐