Directorio telefonico

DESCRIPCIÓN GENERAL:
El proyecto final consiste en una libreta o agenda de direcciones, donde el usuario podrá almacenar una lista de contactos y, para cada uno de estos, su respectiva información personal y de localización. Dicho proyecto será codificado en su totalidad por cada equipo de alumnos usando el lenguaje de programación C++. Se recomienda el uso de el ambiente de desarrollo Codeblocks v16.01, pero cada equipo es en última instancia responsable de seleccionar las herramientas de desarrollo que utilizará en cada caso.


requerimientos de interacción con el usuario (riu).
1.    Al iniciar, el programa deberá desplegar una lista de instrucciones con todos los comandos disponibles. Esta misma lista será desplegada cada vez que el usuario solicite el comando ‘?’.
2.    El programa presentará al usuario un prompt (la cadena de caracteres “$> “) cada vez que solicite el ingreso de un comando, evitando la confusión que podría presentarse si el usuario no reconoce que se espera una entrada.
3.    Todos los mensajes generados por el programa estarán codificados como ASCII imprimible (rango 32 a 127), más los caracteres de control habituales como el salto de línea. El programa aceptará que el usuario ingrese caracteres de ASCII extendido (rango 128 a 255), pero no se garantiza que los caracteres exclusivos del alfabeto español (‘Ñ’, ‘n’, y vocales acentuadas) sean interpretadas correctamente por herramientas ajenas al mismo programa.
4.    Todos los comandos, con excepción del comando de ayuda (‘?’), serán representados por una sola letra del alfabeto inglés. El programa, en tanto esté procesando comandos, no hará distinción de mayúsculas y minúsculas.

requerimientos funcionales (rf):
1.    El programa operará en un ciclo infinito, presentando al usuario la posibilidad de ejecutar un comando en cada iteración del ciclo. El programa terminará cuando el usuario seleccione el comando (S)alir.

2.    El programa soportará una lista de contactos, a la cual podrá (A)gregar o (E)liminar elementos usando los comandos correspondientes.
a.    En el caso de (A)gregar, el programa ubicará al nuevo contacto en la primera posición disponible dentro de la lista. El comando reportará un mensaje de error si la lista se encuentra llena en ese momento.
b.    En el caso de (E)liminar, el programa solicitará al usuario que escriba la posición en la lista del contacto a eliminar.
3.    La lista tendrá una longitud inicial de 10 elementos, pero podrá ser expandida para aumentar su capacidad con el comando (I)ncrementar. La capacidad actual, así como el número  de elementos utilizados, de la lista puede ser consultada usando el comando (N)úmero.
4.    El contenido de la lista podrá consultarse usando el comando (M)ostrar. Dicha consulta presentará al usuario con una lista que muestra exclusivamente el nombre, apellido paterno, e inicial del apellido materno del contacto, así como su posición en la lista. El domicilio y teléfono de cada contacto podrán ser desplegados mediante el comando (D)etalles.
El programa solicitará el número de contacto al usuario para desplegar solo los detalles de un contacto seleccionado.
5.    El contenido de la lista podrá filtrarse usando el comando (B)uscar, que desplegará solo aquellos elementos de la lista que cumplan con el criterio de selección. Dicho criterio será una palabra provista por el usuario, que deberá encontrarse como parte del nombre o de los apellidos del contacto. Dicho filtro ignorará la diferencia entre mayúsculas y minúsculas.

a.    Si ningún contacto cumple con los criterios del filtro, se mostrará al usuario un mensaje de error indicando este hecho.
6.    El usuario podrá modificar los datos de un contacto que ya ha sido agregado a la lista, mediante el comando (C)ambiar. Una vez que se seleccione el número de contacto que hay que modificar, el programa presentará al usuario con el contenido actual de cada campo de datos, y el usuario podrá ingresar un nuevo valor, o bien, conservar el valor actual tecleando solamente la techa ENTER.
7.    Todos los comandos que capturan un número o posición en la lista para afectar a un solo contacto deberán verificar que dicha posición sea válida, tanto en el caso que la posición exista dentro de la lista como el que dicha posición se encuentre ocupada por un comando válido. En caso de no ser así, se presentará un mensaje al usuario informándole cual es el motivo de la falla y se le pedirá que vuelva a intentar un máximo de 3 veces. Después de 3 intentos fallidos, el comando terminará su ejecución sin realizar ninguna otra acción.

8.    Originalmente, los contactos se guardarán en la lista en el orden en que fueron agregados. Sin embargo, el usuario podrá solicitar que los contactos sean ordenados alfabéticamente mediante el comando (O)rdenar.
a.    Existen dos criterios de ordenamiento, por nombre(s) y por apellidos. El programa alternará entre uno y otro cada vez que se invoque el comando (O)rdenar.
9.    Para evitar perder los contactos entre una y otra sesiones de utilización del programa, el contenido de la lista se podrá almacenar en el sistema de archivos usando el comando (G)uardar. Este mismo contenido podrá recuperarse en una sesión futura usando el comando (K)argar.

requerimientos de almacenamiento (ra):
1.    Existen dos tipos de almacenamiento, primario y secundario. El almacenamiento primario se refiera a la manera en que se guarda la información en memoria, mientras que el secundario se refiere al almacenamiento persistente (que subsiste después que el programa se ha detenido) en un archivo del sistema de archivos de la computadora.

2.    En memoria, cada contacto se almacena en un tipo de datos complejo llamado Persona. Esta estructura contiene información básica (nombre y apellidos) del individuo, así como otras subestructuras complejas llamadas respectivamente Domicilio y Telefono. Los detalles de cómo están compuestas estas estructuras se encuentran en el archivo cedi/types.h, que se pone a disposición de los alumnos para que todos utilicen el mismo formato.

3.    El archivo donde se realiza el almacenamiento persistente de los contactos tendrá un nombre y ubicación persistente. Su nombre será AGENDA.TDAT, y su ubicación será el directorio raíz del mismo programa.
4.    El archivo AGENDA.TDAT será un archivo de texto con formato definido por el profesor, como se describe a continuación:
a.    La primera línea del archivo deberá contener la siguiente leyenda: “cedi txt data format v0.1” (la versión podrá modificarse, previo aviso del profesor, si el formato sufriera modificaciones debido a problemas no considerados al momento de escribir este documento). Dicha línea deberá constar de por lo menos 32 caracteres, y se agregarán espacios en blanco al final para completar la longitud mínima.

b.    Cada contacto, representado por el tipo de datos Persona, será representado en 3 líneas. Cada línea representa un tipo de datos struct y sus campos de tipo estándar. La primer palabra de cada línea será el nombre del tipo, seguido de dos puntos ‘:’, posteriormente vendrán todos los miembros o atributos de tipo texto o numérico, separados entre ellos por el carácter TABULADOR (‘\t’).
La primera línea contiene los datos de la Persona (nombre, apellido paterno, apellido materno). La segunda línea contiene el Domicilio (calle, número, interior, colonia, código postal, ciudad y estado); mientras que la tercera contiene el teléfono (tipo de teléfono, número local y clave de larga distancia).
c.    Ejemplo, con un solo contacto:
cedi txt data format v0.1   
Persona:        Carlos Ramon    Pati~o  Ruvalcaba
Domicilio:      Av. Falsa      2017    Lomas Lejanas  12345  Guadalajara    JAL
Telefono:      H              33      3568-8722

requerimientos de control (rc):
1.    El programa deberá soportar un comando (V)ersion, que nos informe sobre los cambios que el código ha ido sufriendo a lo largo del tiempo.
Deberán proveerse versiones distintas para el software del programa, y para los datos del programa.
2.    En algún lugar, el alumno debe incluir dos variables de tipo string que almacenen la versión del código y de los datos. Dicha versión cambia cada vez que se efectúe un cambio significativo al programa. Nótese que la expectativa del profesor es que este proyecto es demasiado grande como para que cualquier alumno lo complete en una sola sesión.
Planee su tiempo y su carga de trabajo a lo largo de las próximas semanas para realizar avances lentos pero constantes.
3.    La versión consta de dos números, mayor y menor. Ambos números empiezan en 0, y esto significa que se tiene un proyecto iniciado en Codeblocks, que existe un programa con una función main() vacia, que compila pero que no hace nada. El programa expresará esto de la siguiente manera: v0.0.

4.    La versión mayor cambia a 1 cuando se completen todos los requerimientos funcionales de la primera entrega, y a 2 cuando se complete la totalidad de los requerimientos funcionales.
5.    La versión menor cambia cada vez que se logra hacer un cambio significativo (como completar un requerimiento, o corregir un error que no se había identificado en el primer intento). Idealmente no se le debe asignar versiones a código que no compila.
6.    Como actividad formativa, cada equipo de alumnos deberá llevar una lista de las versiones de su proyecto. Deberán registrar en un documento de Excel: el número de versión, la fecha en que lo completaron, y cuales requerimientos o comandos han logrado hasta ese momento. Por ejemplo: v0.9 – 18/noviembre – Completé el comando Eliminar del RF2.