PUNTO 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.

Para que se pudiera reutilizar la mayor cantidad posible de código en caso de que se creara otra versión del programa en un entorno gráfico u otro tipo de interfaz más adelante, se podría separar la parte visual de la parte lógica. 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.

PUNTO 2.1

DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS

Después de analizar los requisitos que debe tener el programa, ahora se deben decidir las estructuras básicas que van a emplearse.

La fase de diseño podría reducirse a decidir qué estructuras de datos usar y en qué funciones descomponer el cuerpo del programa. Más adelante se estudiará una versión algo más elaborada del programa.

La estructura de datos del programa podría ser:

• Struct: lugar donde se almacena cada dato individual. Los struct individuales se almacenarán en un vector.

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

• mostrarMenu: muestra la lista de opciones disponibles conforma al prototipo visual.
• nuevaFicha: pide los datos de una nueva persona y los añade a la lista de contactos existentes.
• verFichas: muestra la primera ficha. Al pulsar ciertas teclas, el usuario podrá elegir entre consultar la ficha anterior, la posterior, modificar una actual o borrar la actual.
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se quiere cambiar un dato, se debe introducir el texto de los campos que se quieran modificar y si no se desea cambiar algún dato, bastará con pulsar Intro.
• intentarBorrar(n): solicita confirmación para borrar datos.
• buscarTexto: pide al usuario el texto que desea buscar, cuenta cuántas fichas lo contienen y las muestra de una en una. Después, da la opción de consultarla con mayor detalle, continuar (que no aparecerá si no existe ninguna ficha) o volver al menú.
• buscarCumplesMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en un cierto mes. Si hay más de 20 datos, el programa hará una pausa cada 20 datos y esperará a que el usuario pulse Intro. No es necesario que los datos aparezcan ordenados por fecha.
• guardar: vuelca todos los datos a fichero. Para que los datos queden guardados antes de salir del programa, es necesario darle a esta opción. También se puede guardar después de cada modificación.
• cargar: lee todos los datos del fichero. Se debe llamar automáticamente al principio del programa.

PUNTO 1.5

DIAGRAMAS DE CASOS DE USO

Debido a que muchos clientes no poseen conocimientos de programación informática y puede resultarle incomprensible un documento de especificación, se han creado unos diagramas, como el diagrama de casos de uso, que muestre de forma visual los principales requisitos del programa.

En los diagramas de casos de uso, el sistema se presenta como un rectángulo, las acciones dentro de elipses y los tipos de personas se muestran como figuras (llamadas actores) que pueden interactuar con el sistema para realizar acciones.

Por ejemplo, una versión mejorada del programa de la agenda de contactos podría incluir al usuario normal, que puede 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.

PUNTO 1.4

PROTOTIPOS VISUALES

Los prototipos visuales, que sirven para crear "maquetas" de pantalla con las que se muestra al cliente una idea aproximada de cómo va a ser el resultado a nivel visual, son una herramienta muy útil en la detección de errores en la especificación de requisitos.

Estos prototipos permiten que el usuario detecte si hay algún fallo. Por ejemplo, en la agenda de contactos, en la visualización de datos, etc.

Los prototipos pueden dar una idea tanto de los textos que aparecerían en pantalla como de la forma en la que el usuario interactuaría con el programa. Así, el usuario podría descubrir problemas de usabilidad del programa.

PUNTO 1.3

REFINAMIENTO

Para que el proceso de especificación sea lo más correcto posible, en las empresas de desarrollo de software existe una figura del analista, que se encarga de hablar con el cliente, observar la forma en la que se trabaja, etc.

En las empresas pequeñas, se puede dar el caso de que no dispongan de analista y su facilidad para detectar las necesidades del cliente sea menor. Esto se soluciona con una segunda lectura pormenorizada de la especificación para afinar los detalles que inicialmente eran 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? ¿Se debe hacer una pausa tras la inserción de n datos o de cada dato? ¿Las búsquedas deben distinguir entre mayúsculas y minúsculas?
• ¿Qué datos de cada persona que cumpla años deben mostrarse?
• Etc.

De esta forma, al realizar un proyecto real, es cada vez más común repetir la secuencia análisis-diseño-implementación-verificación, incluyendo reuniones con el cliente entre una secuencia y otra para que los errores y carencias del programa puedan ser descubiertos cuanto antes. Son muy necesarias las reuniones cada dos semanas aproximadamente porque evitan que haya que dar costosos paso atrás en caso de descubrir aspectos que no se hubieran entendido correctamente.

PUNTO 1.2

ESPECIFICACIÓN

Es muy común que se elabore una "lista de cosas que el programa debe hacer", pero en las aplicaciones reales se suele distinguir entre los requisitos funcionales (lo que el programa hará) y requisitos técnicos (limitaciones "físicas", espacio máximo en disco que ocupará el programa, etc).

Un ejemplo de una lista para un programa no muy complejo es:

• Podrá guardar datos de personas para consultarlos más adelante.
• Almacenará datos de personas (nombre, dirección, etc) aunque el único imprescindible será el nombre.
• Podrá guardar una cantidad elevada de datos, sin limitaciones.
• Se podrá disponer de los datos cada vez que se acceda al programa porque deberán guardarse en un fichero.
• Se podrán buscar datos a partir de cualquier palabra introducida, apareciendo toda la información disponible (nombre, apellidos, domicilio o correo electrónico).
• Buscará a personas que cumplan años en los próximos treinta días.
• El programa debe estar creado en C++ y se podrá compilar tanto en Windows como en LliureX u otra versión de Linux ya que permitirá trabajar en modo texto.

TEMA 7. PUNTO 1.1

CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS

Para crear un programa con un determinado tiempo y presupuesto, lo primero es pensar qué

tareas se van a realizar. Puede que sea menos relevante si el programa es para uso propio, pero si es una aplicación por encargo, esto adquiere mucha importancia.

Para tener una buena organización del programa, se puede crear una lista con los requisitos que debe cumplir. Esto favorece la determinación de qué tareas son importantes y cuáles no deben hacerse y el establecimiento del momento en el que finalizará el proyecto, algo muy importante en los proyectos a medida ya que evita que el programa pueda crecer indefinidamente añadiéndole nuevas características cada cierto tiempo.

Cuando ya se conocen el tiempo necesario y el presupuesto se deben añadir las características deseadas por el cliente y volver a calcular el tiempo y los recursos necesarios para añadirlas.