Buscar este blog

sábado, 25 de abril de 2020

Diagramas de casos de uso

Un documento de especificación puede resultar 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. Uno de los más habituales es el diagrama de casos de uso.
En los diagramas de casos de uso, 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.



Creación de clases a partir de análisis

Se podría optar por separar la parte visual de la parte lógica, de modo que se pudiera reutilizar la mayor cantidad posible 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 se encargue de cargar y guardar datos, así como de permitir el acceso a los mismos. De esta manera, los datos de cada persona pasarían de ser un struct a ser una clase que tendría los mismos campos, pero añadiría métodos que permitieran obtener y fijar los valores de esos campos, así como simplificar las búsquedas.

viernes, 24 de abril de 2020

Decisión de tareas a partir de análisis

Una vez analizados los requisitos que debe cumplir el programa, el siguiente paso consiste en decidir las estructuras básicas que van a emplearse para llevarlo a cabo.
El programa propuesto es simple: podría ser realizado en pocas horas por un programador experto de modo que la fase de diseño en este caso podría reducirse a decidir que estructuras de datos usar y en que funciones descomponer el cuerpo del programa.
Más adelante se estudiará una versión algo más elaborada del programa, en la que este se plantea como una serie de objetos que colaboran entre ellos, con la ayuda de un diagrama de clases.
La estructura de datos del programa podría ser la siente:
  • Cada dato individual se almacena en un struct. Los struct individuales se almacenarán en un vector.
Y las funciones en las que se descompondría:
  • mostrarMenu.
  • nuevaFicha.
  • verFichas.
  • modificar(n).
  • intentarBorrar(n).
  • buscarTexto.
  • buscarCumplesMes.
  • guardar.
  • cargar.

viernes, 17 de abril de 2020

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. Esos 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.
Así, los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. Por ejemplo, para la agenda de contactos, los ejemplos podrían constituir prototipos visuales de la pantalla de menú, de visualización de datos y de visualización de un resultado de búsqueda.

Prototipo de pantalla de menú

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.
Por ejemplo, para un programa no muy complejo, se podría partir de una lista como la siguiente:

  • 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.




lunes, 10 de febrero de 2020

Tema 5. Programación Estructurada

1. Lenguajes, complicadores e integrales.

1.1 Lenguajes de bajo nivel y de alto nivel.
Un programa > secuencia de instrucciones
Un lenguaje de programación > se conoce algoritmo o secuencia de pasos para resolver un problema.
Dos tipos de lenguaje de programación:
  • Bajo nivel: parecido al código máquina (cerosy uno), difícil de entender.
  • Alto nivel: lenguaje parecido al de los humanos, fácil de entender.

1.2 Compiladores e intérpretes.
Compiladores > son las herramientas encargadas de convertir nuestro programa estricto en lenguaje de alto nivel (=programa fuerte) a código máquina, a través de lo cual se obtiene un programa ejecutable.
Intérprete > es otro tipo de traductor, pero estos no crean ningún programa ejecutable capaz de funcionar por sí mismo.
Por lo tanto, un programa interpretado comenzará a funcionar antes que un programa compilado (pues no es necesario traducir todo el programa para empezar), pero será más lento en los programas de cálculo intensivo (porque cada orden se tiene que traducir tantas veces como se ejecute).

1.3 Pseudocódigo.
A pesar de que los lenguajes de alto nivel se asemejan al lenguaje natural que los seres humanos empleados para hablar, es habitual no usar ningún lenguaje de programación concreto cuando queremos plantear inicialmente los pasos necesarios para resolver un problema, sino emplear un lenguaje de programación ficticio, no tan estricto, en muchos casos escrito incluso en lengua castellana.Este lenguaje recibe el nombre de pseudocódigo.
Ej. Pedir número 1
     Pedir número 2
     Si número= 0
         Escribir "Su división es", Número 1 / Número 2
     Si no
         Escribir "No se puede dividir entre cero"