Entradas

DIAGRAMAS DE CASOS DE USO

Imagen
DIAGRAMAS DE CASOS DE USO El documento de especificación puede parecer incomprensible a un cliente que no tenga conocimientos de programación informática. Por eso, se elaboran diagramas que muestran los principales requisitos del programa de una forma más visual. Uno de los más destacados es el diagrama de casos de uso. En él, 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. Por ejemplo, volviendo al ejemplo anterior de la agenda de contactos, una versión mejorada permitiría incluir al usuario normal, que tendría la capacidad de ver y manipular datos , por otro lado el administrador, podría consultar y añadir datos, además cambiar la contraseña de acceso al sistema. Diagrama de casos de uso Ejercicio 1 . Elaborar un diagrama de casos de uso de una bibliote

CREACIÓN DE CLASES A PARTIR DE ANÁLISIS

Imagen
CREACIÓN DE CLASES A PARTIR DE ANÁLISIS En el tema anterior vimos las pautas de seguir para descomponer un programa como una serie de clases que se relacionan entre sí. Sin embargo, para el programa de la agenda una descomposición en clases sería muy forzada debido a la poca complejidad del programa. Pero se puede optar por separar la parte visual (aplicación principal) y la parte lógica (lista de personas) para reutilizar la mayor cantidad posible de código por si se creara otra versión del programa en el entorno gráfico o con otra interfaz. Para ello es posible crear una clase lista de personas que cargue y guarde datos permitiendo el acceso a ellos. Así los datos pasarían de se un struct a una clase con los mismos campos pero con métodos que permitieran obtener y fijar los valores de los campos al igual que simplificar la búsqueda. Ejercicio 1. Ejercicio 2.

DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS

Imagen
DECISIÓN DE TAREAS A PARTIR DEL ANÁLISIS Una vez realizados todos los requisitos tenemos que decidir las estructuras básicas que se van a emplear. El programa propuesto es simple y podría realizarse en pocas horas, de modo que la fase de diseño podría reducirse a decidir qué estructuras usar. Después se estudiará una versión más elaborada del programa, planteándolo como una serie de objetos que colaboran entre ellos. La estructura de datos del programa podría ser: Cada dato se almacena en un  struct , y cada struct se almacenará en un  vector . Y las funciones en las que se descompondría podrían ser estas: mostrarMenu : muestra la lista de opciones disponibles. nuevaFicha : pide los datos de una nueva persona y los añade a la lista. verFichas : muestra la primera ficha. Al pulsar sobre algunas teclas el usuario puede elegir si consultar la ficha anterior, modificar la actual o elegir otra. modificar(n) : pide los campos de la ficha que se indique como parámetro. Si se d

ANÁLISIS 2ºPARTE

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 secuen

TEMA 7(COMIENZO)

Imagen
ANÁLISIS Características del análisis de requisitos Para crear un programa en un tiempo limitado y con unos costes limitados, el primer paso consiste en pensar que tareas debe realizar. 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 cuales 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 programa a medida, evita que crezca de indefinidamente por el hecho del que el cliente añada nuevas características. Una vez estimado el tiempo necesario y el presupuesto, las características nuevas que el cliente desee deben anotarse para su realización de una versión posterior del proyecto. Especificación Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa. Estos requisitos pueden reflejarse en una lista de cosas que

TEMA 5. PROGRAMACIÓN ESTRUCTURADA

TEMA 5. PROGRAMACIÓN ESTRUCTURADA 1. Lenguajes de bajo nivel y de alto nivel Un programa es una secuencia de instrucciones para un ordenador.   Un lenguaje de programación se conoce como algoritmo o secuencia de pasos para resolver un problema. Existen dos tipos de lenguaje: Bajo nivel: parecido al código máquina (ceros y unos), difícil de entender. Alto nivel: lenguaje parecido al de los humanos, fácil de entrender. 2. Complicadores e intérpretes Los compiladores son las herramientas encargadas de convertir nuestro programa escrito en lenguaje de alto nivel (progrma fuerte) a código máquina, a través de lo cual se obtiene un programa ejecutable. El 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 progrma interpretado comenzará a funcionar antes que un programa compilado, pues no es necesario traducir todo el progrma para empezar, pero será más lento en los programas de cálculo intensico ( por

ESQUEMA RESUMEN UNIDAD 4

ESQUEMA RESUMEN UNIDAD 4 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 Amenazas humanas: Ataques pasivos: usuarios con conocimientos básicos y hackers Ataques activos: antiguos empleados de una organización y crackers y otros atacantes. Amenazas lógicas software maliciosos vulnerabilidad del software  Amenazas físicas fallos en los dispositivos accidentes catástrofes naturales Conductas de seguridad Seguridad activa: control de acceso, encriptación, software de seguridad informática, firmas y certificados digitales y protoclos seguros. Seguridad pasiva: herramientas de limpieza, copias de seguridad, sistemas de alimentación ininterrumpida, dispositivos NAS y sistemas redundantes. 3. Malware (no definición) Tipos de malware: virus, gusano, troyano, spyware, adware, ransomware, rogue y roo