UD 7. CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

2.2 CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

En la unidad anterior, se estudiaron las pautas básicas que deben seguirse para descomponer un programa real como una serie de clases que se relacionan entre sí. Para el programa de ejemplo propuesto, una descomposición en clases quedaría un poco forzada, ya que su nivel de complejidad no es tan elevado para justificarla.

Aún así, se podría optar por separar la parte visual (la aplicación principal) de la parte lógica (la lista de personas), de modo que se pudiera realizar 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 (Windows Forms o Qt, por ejemplo) 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.

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, el siguiente paso consiste en decidir las estructuras básicas que van a emplear para llevarlo a cabo.

El programa propuesto (la agenda de contactos) es simple; podrías 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á na versión algo más elaborada del programa, en la que se plantea como una serie de objetos que colabora entre ellos, con la ayuda de un diagrama de clases.

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.

Las funciones en las que se descompondría serían las siguientes:

• mostrarMenu: muestra la lista de opciones disponibles conforme al prototipo visual.
• nuevaFicha: pide 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 función).
• modificar(n): pide los campos de la ficha que se indique como parámetro. En caso de que se desee cambiar un dato, se deberá volver a introducir el texto de los campos que se quieran modificar. Si, por el contrario, no se desea cambiar algún dato, bastará con pulsar intro para conservarlo como estaba.
• 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 consultarla con mayor detalle, contiene (mostrando la siguiente, si existe) o volver al menú. Si no existe una siguiente ficha, la opción Continuar no aparecerá.
• buscarCumpleMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen años en un cierto mes. En caso de haber más de una veinte datos, el programa efectuará una pausa cada veinte datos y esperará a que el usuario pulse intro. En esta primera versión, no es necesario que los datos aparezcan ordenados por fecha.
• 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 el fichero. Se debe llamar automáticamente al principio del programa.

UD 7. Análisis (3)

1.5 DIAGRAMAS DE CASOS DE USO

Un documento de especificación puede resultarle 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 planas para simbolizar a cada uno de los tipos de personas (las cuales reciben el nombre de "actores") que pueden interactuar con el sistema para realizar las correspondientes acciones.

Por ejemplo, una versión mejorada del programa de la agenda de contactos podía incluir al usuario normal, que tendría la capacidad de ver y manipular datos, pero también el de un administrador, que podría consultar y añadir datos, así como cambiar la contraseña de acceso al sistema (que la primera versión de la agenda todavía no incluye). Así el diagrama quedaría de la siguiente manera:

UD. 7 Análisis (2)

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 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. Estos consisten en la creación de maquetas de pantalla con las que se muestre al cliente una idea aproximada de como va a ser el resultado a nivel visual.

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.

UD 7. 1 Análisis (1)

1.1 CARACTERÍSTICAS DEL ANÁLISIS DE REQUISITOS

Para crear un programa en un tiempo limitado y con costes limitados, lo primero que hay que hacer es pensar de forma rigurosa las tareas que queremos que realice, este paso adquiere mucha importancia en caso de que sea un programa pedido por encargo.

Podemos crear un lista de los requisitos que debe cumplir el programa para orientarnos mejor, también hay que establecer que tareas son las mas importantes y cuales no hay que hacer. También es muy importante establecer el momento en el que el proyecto se daría por acabado.

Cuando ya se haya calculado el tiempo necesario y se haya aprobado el presupuesto del proyecto, deben anotarse las características nuevas que desea el cliente ya que será más fácil usarlas para versiones posteriores del proyecto.

1.2 ESPECIFICACIÓN

Es aconsejable crear un documento en el que se recojan los requisitos que debe cumplir el programa. Que en principio simplemente sería una lista de las cosas que queremos que el programa haga, pero posteriormente hay que diferenciar entre los requisitos funcionales y los técnicos.

Un ejemplo de lista que sería bueno hacerla es la siguiente:

• El programa será una agenda de contactos que permitirá guardar datos de personas para poder consultarlos más tarde.
• Deberá almacenar el nombre, los apellidos, la fecha de nacimiento, el domicilio y el correo electrónico de cada persona. Lo único obligatorio será el nombre, lo demás es opcional.
• Que permita guardar una gran cantidad de datos.
• Los datos se deben almacenarse en un fichero para tener acceso a ellos cada vez que se acceda al programa.
• Permitirá buscar datos a partir de cualquier palabra introducida en la búsqueda.
• Buscará a las personas que cumplan años en los próximos 30 días.
• El programa  debe ser 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.

Esquema resumen de la UD 4

1. SEGURIDAD DE LA INFORMACIÓN

1. Confidencialidad
2. Integridad
3. Disponibilidad
4. Autentificación
5. Autorización
6. Cifrado
7. No repudio
8. Vulnerabilidad
9. Seguridad de la información

2. AMENAZAS A LA SEGURIDAD

1. Humanas:
• Ataques pasivos (Usuarios con conocimientos básicos o hackers)
• Ataques activos (Antiguos empleados de una organización y crakcers y otros atacantes)
2. Lógicas:
• Software malicioso
• Vulnerabilidades del software
3. Físicas:
• Fallos en los dispositivos
• Accidentes
• Catástrofes naturales.
4. Conductas de seguridad:
• Activas: (...)
• Pasivas: (...)

3. MALWARE

1. Tipos:
• Virus, gusano, troyano, spyware, adware, ransomewere, rogue, rootkit.
2. Otros tipos:
• Phishing, pharming, spam, hoak.

4. ATAQUES A LOS SISTEMAS INFORMÁTICOS

1. Tipos:
• Interrupción, interceptación, modificación, suplantación o fabricación.
2. Ingeniería social
3. Ataques remotos: (...)

5. PROTECCIÓN CONTRA EL MALWARE

1. Políticas de seguridad
2. Antivirus

6. CIFRADO DE LA INFORMACIÓN

1. Criptografía, criptología y criptoanálisis.
2. Tipos de cripografía:
• Simétrica
• Asimétrica
• Pública

7. FIRMA ELECTRÓNICA Y CERTIFICADO DIGITAL.

1. Firma electrónica
2. Certificado digital
3. Autoridades de certificación

8. NAVEGACIÓN SEGURA

1. Buenas prácticas de navegación
2. Navegación privada
3. Navegación anónima
4. Servidores proxy

9. PRIVACIDAD DE LA INFORMACIÓN

1. Amenazas a la privacidad
2. Antiespías

10. PROTECCIÓN DE LAS CONEXIONES EN RED

1. Cortafuegos
2. Red privada virtual (VPN)
3. Certificados SSL/TLS de servidor web y HTTPS

Seguridad en las comunicaciones inalámbricas

SEGURIDAD EN LAS COMUNICACIONES INALÁMBRICAS

REDES INALÁMBRICAS

Son redes que comparten información sin cable, las más utilizadas son: Bluetooth y Wifi.

SEGURIDAD EN BLUETOOTH

Blutooth es un estándar global de comunicaciones inalámbricas para redes de área personal y permite la transmisión de voz y de datos entre diferentes equipos por medio de un enlace de radio frecuencia en entornos de comunicación móviles. Tiene un alcance de unos 10 metros. Algunos ataques que se pueden realizar mediante Bluetooth son:

• Bluejacking: envío de spam al usuario por medio del intercambio con este de una vCard, de una nota o un contacto en cuyo nombre aparezca el mensaje de spam. Algún ejemplo de spam es: "OBTÉN CUPONES DE DESCUENTO EN www.paginaweb.com".
• Bluenarfing: aprovecha las vulnerabilidades del protocolo para sustraer información del dispositivo atacado.
• Bluebugging: usa técnicas de ingeniería social para que la víctima acepte una conexión inicial para infectar el dispositivo con malware de control remoto.

SEGURIDAD EN WIFI

Las redes wifi utilizan una tecnología inalámbrica que realiza la conexión entre dispositivos móviles situados en un área relativamente pequeña, como una habitación, una oficina, una casa o un edificio, a través de ondas electromagnéticas. tiene un alcance de unos 100 metros. Algunas de las medidas que podemos seguir para mantener una red wifi segura son:

• Personalizar la contraseña de acceso.
• Cambiar el SSID: es el nombre del wifi, es aconsejable cambiarlo para que no muestre datos personales.
• Revisar el cifrado.
• Desactivar el acceso por WPS.
• Filtrar las MAC
• Actualizar el firmware.
• Comprobar el hisotiral de actividad.
• Usa software de auditoría.