CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

En el tema anterior vimos las pautas de seguir para descomponer un programa como una serie de clases que se relacionan entre sí. Sin embargo, para el programa de la agenda una descomposición en clases sería muy forzada debido a la poca complejidad del programa.

Pero se puede optar por separar la parte visual (aplicación principal) y la parte lógica (lista de personas) para reutilizar la mayor cantidad posible de código por si se creara otra versión del programa en el entorno gráfico o con otra interfaz. Para ello es posible crear una clase lista de personas que cargue y guarde datos permitiendo el acceso a ellos. Así los datos pasarían de se un struct a una clase con los mismos campos pero con métodos que permitieran obtener y fijar los valores de los campos al igual que simplificar la búsqueda.

DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS

Una vez realizados todos los requisitos tenemos que decidir las estructuras básicas que se van a emplear.
El programa propuesto es simple y podría realizarse en pocas horas, de modo que la fase de diseño podría reducirse a decidir qué estructuras usar.
Después se estudiará una versión más elaborada del programa, planteándolo como una serie de objetos que colaboran entre ellos.
La estructura de datos del programa podría ser:

• Cada dato se almacena en un struct, y cada struct se almacenará en un vector.

Y las funciones en las que se descompondría podrían ser estas:

• mostrarMenu: muestra la lista de opciones disponibles.
• nuevaFicha: pide los datos de una nueva persona y los añade a la lista.
• verFichas: muestra la primera ficha. Al pulsar sobre algunas teclas el usuario puede elegir si consultar la ficha anterior, modificar la actual o elegir otra.
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se desea cambiar un dato, se vuelve a introducir el texto. Si no se desea cambiar, bastará con pulsar Intro.
• intentarBorrar(n): si el usuario confirma que desea borrarlos, la ficha se elimina.
• buscarTexto: pide al usuario el texto que quiere buscar, cuenta las fichas y las muestra de una en una. Tras ver todas las fichas, se puede ir pasando de una en una. Si no existen más, la opción de continuar no aparece.
• buscarCumplesMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen en un cierto mes.
• guardar: vuelca todos los datos a fichero, reemplazando todo lo anterior a lo que actualmente estás guardando.
• cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al principio del programa.

DIAGRAMAS DE CASOS DE USO

Un documento de especificación puede resultarle incompresible a un cliente que no posea conocimientos de programación informática. Por ello, es frecuente elaborar diagramas que muestren los principales requisitos del programa de una forma más visual. Uno de los más habituales es el diagrama.
En los diagramas de casos de uso, el sistema se representa como un rectángulo, las acciones que pueden realizarse se incluyen dentro de elipses y se dibujan figuras para simbolizar a cada uno de los tipos de personas que pueden interactuar con el sistema para realizar las correspondientes acciones.
Por ejemplo, una versión mejorada del grama de la agenda de contactos podría incluir al usuario normal, que tendría la capacidad de ver y manipular datos, pero también a un administrador, que podría consultar y añadir datos, así como cambiar la contraseña de acceso al sistema. El diagrama quedaría de la siguiente manera:

ANÁLISIS 2.0

REFINAMIENTO

En las empresas de desarrollo de software, suele existir la figura del analista, encargado de hablar con el cliente, observar la forma en que este trabaja y formular las preguntas adecuadas para que el proceso de especificación sea lo más correcto posible.

En empresas pequeñas, es posible que no exista esta figura y es habitual que los programadores independientes no tengan tanta experiencia a la hora de identificar las necesidades del cliente. En estos casos, una segunda lectura permite afinar los detalles inicialmente ambiguos. Se podrían detectar las siguientes carencias:

• ¿No se podrán consultar los datos si no se hace una búsqueda?
• ¿Qué datos de cada persona que se encuentre a través de las búsquedas de texto deben mostrarse? ¿Se debe hacer una pausa tras la inserción de n datos o de cada datos? ¿Las búsquedas deben distinguir entre mayúsculas y minúsculas?
• ¿Qué datos de cada persona que cumpla años deben mostrarse?
• ¿Los datos se guardarán automáticamente o deberá seleccionarse, para ello, una opción determinada del menú?
• ¿Es necesario guardar los datos en fichero usando algún formato específico o no van a compartirse con ninguna otra aplicación?
• ¿No será necesario modificar ni borrar datos?

En la realización de un proyecto real es cada vez más habitual repetir varias veces la secuencia análisis.diseño-implementación-verificación, proceso que incluye reuniones con el cliente entre una secuencia y otra con el fin de que los errores y las carencias del programa puedan ser detectadas cuanto antes. En un proyecto de varios meses de duración, es habitual que se concierten reuniones cada dos semanas para evitar tener que dar costosos pasos atrás en caso de descubrir aspectos que no se hubieran entendido correctamente. 

PROTOTIPOS VISUALES

Una herramienta que puede resultar útil para contribuir a la detección de errores o malentendidos en la especificación de requisitos son los prototipos visuales. Consisten en la creación de <<maquetas>> de pantalla con las que se muestra al cliente una idea aproximada de cómo va a ser el resultado a nivel visual.

Los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. Por ejemplo, para la agenda de contactos, los ejemplos de abajo podrían constituir prototipos visuales de la pantalla de menú, de visualización y de visualización de un resultado de búsqueda. 

Ejemplo 1

Ejemplo 2

Ejemplo 3