UD 7. CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

2.2 CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

En la unidad anterior, se estudiaron las pautas básicas que deben seguirse para descomponer un programa real como una serie de clases que se relacionan entre sí. Para el programa de ejemplo propuesto, una descomposición en clases quedaría un poco forzada, ya que su nivel de complejidad no es tan elevado para justificarla.

Aún así, se podría optar por separar la parte visual (la aplicación principal) de la parte lógica (la lista de personas), de modo que se pudiera realizar la mayor cantidad posible de código en caso de que más adelante se creara otra versión del programa en un entorno gráfico (Windows Forms o Qt, por ejemplo) o con cualquier otro tipo de interfaz. Para ello es posible crear una clase ListaPersonas que se encargue de cargar y guardar datos, así como de permitir el acceso a los mismos. De esta manera, 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, así como simplificar las búsquedas.

UD 7. DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS

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 emplear para llevarlo a cabo.

El programa propuesto (la agenda de contactos) es simple; podrías ser realizado en pocas horas por un programador experto, de modo que la fase de diseño en este caso podría reducirse a decidir que estructuras de datos usar y en que funciones descomponer el cuerpo del programa.

Más adelante se estudiará na versión algo más elaborada del programa, en la que se plantea como una serie de objetos que colabora entre ellos, con la ayuda de un diagrama de clases.

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.

Las funciones en las que se descompondría serían las siguientes:

• mostrarMenu: muestra la lista de opciones disponibles conforme al prototipo visual.
• nuevaFicha: pide 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 función).
• modificar(n): pide los campos de la ficha que se indique como parámetro. En caso de que se desee cambiar un dato, se deberá volver a introducir el texto de los campos que se quieran modificar. Si, por el contrario, no se desea cambiar algún dato, bastará con pulsar intro para conservarlo como estaba.
• 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 consultarla con mayor detalle, contiene (mostrando la siguiente, si existe) o volver al menú. Si no existe una siguiente ficha, la opción Continuar no aparecerá.
• buscarCumpleMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en un cierto mes. En caso de haber más de una veinte datos, el programa efectuará una pausa cada veinte datos y esperará a que el usuario pulse intro. En esta primera versión, no es necesario que los datos aparezcan ordenados por fecha.
• 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 el fichero. Se debe llamar automáticamente al principio del programa.

UD. 7 Análisis (2)

1.3 REFINAMIENTO

La figura del analista es un experto encargado de hablar con el cliente, observar la forma en la que este trabaja y formular las preguntas adecuadas para que el proceso de especificación sea lo más correcto posible.

En las 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 este caso una segunda lectura pormenorizada de la especificación puede contribuir a afinar los detalles inicialmente ambiguos. Por ejemplo algunas carencias del programa de la entrada anterior puede ser:

• ¿Qué datos de cada persona que cumpla años debe mostrarse?
• ¿No será necesario borrar o modificar datos?
• ¿No se podrán consultar los datos si no se hace una búsqueda?

Es cada vez más habitual en la realización de un proyecto repetir 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 cadencias se corrijan.

1.4 PROTOTIPOS VISUALES

Una herramienta que puede ser ú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 muestre al cliente una idea aproximada de como 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. Ayudan a explicar como se va a relacionar el usuario con el programa.

UD 7. 1 Análisis (1)

1.1 CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS

Para crear un programa en un tiempo limitado y con costes limitados, lo primero que hay que hacer es pensar de forma rigurosa las tareas que queremos que realice, este paso adquiere mucha importancia en caso de que sea un programa pedido por encargo.

Podemos crear un lista de los requisitos que debe cumplir el programa para orientarnos mejor, también hay que establecer que tareas son las mas importantes y cuales no hay que hacer. También es muy importante establecer el momento en el que el proyecto se daría por acabado.

Cuando ya se haya calculado el tiempo necesario y se haya aprobado el presupuesto del proyecto, deben anotarse las características nuevas que desea el cliente ya que será más fácil usarlas para versiones posteriores del proyecto.

1.2 ESPECIFICACIÓN

Es aconsejable crear un documento en el que se recojan los requisitos que debe cumplir el programa. Que en principio simplemente sería una lista de las cosas que queremos que el programa haga, pero posteriormente hay que diferenciar entre los requisitos funcionales y los técnicos.

Un ejemplo de lista que sería bueno hacerla es la siguiente:

• El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultarlos más tarde.
• Deberá almacenar el nombre, los apellidos, la fecha de nacimiento, el domicilio y el correo electrónico de cada persona. Lo único obligatorio será el nombre, lo demás es opcional.
• Que permita guardar una gran cantidad de datos.
• Los datos se deben almacenarse en un fichero para tener acceso a ellos cada vez que se acceda al programa.
• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda.
• Buscará a las personas que cumplan años en los próximos 30 días.
• El programa  debe ser 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.