Diseño

2.2 Creación de clases a partir de análisis

En este programa de ejemplo propuesto, la descomposición en clases de la unidad anterior quedaría un poco "forzada", ya que su nivel de complejidad no es tan elevado como para justificarla.
Se puede optar por separar la parte visual de la parte lógica de modo que se pueda reutilizar la mayor cantidad de posible de código en caso de que más adelante se creara otra versión del programa del entorno gráfico. Para ello, se puede crear una ListaPersonas que cargue datos, los guarde y permita el acceso a los mismos. Así, los datos de cada persona pasarían de ser un struct a ser una clase que tendría los mismos campos, pero añadiría métodos que permitieran obtener y fijar los valores de esos campos y simplificar las búsquedas. 

Análisis

1.5- Diagramas de caso de uso

Un documento de especificación puede ser incomprensible para un cliente que no posea  conocimientos de programación informática. Por este motivo, se suelen elaborar diagramas con un contenido más visual y así facilitar la tarea al cliente
Uno de los más habituales es el diagrama de casos de uso. En estos, el sistema se representa como un rectángulo, las acciones se incluyen dentro de elipses y se dibujan figuras para simbolizar a diferentes tipos de personas que pueden interactuar con el sistema para realizar las correspondientes acciones.
Por ejemplo, una versión mejorada del programa podría incluir al usuario normal, que tendría la capacidad de ver y manipular datos; también podría incluir a un administrador, que éste podría consultar y añadir datos. El diagrama quedaría de la siguiente manera:

Diseño

2.1. Decisión de tareas a partir del análisis

Una vez analizados los requisitos que debe cumplir el programa, el siguiente paso consiste en decidir las estructuras básicas que van a emplearse para llevarlo a cabo.

La estructura de datos del programa podría ser la siguiente:

• Cada dato individual se almacena en un struct. Para que se puedan guardar tantos datos como se desee, los struct individuales se almacenaran en un vector

Y las funciones en las que se descompondria podrian ser estas:

-mostrarMenu : muestra la lista de opciones disponibles conforme al prototipo 
visual.

-nuevaFicha: pide los datos de una nueva persona y los añade a la lista de contactos 

existentes.

-verFichas: muestra en pantalla la primera ficha. Al pulsar sobre ciertas teclas, 

el usuario podrá elegir entre consultar la ficha anterior (si existe), la posterior 

(si existe),modificar la actual (llamando a una función adicional) o borrar la actual

llamando a otra funcion).

-modificar(n): pide los campos de la ficha que se indique como parámetro.

-intentarBorrar(n): solicita confirmación para borrar datos. Si el usuario confirma 

que desea borrarlos, la ficha se eliminará de la lista.

-buscarTexto: pide al usuario el texto que desea buscar, cuenta cuántas fichas lo 

contienen y, finalmente, las muestra de una en una. Tras mostrar el resumen de 

una ficha, da la opción de consultar con mayor detalle, 

-buscarCumpleMes: muestra las fechas de nacimiento y los nombres y apellidos

 de las personas que cumplen años en un cierto mes. 

-guardar: vuelca todos los datos a fichero, reemplazando el contenido anterior de

 dicho fichero. Se debe llamar automáticamente antes de salir del programa, de 

modo que los datos queden almacenados para la siguiente sesión. También es

 posible guardar los datos tras cada modificación, de manera que el contenido 

del fichero siempre esté actualizado.

-cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al 

principio del programa.

Análisis

1.3. Refinamiento

En las empresas de desarrollo de software, suele existir la figura del analista, experto encargado  de que el proceso de especificación sea lo más correcto posible.

En empresas pequeñas, es posible que no exista la figura del analista en estos casos, una segunda lectura pormenorizada de la especificación puede contribuir a afinar los detalles inicialmente ambiguos. Por ejemplo, para el programa del apartado anterior, 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? ¿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 especifico o no van a compartir con ninguna otra aplicación?
• ¿No será necesario modificar ni borrar datos?

Así, 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 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.

1.4. 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. Estos 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.

Así, los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. 

En los ejemplos de abajo, se puede observar que los prototipos pueden dar una idea tanto de los textos que aparecen en pantalla como de la forma en la que el usuario interactúa con el programa. Así, el usuario podría descubrir problemas de usabilidad del programa.

Análisis

1.1. Características del análisis de requisitos

Si se desea crear un programa en un tiempo limitado y con unos costes limitados, el primer paso consiste en pensar, de la forma más rigurosa posible, qué tareas debe realizar. En un programa realizado para uso propio, este detalle puede parecer de poca importancia, pero en el caso de una aplicación creada por encargo, este se convierte en un paso de mucha relevancia.

Crear una lista con los requisitos que debe cumplir el programa favorece la 
orientación del trabajo, la determinación de qué tareas son más importantes  y de cuáles no deben hacerse, así como el establecimiento del momento en el que el proyecto se podrá dar por terminado.
Este último aspecto es muy importante en un proyecto a medida, pues permite programa crezca indefinidamente .

Una vez que se ha estimado el tiempo necesario y se ha aprobado el presupuesto del proyecto, las características nuevas que el cliente desee deben anotarse para la realización de una versión posterior del proyecto.

1.2 Especificación 

Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa. En una primera aproximación, estos requisitos podrían reflejarse, en una «lista de cosas que el programa debe hacer». Sin embargo, para una aplicación real, es habitual distinguir al menos entre los requisitios funcionales y los requisitos técnicos 

Por ejemplo, para un programa no muy complejo, se podría partir de una lista como la siguiente:

• El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultar los más adelante.

• Deberá almacenar, para cada persona, el nombre, los apellidos, la fecha de na cimiento, el domicilio y el correo electrónico. El único dato obligatorio será el nombre; el resto de datos son opcionales,

• Permitirá guardar una cantidad elevada de datos (es decir, no deberá estar limitado a cincuenta o cien datos)

• Los datos deberán guardarse en fichero para que se pueda disponer de ellos cada vez que se acceda al programa.

• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda.

• El programa deberá haberse creado en C++ y permitirá trabajar en modo texto, de forma que se pueda compilar tanto para Windows como para LliureX o para cualquier otra versión de Linux.