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 frzada , 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. 

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. 

• Struct: lugar donde se almacena cada dato individual. 

Y las funciones 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
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se quiere cambiar un dato
• 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. 
• buscarCumplesMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en un cierto mes. 
• guardar: vuelca todos los datos a fichero. 
• cargar: lee todos los datos del fichero. Se debe llamar automáticamente al principio del programa.

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.

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

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

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

Una vez analizados los requisitos que debe cumplir el programa, debemos decidir la estructura que llevará el programa. El programa propuesto de agenda de contactos es un programa simple y la estructura podría ser:
 Cada dato se almacena en un struct para guardar todos los datos deseados, los struct individuales se almacenarán en un vector
Las funciones del programa serían:
mostrar  menú: muestra las opciones disponibles conforme al prototipo ya realizado.
nuevaFicha: pide los datos de una nueva persona  y los añade a la lista.
verFichas: muestra la primera ficha y con las teclas se podrá elegir entre ver la ficha posterior, la interior, modificar la actual o borrarla.
modificar: pide los campos de la ficha, en los parámetros que se desee cambiar se volverá a escribir texto, sino basta con pulsar intro.
intentarBorrar: solicita confirmación para borrar datos, si el usuario la acepta se borrará.
buscarTexto: pide el texto que se desea buscar y muestra las fichas que lo contienen. Al mostrar la ficha resumen da la opción de mostrarla desarrollada, continuar consultando otras o volver al menú.
buscarCumpleMes: muestra fechas, 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 los datos queden almacenados e. También es posible guardar los datos tras cada modificación.

cargar: lee todos los datos del fichero. Se llama automáticamente al comenzar el programa.

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 

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 secuencia y otra con el fin de que los errores y las cadencias se corrijan.

1.4 PROTOTIPOS VISUALES

Una herramienta que puede ser útil para contribuir a la detección de errores o malentendidos en la especificación de requisitos son los prototipos visuales. 

Los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. Ayudan a explicar como se va a relacionar el usuario con el programa.

Refinamiento

Refinamiento

En las empresas de desarrollo de software, suele existir la figura del analista, experto encargado de hablar con el cliente, observar la forma en que este trabaja y formular las preguntas adecuadas para que el proceso de especificación sea lo más correcto posible.

En empresas pequeñas, es posible que no exista la figura del analista y es habitual que los programadores independientes no tengan tanta experiencia a la hora de identificar las necesidades del cliente. En estos casos, una segunda lectura pormenorizada de la especificación puede contribuir a afinar los detalles inicialmente 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?
• ¿Qué datos de cada persona que cumpla años deben mostrarse?
• ¿Los datos se guardarán automáticamente?
• ¿Es necesario guardar los datos en fichero?
• ¿No será necesario modificar ni borrar datos?

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

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 consiste en pensar qué tareas debe realizar. En el caso de una aplicación creada 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 cuáles 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 proyecto a medida, pues permite evitar que el programa crezca indefinidamente por el hecho de que el cliente o usuario desee añadir nuevas características cada cierto tiempo.

Una vez que se ha estimado el tiempo necesario y se ha aprobado el presupuesto del proyecto, las características nuevas que el cliente desee deben anotarse para la realización de una versión posterior del proyecto, lo que conllevará volver a calcular el tiempo y los recursos necesarios para añadirlas.

1.2 Especificación

Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa. En una primera aproximación, estos requisitos podrían reflejarse, sencillamente, en una "lista de cosas que el programa debe hacer". Sin embargo para una aplicación real, es habitual distinguir al menos entre los requisitos funcionales y los requisitos técnicos.

• El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultarlos más adelante.
• Deberá almacenar, para cada persona, el nombre, los apellidos, la fecha de nacimiento, el domicilio y el correo electrónico. El único dato obligatorio será el nombre.
• Permitirá guardar una cantidad elevada de datos.
• Los datos deberán guardarse en fichero para que se pueda disponer de ellos cada vez que se acceda al programa.
• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda.
• Buscará personas que cumplan años en los próximos 30 días.
• El programa deberá haberse creado en C++ y permitirá trabajar en modo texto

TEMA 5 PROGRAMACION ESTRUCTURADA

T.5 PROGRAMACION ESTRUCTURADA 

1.LENGUAJES COMPILADORES E INTERPRETES

1.1 LENGUAJES DE ALTO Y BAJO NIVEL  

UN PROGRAMA; SECUENCIA DE INSTRUCIONES.

UN LENGUAJE DE PROGRAMACION; SE CONOCE COMO ALGORITMO O SECUENCIA DE PASOS PARA RESOLVER UN PROBLEMA 

 EXISTEN 2 TIPOS DE LENGUAJE

ALTO NIVEL: PARECIDO AL CODIGO MAQUINA (CEROS Y UNOS) , DIFICIL DE ENTENDER 

BAJO NIVEL: PARECIDO AL DE LOS HUMANOS , FACIL DE ENTENDER 

1.2 COMPILADORES E INTERPRETES

COMPILADORES; SON LAS HERRAMEINTAS ENCARGADAS DE CONVERTIR NUESTRO PROGRAMA ESCRITO EN LENGUAJE DE ALTO NIVEL 8PROGRAMA DE FUENTE) A CODIGO MAQUINA A TRAVES DEL CUAL SE OBTIENE UN RPGRAMA EJECUTABLE 

INTERPRETE: ES OTRO TIPO DE TRADUCTOR , PERO ESTOS NO CREAN NINGUN PROGRAMA EJECUTABLE CAPAZ DE FUNCIONAR POR SI MISMO 

POR LO TANTO , UN RPGRAMA INTERPRETADO COMENZARA A FUNCIONAR ANTES QUE UN RPGRAMA COMPILADO (PUES NO ES NECESERIO TRADUCIR TODO EL PRGRAMA PARA EMPEZAR) PUES SERA MAS LENTO EN LOS PRGRAMAS DE CALCULO INTENSIVO (PORQUE CADA ORDEN SE TIENE QUE TRADUCIR TANTAS VECES COMO SE EJECUTE.

1.3 PSEUCODIGO

A PESAR DE LOS LENGUAJES DE ALTO NIVEL SE ASEMEJAN AL LENGUAJE NATURAL QUE LOS SERES HUMANOS EMPLEAMOS PARA HABLAR , ES HABITUAL NO UTILIZAR NINGUN LENGUAJE DE PROGRAMACION CONCRETO CUANDO QUEREMOS PLANTEAR INICIALMENTE PARA RESOLVER UN PRGRAMA SINO EMPLEAR UN LENGUAJE DE PROGRAMACION FICTICIO , NO TAN ESCRITO Y A VECES ESCRITO EN LENGUA CASTELLANA , ESTE LENGUAJE RECIBE EL CODIGO DE PSEUCODIGO  

EJ: 

PEDIR NUMERO 1 

PEDIR NUMERO 2 

SI NUMERO <> 0 

     ESCRIBIR " SU DIVISION ES  " NUMERO1/NUMERO2 

SI NO ESCRIBIR "NO SE PUEDE DIVIDIR ENTRE 0"