Diego Rubio

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 Ejercicio 1 . Elaborar un diagrama de casos de uso de una bibliote

CREACIÓN DE CLASES A PARTIR DE ANÁLISIS En el tema anterior vimos las pautas de seguir para descomponer un programa como una serie de clases que se relacionan entre sí. Sin embargo, para el programa de la agenda una descomposición en clases sería muy forzada debido a la poca complejidad del programa. Pero se puede optar por separar la parte visual (aplicación principal) y la parte lógica (lista de personas) para reutilizar la mayor cantidad posible de código por si se creara otra versión del programa en el entorno gráfico o con otra interfaz. Para ello es posible crear una clase lista de personas que cargue y guarde datos permitiendo el acceso a ellos. Así los datos pasarían de se un struct a una clase con los mismos campos pero con métodos que permitieran obtener y fijar los valores de los campos al igual que simplificar la búsqueda. Ejercicio 1. Ejercicio 2.

DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS Una vez realizados todos los requisitos tenemos que decidir las estructuras básicas que se van a emplear. El programa propuesto es simple y podría realizarse en pocas horas, de modo que la fase de diseño podría reducirse a decidir qué estructuras usar. Después se estudiará una versión más elaborada del programa, planteándolo como una serie de objetos que colaboran entre ellos. La estructura de datos del programa podría ser: Cada dato se almacena en un  struct , y cada struct se almacenará en un  vector . Y las funciones en las que se descompondría podrían ser estas: mostrarMenu : muestra la lista de opciones disponibles. nuevaFicha : pide los datos de una nueva persona y los añade a la lista. verFichas : muestra la primera ficha. Al pulsar sobre algunas teclas el usuario puede elegir si consultar la ficha anterior, modificar la actual o elegir otra. modificar(n) : pide los campos de la ficha que se indique como parámetro. Si se d

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 secuen

ANÁLISIS Características del análisis de requisitos Para crear un programa en un tiempo limitado y con unos costes limitados, el primer paso consiste en pensar que tareas debe realizar. 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 cuales no deben hacerse, así como el establecimiento del momento en el que el proyecto se podrá dar por terminado. 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. 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