Diseño

2.2 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 "forzada", ya que su nivel de complejidad no es tan elevado como para justificarla.
Se puede optar por separar la parte visual de la parte lógica de modo que se pueda reutilizar la mayor cantidad de posible de código en caso de que más adelante se creara otra versión del programa del entorno gráfico. Para ello, se puede crear una ListaPersonas que cargue datos, los guarde y permita el acceso a los mismos. Así, 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 y simplificar las búsquedas. 

Análisis

1.5- Diagramas de caso de uso

Un documento de especificación puede ser incomprensible para un cliente que no posea  conocimientos de programación informática. Por este motivo, se suelen elaborar diagramas con un contenido más visual y así facilitar la tarea al cliente
Uno de los más habituales es el diagrama de casos de uso. En estos, el sistema se representa como un rectángulo, las acciones se incluyen dentro de elipses y se dibujan figuras para simbolizar a diferentes tipos de personas que pueden interactuar con el sistema para realizar las correspondientes acciones.
Por ejemplo, una versión mejorada del programa podría incluir al usuario normal, que tendría la capacidad de ver y manipular datos; también podría incluir a un administrador, que éste podría consultar y añadir datos. El diagrama quedaría de la siguiente manera:

Diseño

2.1. Decisión de tareas a partir del 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.

La estructura de datos del programa podría ser la siguiente:

• Cada dato individual se almacena en un struct. Para que se puedan guardar tantos datos como se desee, los struct individuales se almacenaran en un vector

Y las funciones en las que se descompondria podrian ser estas:

-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 pantalla la primera ficha. Al pulsar sobre ciertas teclas, 

el usuario podrá elegir entre consultar la ficha anterior (si existe), la posterior 

(si existe),modificar la actual (llamando a una función adicional) o borrar la actual

llamando a otra funcion).

-modificar(n): pide los campos de la ficha que se indique como parámetro.

-intentarBorrar(n): solicita confirmación para borrar datos. Si el usuario confirma 

que desea borrarlos, la ficha se eliminará de la lista.

-buscarTexto: pide al usuario el texto que desea buscar, cuenta cuántas fichas lo 

contienen y, finalmente, las muestra de una en una. Tras mostrar el resumen de 

una ficha, da la opción de consultar con mayor detalle, 

-buscarCumpleMes: 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, reemplazando el contenido anterior de

 dicho fichero. Se debe llamar automáticamente antes de salir del programa, de 

modo que los datos queden almacenados para la siguiente sesión. También es

 posible guardar los datos tras cada modificación, de manera que el contenido 

del fichero siempre esté actualizado.

-cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al 

principio del programa.

Análisis

1.3. Refinamiento

En las empresas de desarrollo de software, suele existir la figura del analista, experto encargado  de 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 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? ¿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 deberá seleccionarse, para ello, una opción determinada del menú?
• ¿Es necesario guardar los datos en fichero usando algún formato especifico o no van a compartir con ninguna otra aplicación?
• ¿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 con el fin de que los errores y las carencias del programa puedan ser detectadas cuanto antes. En un proyecto de varios meses de duración, es habitual que se concierten reuniones cada dos semanas para evitar tener que dar costosos pasos atrás.

1.4. 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. Estos 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. 

En los ejemplos de abajo, se puede observar que los prototipos pueden dar una idea tanto de los textos que aparecen en pantalla como de la forma en la que el usuario interactúa con el programa. Así, el usuario podría descubrir problemas de usabilidad del programa.

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, de la forma más rigurosa posible, qué tareas debe realizar. En un programa realizado para uso propio, este detalle puede parecer de poca importancia, pero 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 programa crezca indefinidamente .

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.

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, en una «lista de cosas que el programa debe hacer». Sin embargo, para una aplicación real, es habitual distinguir al menos entre los requisitios 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 consultar los más adelante.

• Deberá almacenar, para cada persona, el nombre, los apellidos, la fecha de na cimiento, el domicilio y el correo electrónico. El único dato obligatorio será el nombre; el resto de datos son opcionales,

• Permitirá guardar una cantidad elevada de datos (es decir, no deberá estar limitado a cincuenta o cien 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.

• El programa deberá haberse creado en C++ y permitirá trabajar en modo texto, de forma que se pueda compilar tanto para Windows como para LliureX o para cualquier otra versión de Linux.

Programación estructurada

1.-Lenguajes, compiladores e intérpretes

• 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.
Hay dos tipos de lenguaje de programación:
- Bajo nivel: parecido al código máquina (ceros y ceros) difícil de entender.
- Alto nivel: lenguaje parecido al de los humanos fácil de entender

• Compiladores e intérpretes

-Compiladores: 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érpretes: son otro tipo de traductor, pero éstos no crean ningún programa ejecutable capaz de funcionar por sí mismo.
i
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 intenso (porque cada orden se tiene que traducir tantas veces como se ejecute).

• Pseudocódigo

A pesar de quje los lenguajes de alto nivel se asemejan al lenguaje natural que los seres humanos empleamos 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 escrito , en muchos casos escrito incluso en lenguaje castellano. Este lenjuage recibe el nombre de pseudocódigo.
 

EJ: PEDIR numero1
      PEDIR numero2
     SI numero <>0
                Escribir "Su desición es", número1/número2
     Si  NO
                Escribir "No se puede dividir entre cero"

Esquema resumen ud4

1. La seguridad de la información

-Confidencialidad 
-Integridad
-Disponibilidad
-Autentificación
-Autorización
-Cifrado
-No repudio
-Vulnerabilidad 
-Seguridad de la información



2. Amenazas a la seguridad

Humanos

-Ataques pasivos:
-Usuarios con conocimientos básicos.
-Hockers.
 
-Ataques activos:  
-Antiguos empleados de una organización
-Crackers y otros atacantes.

Lógicos  

-Software malicioso

-Vulnerabilidad del software.

Físicas

-Fallos en los dispositivos.
-Accidentes
-Catástrofes naturales.

Conductas de seguridad 

-Activa: ejemplo 

-Pasiva: ejemplo

 3. MALWARE.

Tipos:
-Virus
-Gusano
-Troyano
-Spyware
-Adware
-Ransomware
-Rogue
-Rookit 

Otros tipos: 
-Phishining
-Oharming
-Spam
-Hoax

4. ATAQUES A LOS SISTEMAS INFORMÁTICOS.

Tipos:
-Interrupción
-Intercepción
-Modificación
-Suplantación

5. PROTECCIÓN CONTRA EL MALWARE.

-Políticas de seguridad
-Antivirus

6. CIFRADO DE LA INFORMACIÓN.

Criptografía, criptología, criptoanálisis

Tipos de criptografía:
-SImetría
-Asimetría
-Pública

7. FIRMA ELECTRÓNICA Y CERTIFICADO DIGITAL.

-Firma electrónica
-Certificadi digital
-Autoridades de certificación

8. NAVEGACIÓN SEGURA.

-Buenas prácticas de navegación
-Navegación privada
-N. Anónima
-N. Proxy

9. PRIVACIDAD DE LA INFORMACIÓN

-Amenazas a la privacidad
-Antiespías 

10. PROTECCIÓN DE LAS CONEXIONES EN RED 

-Cortafuegos
-Red Privada Virtual (VPN)
-Certificados SSL/TLS de servidor web y HTTPS.