Entradas

2.2 Creación de clases a partir de análisis Una descomposición en clases quedaría un poco "forzada", ya que su nivel de complejidad no es tan elevado. 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. Es posibles, crear una clase que se encargue de cargar y guardar datos.   
2.1 Decisión de tareas a partir del análisis Cuando analices los requisitos que el programa debe cumplir, el siguiente paso consiste en decidir las estructuras básicas que deben emplearse para llevarlo a cabo. El programa podría ser realizado en unas horas por un programador experto, en este caso podría reducirse a decidir qué estructuras de datos usar y en qué funciones descomponer el cuerpo del programa. Más adelante, se estudiará una versión más elaborada del programa, en la que se plantea como una serie de objetos que colaboran entre ellos. La estructura será la siguiente:  Cada dato individual se almacena en un struct . Éstos se almacenan en un vector . Las funciones en las que se descompondrían serían las siguientes:   mostrarMenu: 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 en la pantalla la primera ficha. Al pulsar
1.5 Diagramas de casos de uso Es frecuente elaborar diagramas que muestren los principales requisitos del programa de una forma más visual y uno de los más habituales es el diagrama de casos de uso. En estos diagramas, el sistema se representa como un rectángulo, las acciones que pueden realizarse se incluyen dentro de los 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, una versión mejorada del programa de la agenda de contactos podría incluir al usuario normal, que puede consultar y añadir datos, así como cambiar la contraseña de acceso al sistema.   
1.3 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 la que se 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. 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? ¿Se debe hacer una pausa tras la inserción de n datos o de cada dato? ¿Las búsquedas deben distinguir entre mayúsculas y minúsculas? ¿Qué datos de cada persona que cumpla años deben mostrarse? ¿Los datos se guardarán automáticamente o de
TEMA 7 1.1 Características del análisis de requisitos Si se desea crear un programa en un tiempo limitado y con costes limitados el primer paso consiste en pensar, qué tareas debes realizar. En caso de una aplicación creada por encargo, éste 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. Este último e aspecto es muy importante en un proyecto a medida, permite evitar que el programa crezca indefinidamente por el hecho de que el cliente desee añadir 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 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

UD5 Programación Estructurada

1. Lenguajes, compiladores e intérpretes 1.1.   Lenguajes de bajo nivel y de alto nivel Un programa. Secuencia de instrucciones. Un lenguaje de programación.  Se conoce como algoritmo o secuencia de pasos para resolver un problema. Dos tipos de lenguaje de programación: Bajo nivel.  Parecido al código máquina (ceros y unos), difícil de entender. Alto nivel. Lenguaje parecidos al de los humanos, fácil de entender.  1.2. Copiladores e intérpretes Copiladores. Son las herramientas encargadas de convertir nuestro programa escrito en lenguaje de alto nivel (=programa fuente) a código máquina, a través de lo cual se obtiene un programa ejecutable. Intérprete.  Es otro tipo de traductor, pero éstos 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 d

Esquema Resumen UD4

1. La Seguridad de la Información - Confidencialidad                       - Autorización                       - Seguridad de la Información - Integridad                                 - Cifrado - Disponibilidad                           - No Repudio - Autentificación                          - Vulnerabilidad 2. Amenazas a la seguridad Humanas.  - Ataques Pasivos: Hay dos tipos, Usuarios con conocimientos y Hacker - Ataques Activos: Hay dos tipos, Antiguos empleados de una organización, Crackers y   otros atacantes Lógicas. - Software malicioso - Vulnerabilidades del Software Físicas. - Fallos en los dispositivos - Accidentes - Catástrofes Naturales Conductas de Seguridad:  -Activa  -Pasiva 3. Malware Tipos:                                                            Otros tipos:               - Virus                                                           - Phishing - Gusano