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

2.2 Creación de clases a partir de análisis.
Ya hemos estudiado las pautas básicas que deben seguirse para descomponer un programa real como una serie de clases que se relacionen entre sí. Para el programa propuesto, una descomposición de clases quedaría un poco forzada.
Aún así, se podría separar la parte visual de la parte lógica, de modo que se pudiera utilizar la mayor cantidad de código en caso de que más adelante se creara otra versión del programa en un entorno gráfico o con cualquier otro tipo de interfaz. Para ello, es posible crear una clase listaPersonas, que cargue y guarde datos, y permita su acceso. Por lo tanto, los datos de cada persona pasarían de ser un struct a ser una clase que tendría los mismos campos.

Ejercicio 1.

Ejercicio 2.

2.Diseño.

2.1 Decisión de tareas a partir del análisis.
Una vez realizados los requisitos que debe cumplir el programa, el siguiente paso consiste es decidir las estructuras básicas que van a emplearse.
El programa propuesto es simple, podría ser realizado es pocas horas, de modo que la fase de diseño podría reducirse a qué estructuras de datos usar y en qué funciones descomponer el cuerpo del programa.
Más adelante, se planteará el programa como una serie de objetos que colaboran entre ellos, con la ayuda de un diagrama de clases.

La estructura de datos podría ser la siguiente:

• Cada dato individual se almacena en un struct, y para que se puedan almacenar todos los datos que se desean, los structs se almacenan en un vector.

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

• mostarMenu: muestra la lista de opciones disponibles.
• nuevaFicha: pide los datos de una nueva persona.
• verFichas: muestra en pantalla la primera ficha. Al pulsar sobre ciertas teclas, el usuario podrá consultar la ficha anterior, posterior, modificar la actual...
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si no se desea cambiar algún datos, bastará con pulsar Intro para conservarlo como está.
• buscarTexto: pide al usuario el texto que desea buscar y muestra las fichas de una en una. Si no existe una siguiente ficha, la opción de continuar desaparece.
• buscarCumpleMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en cierto mes. 
• guardar: vuelca todos los datos a un fichero, reemplazando el contenido anterior de dicho fichero. También es posible guardar los datos tras cada modificación, siempre que el contenido del fichero esté actualizado. 
• cargar: lee todos los datos desde fichero. 

Diagramas de casos de uso.

1.5 Diagrama de casos de uso.
Un documento de especificación puede resultarle incomprensible 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. Destacamos el diagrama de casos de uso.
En estos diagramas, el sistema se representa como in rectángulo, y se dibujan figuras para simbolizar 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 programa de la agenda de contactos podría incluir al usuario normal, pero también al administrador. Otra versión mejorada del programa de restaurante podría incluir al chef y a un crítico de comidas, quedaría así:

Ejercicio 1. Elaborar un diagrama de casos de uso de una biblioteca.

Ejercicio 2. Elaborar dos diagramas de casos de uso de como gestionar una colección de música.

 

Continuación del P.1

1.3 Refinamiento. 
En las empresas de desarrollo de software, suele existir un analista, experto encargado de hablar con el cliente. También formula las preguntas adecuadas para que el proceso de refinamiento sea el más correcto posible.
En empresas pequeñas es posible que no exista, por lo tanto es habitual que los programadores independientes no identifiquen las necesidades de los clientes. En estos casos, una segunda lectura pormenorizada puede contribuir a afinar detalles. Por ejemplo, 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 cumpla años deben mostrarse?
• ¿Los datos se guardarán automáticamente?
• ¿Es necesario guardar los datos en un fichero?
• ¿No será necesario modificar ni borrar datos? Etc...

Así es la realización de un proyecto real. es cada vez mas habitual repetir varias veces la secuencia análisis-diseño-implementación-verificación, proceso con el fin de que los errores y las carencias del programa puedan ser detectadas cuanto antes.

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 aproxima 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.Por ejemplo, para la agenda contactos, pueden contribuir prototipos visuales de pantalla de menú , de visualización de datos...

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 .

U6. Análisis

                                                      1-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 es pensar qué tareas debe realizar. En un programa realizado para uso propio, este detalle tiene poca importancia, pero si es por encargo se convierte en un detalle 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 cuáles no deben realizarse. Este último aspecto es muy importante en un programa a medida, evita que crezca de indefinidamente por el hecho del que el cliente añada nuevas características.
Una vez estimado el tiempo necesario y el presupuesto, las características nuevas que el cliente desee deben anotarse para su 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. Estos requisitos pueden reflejarse en una lista de cosas que el programa debe hacer. Sin embargo es habitual distinguir entre los requisitos funcionales (lo que hará) y los técnicos (limitaciones físicas).
Para un programa no muy complicado se puede partir de la siguiente lista:

• El programa será una agenda de contactos que guardará datos y se podrán consultar posteriormente.
• Deberá almacenar los datos personales de cada persona (nombre, apellidos, domicilio...), siendo el nombre el único dato obligatorio.
• Permitirá guardar una elevada cantidad de datos. 
• Los datos deberán guardarse en fichero para poder acceder a ellos cunado sea necesario.
• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda.
• Buscará las personas que cumplan años en los próximos treinta días.
• El programa deberá haberse creado en C++ y permitirá trabajar en modo texto, de forma que se pueda compilar en Windows, LliureX o Linux.