2. DISEÑO

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

En la unidad anterior vimos las pautas que deben seguirse para descomponer un programa como una serie de clases que se relacionan entre sí. En cambio, para el programa de ejemplo propuesto, una descomposición en clases sería un poco forzada, ya que su nivel de complejidad no es tan elevado.

Aunque, se puede optar por separar la parte visual (aplicación principal) de la parte lógica (lista de personas) de tal manera que se pudiese reutilizar la mayor cantidad posible de código en caso de que se creara otra visual del programa en un entorno gráfico o con otro tipo de interfaz. Para ello, es posible crear una ListaPersonas que se encargue de cargar y guardar datos, permitiendo el acceso a ellos. De este modo, los datos pasarían de ser un struct a ser una clase que tendrían los mismos campos, pero añadiría métodos para obtener y fijar valores de esos campos, así como simplificar las búsquedas.

Diagrama de clases para la agenda

2. DISEÑO

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

Una vez analizados los requisitos que debe cumplir el programa, tenemos que decidir las estructuras básicas que van a emplearse en el programa.
El programa propuesto ( agenda de contactos ) es simple, la fase de diseño en este caso podría reducirse a ver qué estructuras de datos usar y en qué funcionalidades descomponer el cuerpo.
Próximamente se estudiará una versión algo más elaborada.

La estructura de datos del programa podría ser la siguiente :
Struct: lugar donde se almacena cada dato individual para que se puedan guardar tantos datos como desee, los struct individuales se almacenarán en un vector.

Y las funciones en las que se descompondría podrían ser :
-mostrar menú: 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 la primera ficha y al pulsar sobre ciertas teclas se podrá elegir entre consultar la ficha anterior, posterior y modificar la actual o borrarla.
-modificar(n): pide los campos de la ficha que se indica como parámetro, si se desea cambiar un dato se volverá a introducir el texto, por el contrario basta con pulsar intro, para conservarlo todo como estaba.
-intentarBorrar(n): solicita confirmación para borrar datos.Si el usuario acepta borrarlos, la ficha se eliminará de la lista.
-buscarTexto: pide el texto que se desea buscar , cuenta las fichas que lo contienen y las muestra de una en una. Tras mostrar el resumen de la  da la opción de mostrarla detalladamente, continuar consultando otras o volver al menú.
-buscarCumpleMes: muestra las fechas de nacimiento, 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 antes de salir del programa, para que de este modo los datos queden almacenados. Además es posible guardar los datos tras cada modificación.
-cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al inicio del programa.

Datos de cada persona de la agenda

Funciones que componen el programa

ANÁLISIS

1.5. DIAGRAMAS DE CASOS DE USO

El documento de especificación puede parecer incomprensible a un cliente que no tenga conocimientos de programación informática. Por eso, se elaboran diagramas que muestran los principales requisitos del programa de una forma más visual. Uno de los más destacados es el diagrama de casos de uso.

En él, el sistema se representa como un rectángulo, las acciones que pueden realizarse se incluyen dentro de elipses y se dibujan figuras para simbolizar a cada uno de los tipos de personas que pueden interactuar con el sistema para realizar las correspondientes acciones.

Por ejemplo, volviendo al ejemplo anterior de la agenda de contactos, una versión mejorada permitiría incluir al usuario normal, que tendría la capacidad de ver y manipular datos , por otro lado el administrador, podría consultar y añadir datos, además cambiar la contraseña de acceso al sistema.

Diagrama de casos de uso

Diagrama de casos de uso para la agenda de contactos.

ANÁLISIS

1.3. REFINAMIENTO

En las empresas de desarrollo de software suele existir la figura del analista, experto en hablar con el cliente, observar la forma en la que se trabaja y asegurarse de que el proceso de especificación sea lo más correcto.

En cambio, en las empresas pequeñas esta figura no existe y es habitual que los programadores independientes no tengan tanta experiencia a la hora de identificar las necesidades del cliente. Por lo que, una segunda lectura mejora a afinar los detalles inicialmente ambiguos.

Por ejemplo, para el programa de la anterior entrada, podrían detectarse 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 búsquedas de texto deben mostrarse?

- ¿Qué datos de cada persona que cumpla años deben aparecer?

- ¿Los datos se guardarán automáticamente o deberá haber una opción determinada del menú?

- ¿Será necesario guardar los datos en un fichero usando un formato específico?

- ¿No habrá que modificar ni borrar datos?

Por eso, en la realización de un proyecto, es frecuente repetir varias veces la secuencia análisis-diseño-implementación-verificación, incluyendo reuniones con el cliente entre una secuencia y otra para detectar los errores y carencias.

Refinamiento

1.4. PROTOTIPOS VISUALES

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. Esto permite al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. 

Prototipo Visual interactivo.

Prototipo Visual de una empresa

TEMA 7. ANÁLISIS, DESARROLLO Y PRUEBA DE APLICACIONES

ANÁLISIS

Es un proceso incluido en las etapas para desarrollar un proyecto software, el objetivo del análisis es la delimitación de la función del programa.

1.1 CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS

Si se desea crear un programa en un tiempo limitado y con unos costes limitados lo primero que hay que hacer es pensar qué tareas debe realizar. En el caso de para programa  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 aquellas que no se deben realizar. 

Este último aspecto es muy importante en un proyecto a medida, pues evita que el programa crezca indefinidamente por el hecho de que el cliente añada nuevas características cada cierto tiempo.

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

Análisis

       1.2. ESPECIFICACIÓN

Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa. Estos requisitos podrían reflejarse en una lista de cosas que el programa debe hacer. Aunque, es habitual distinguir entre los requisitos funcionales, lo que el programa hará y los requisitos técnicos, las limitaciones físicas.

Un ejemplo para un programa no muy complejo, podría ser la siguiente lista :

- El programa será una agenda de contactos que guardará datos de personas para poder consultarlos más tarde.

- Para cada persona, almacenará sus datos personales, nombres, apellidos, domicilio..., siendo el único obligatorio el nombre.

-  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á crearse en C++ permitiendo así trabajar en modo texto, de forma que se pueda compilar en Windows, LliureX o Linux.

Especificación