Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007.Sobre la cátedra Profesor: Análisis y Diseño de Sistemas Clase 1 – Sistemas e Ingeniería de Software Mercedes Vitturini Oficina 211. E-Mail
[email protected] Horario de Consulta: martes 18:00 hs. Asistente: Telma Delladio Lic. María Mercedes Vitturini Auxiliares: 1er. CUATRIMESTRE 2007 Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur María Clara Casalini. Marian Fernandez Benassati. Victor Ferracutti. Análisis y Diseño de Sistemas - Clase 1 2 Material Horarios de Clase Acceso al material – Teoría En la fotocopiadora del CeCom Clases Teóricas. Clases Prácticas. Material Bibliográfico. Martes: 14:00 a 16:00 – Aula 38A. Jueves: 14:00 a 16:00 – Aula 38A. Práctica Página de la materia: http://cs.uns.edu.ar/aads/ Clases Teóricas. Clases Prácticas. Información General de la Materia. Links a las Herramientas de trabajo. Análisis y Diseño de Sistemas - Clase 1 3 Martes: 16:00 a 18:00 – Aula 38A. Jueves: 16:00 a 18:00 – Aula 38A. Análisis y Diseño de Sistemas - Clase 1 4 Condiciones de cursado de la materia Proyectos de cursado Dos Parciales. 1er. Parcial, jueves 3 de mayo. 2do. Parcial, jueves 13 de junio. Un único recuperatorio Recuperatorio jueves 28 de junio. Construcción de los modelos de análisis y primeros modelos de diseño para un Sistema asignado. El trabajo es en comisiones. Entregas. Para rendir recuperatorio se requiere tener aprobado uno de los dos parciales. La inscripción a cursado es en los puestos de autogestión hasta el 30/03/2007 Primer entrega: 10 de abril. Segunda entrega: 10 de mayo. Tercera entrega: 23 de junio. La NO presentación del trabajo en las fechas establecidas, implica automáticamente la desaprobación del cursado. Análisis y Diseño de Sistemas - Clase 1 5 Análisis y Diseño de Sistemas - Clase 1 6 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 1 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. ¿Sistemas? ¿Sistemas? Sistema de computación. Sistema operativo. Sistema de liquidación de sueldos. Sistema educativo. Sistema de gobierno. Sistema de ingreso a la UNS. … Análisis y Diseño de Sistemas - Clase 1 8 Sistemas - Definiciones Sistemas - Definición Definición 1 – Un conjunto organizado de doctrinas, ideas y principios que intentan explicar el funcionamiento de un todo. Ejemplo: Las leyes de la mecánica. Definición 4 – Un grupo de ítems interdependientes o que interactúan de manera regular formando un todo. Ejemplos: Definición 2 – Un procedimiento organizado o Definició establecido. Ejemplo: Sistema de numeración, Sistema de clasificación. Un grupo de órganos que cumplen una función (sistema digestivo). Un grupo de cuerpos interactuando bajo influencia de fuerzas relacionadas (sistema gravitacional). Una central telefónica. Sistema de producción. Definición 3 – Un patrón o arreglo armónico. Definició Ejemplo: Orden social, Sistema Universitario. Análisis y Diseño de Sistemas - Clase 1 9 Análisis y Diseño de Sistemas - Clase 1 10 ¿Por qué estudiar los sistemas? Un sistema automatizado forma parte de un sistema mayor. Los sistemas automatizados reemplazan a sistemas que existían previamente. Aunque los distintos tipos de sistemas parecen diferentes, existen principios, teorías y filosofías que son compartidos por todos. Clasificación de Sistemas Vivientes (J. Miller) Sistema fronterizo – mantiene todos los elementos juntos, y los protege del entorno. La piel. Sistema de seguridad de control de acceso. Firewall. Sistema consumidor – incorpora energía del entorno al sistema. Sistema digestivo. Lectora de barras. Procesador de imágenes. Análisis y Diseño de Sistemas - Clase 1 12 Análisis y Diseño de Sistemas - Clase 1 11 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 2 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Clasificación de Sistemas Vivientes … Sistemas - Clasificación Sistema distribuidor – trae y lleva inputs y outputs con el exterior. Sistema telefónico. Sistema de correo electrónico. Sistemas naturales: Sistemas Físicos (geológicos, moleculares, etc.) Sistemas Vivientes (animales, plantas) Sistemas construidos por el hombre: Manuales. Automáticos o automatizados. Mixtos. Sistema reproductor: capaz de crear otro sistema similar al propio. Sector de planeamiento. Lenguajes de programación. De nuestro interés Análisis y Diseño de Sistemas - Clase 1 13 Análisis y Diseño de Sistemas - Clase 1 14 Sistemas construidos por el hombre Sistemas Automatizados Ejemplos Sistemas sociales Sistemas de transporte Sistemas de comunicaciones Sistemas financieros ... Sistemas Automatizados: Son sistemas hechos por el hombre y controlados por una o varias computadoras. Generalmente se componen de: Hardware: CPU, discos, impresoras, etc. Software: sistema operativos, bases de datos, programas de aplicación, etc. Personas: proveen y/o consumen lo que produce el sistema. Datos: información que se mantiene por período de tiempo. Procedimientos: políticas e instrucciones para operar el sistema. Documentación: manuales, formularios y otros modelos que describen en sistema. Análisis y Diseño de Sistemas - Clase 1 16 Análisis y Diseño de Sistemas - Clase 1 15 Sistemas Automatizados - Evolución Sistemas Batch Características: Recolectan datos por un período de tiempo. No interactúan con usuarios. Procesan varias transacciones juntas. Generalmente tienen acceso secuencial a la mayoría de la información. Batch. On-line. Sistemas de Tiempo Real. Sistemas de soporte de decisión. Sistemas basados en conocimiento. T I E M P O Ejemplo: Políticas de backup. Análisis y Diseño de Sistemas - Clase 1 18 Análisis y Diseño de Sistemas - Clase 1 17 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 3 Algún tipo de software educativo.. Requiere acceso rápido a los datos. Cuanto mayor es un sistema. Principios Generales de los sistemas Cuanto más especializado es un sistema.Clase 1 19 Análisis y Diseño de Sistemas .. Ejemplos: Control de procesos. Ejemplos: Data warehouse. Sistemas on-line Características: La transacción se registra cuando sucede. 4 . Se accede en forma aleatoria a una porción de los datos.Cuatrimestre de 2007.Clase 1 20 . sino que colaboran con la toma de decisión. Los sistemas tienden a crecer. procesándolos y devolviéndolos con suficiente rapidez como para influir en dicho ambiente en ese momento.Clase 1 22 Análisis y Diseño de Sistemas . Pueden presentar la información de varias maneras. Análisis y Diseño de Sistemas . Controla el entorno. No poseen salidas programadas. Asignación de prioridades.Clase 1 23 Estas transparencias proveen sólo una referencia a los temas. Interactúan con personas y ambiente. Una respuesta fuera de tiempo puede ser catastrófica Características Sistemas de facturación. Las transacciones son sencillas. Sistemas de monitoreo de pacientes.Clase 1 24 Ejemplos: Sistemas de ayuda. Procesa de a una transacción por vez. Sistemas de Tiempo Real Sistemas de soporte de decisión Características No toman decisiones por si solos. Para su estudio debe remitirse a la bibliografía. Utilizan técnicas de Inteligencia Artificial. Adquisición de datos de alta velocidad (satélites). Análisis y Diseño de Sistemas . Sistemas de compras vía Web. Manejo de interrupciones.Clase 1 21 Sistemas basados en conocimiento Características Sistemas expertos. Interactúa con el usuario. Ejemplo: Sistemas de Tiempo Real Definición: sistemas que controlan un ambiente recibiendo datos. menos capaz es de adaptarse a circunstancias diferentes. Planillas de cálculo. Análisis y Diseño de Sistemas . más recursos necesita para su mantenimiento. Imitan el comportamiento de una persona en tareas inteligentes. Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Sistemas de switcheo telefónico. Los sistemas son siempre parte de un sistema mayor y casi siempre se pueden partir en sistemas más pequeños. Software genéricos: desarrollados para ser vendidos a un mercado abierto.. Construcciones de múltiples versiones de software hecho por múltiples personas. Análisis y Diseño de Sistemas . Ingeniería de Software Es esencialmente una actividad en equipo: un ingeniero de software desarrollará un componente de software que se combinará con otros componentes desarrollados por otros ingenieros. Productos de ingeniería.Cuatrimestre de 2007. Software a medida: software desarrollado para un cliente particular bajo un contrato. Estas transparencias proveen sólo una referencia a los temas. Requiere de un trabajo disciplinado. Existen versiones del producto. (Parnas) IS es el área de las ciencias de la computación que estudia la construcción de sistemas de software de gran escala Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas .Clase 1 27 Componente de software Se combina con otros componentes escritos por otras personas. Para su estudio debe remitirse a la bibliografía. Análisis y Diseño de Sistemas . Programación escrita por el propio interesado. Son usados y modificados por otras personas. El producto perdura en el tiempo y está sujeto a cambios.Clase 1 28 El producto software Evolución en producción de software La ingeniería de software produce productos de software Un producto de software es un sistema de software distribuido a un cliente junto con su documentación.Clase 1 29 Se distinguen los roles programador y usuario. Proyectos de software de mayor escala (sistemas operativos) Software como parte de un sistema más complejo..Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 1 26 Ingeniería de Software . Lenguajes de programación de más alto nivel y computadoras accesibles. Análisis y Diseño de Sistemas . Ingeniería de Software Ingeniería de Software Es un área de las ciencias de la computación que estudia la construcción de sistemas de software tan grandes y complejos que requieren de un grupo de ingenieros. 5 .Clase 1 30 Ingeniería de Software. Los productos de software se clasifican: Ubicar un conjunto de instrucciones juntas para que la computadora haga algo útil: Problema bien definido. Definiciones. Modelizar y trabajar con distintos niveles de abstracción. Ghezzi – Cap. Principios de Sistemas. 2.Clase 1 31 Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Para su estudio debe remitirse a la bibliografía. Facilitan operaciones comerciales y de toma de decisión. Pfleeger. Tipos de Sistemas. Sistemas Automáticos. “Fundamentals of Software Engineering” – C. Buen programador y conocer sobre lenguajes de programación.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Aplicaciones del Software Aplicaciones del Software Software de Sistema Programas para servir a otros programas Software científico Ejemplos: compiladores. Pressman. Análisis y Diseño de Sistemas . Reside en memoria de lectura. Análisis y Diseño de Sistemas . Ejemplo: conmutador telefónico. Plantear cronogramas de trabajo y organizar trabajos en equipo. Software embebido Ejemplos: software de gestión de y un ATM Software de Tiempo Real: Ejecuta funciones limitadas. Análisis y Diseño de Sistemas . Ingeniería de Software. Transformar requerimientos ambiguos en precisos. analiza y controla sucesos del entorno en la medida que ocurren. Otras lecturas sugeridas “Ingeniería de Software -Teoría y práctica” . Sistemas.Clase 1 33 Bibliografía “Análisis Estructurado Moderno” – E.Shari L. Definición.Clase 1 34 Estas transparencias proveen sólo una referencia a los temas. sistemas operativos Incluyen algoritmos y facilidades de simulación Software de Gestión Ejemplos: GIS Procesamiento de información comercial. Yourdon – Cap. Ejemplo: control de teclas de un horno microondas.1. En los proyectos de mayor envergadura. ser requiere de capacidad para: Comunicación con distintos perfiles de usuarios. Evolución.Clase 1 32 El rol del Ingeniero de Software Temas de la Clase de hoy En desarrollos de baja escala. 6 . Manejo estructuras de datos y abstracciones. Coordina. “Ingeniería de Software – Un enfoque práctico” – Roger S. Análisis y Diseño de Sistemas .Clase 1 5 Un equipo de desarrollo dentro de la empresa. Análisis y Diseño de Sistemas .Clase 1 3 Repaso – Ingeniero de Software El Departamento de sistemas Un Ingeniero de Software debe tener dominio sobre un amplio espectro de actividades. el desarrollo de sistemas puede estar a cargo de: Habilidades interpersonales Las diferentes personas que interactúan con el sistema se pueden clasificar: usuarios. Para su estudio debe remitirse a la bibliografía. auditores. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Los sistemas automatizados son un tipo especial de sistemas construido por el hombre y controlados por una o varias computadoras. datos. Versiones del producto. 1 . personal de operación. procedimientos. SW. dirección. Producto y Proceso Lic. CUATRIMESTRE 2007 Dpto. programadores. Repaso Análisis y Diseño de Sistemas Clase 2 – Participantes.Cuatrimestre de 2007. modelado … Relación Equipo de desarrollo – Empresa En un proyecto. gerentes. María Mercedes Vitturini 1er. Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. etc. Tecnología. Según la alternativa las comunicaciones van a ser diferentes. Pueden hacerse desarrollos para usuarios no conocidos (software de propósito general). Un equipo de desarrollo de una empresa externa (desarrollo de terceros). planificación. documentación … Ingeniería de software es un área de las ciencias de la computación que estudia la construcción de sistemas de software grandes y complejos.Clase 1 6 Estas transparencias proveen sólo una referencia a los temas.Clase 1 2 Ingeniería de Software Ingeniería de Software produce participan Los participantes Producto: SOFTWARE Participantes (jugadores) requiere_de Proceso de Producción En el desarrollo de software se involucra a distintos jugadores o participantes. dentro y fuera del equipo de desarrollo. Análisis y Diseño de Sistemas . Incluyen: HW. personas. Equipo de desarrollo. analistas y diseñadores. Conformar. Análisis y Diseño de Sistemas . necesidades Usuarios Persona/s para la que se construye el sistema (“clientes”o “dueños del sistema”) Entrevistar. 2 . Usuarios Ejecutivos. Usuarios Supervisores.Clase 1 8 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Obligación contractual Usuario Usa el sistema. Novato. Están familiarizados con modelos abstractos. Esto acarrea malos entendidos.Clase 1 11 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Les interesa la información que puedan obtener del sistema. Puede negarse a que se entreviste a sus operadores.Cuatrimestre de 2007.Clase 1 7 Clasificación de los Usuarios Usuarios por categoría de trabajo Ejecutivo_1 Por categoría de trabajo Usuarios Operativos. $$$. Necesidades Sistema de Software Existen sistemas donde no se conoce al usuario.Clase 1 9 Operativo_1 Operativo_2 Operativo_3 Operativo_4 Operativo_5 Análisis y Diseño de Sistemas . Experto.Clase 1 12 Estas transparencias proveen sólo una referencia a los temas. Tiene una visión similar al usuario operador.Clase 1 10 Usuarios Ejecutivos Características Usuarios Supervisores Características Dan iniciativa al proyecto. Generalmente en tiempos anteriores fueron usuarios operativos. Participantes en el desarrollo de software – Primer clasificación Cliente Patrocina el desarrollo del sistema.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Desarrollador Construye el sistema. En estos casos es importante documentar. Les interesa el aumento de productividad que pueda darles el nuevo sistema a su área. Se interesan por estrategias de mercado y ganancias/pérdidas. Supervisor_1 Por nivel de experiencia en proyectos de desarrollo de software. Tienen una visión global del sistema. Para su estudio debe remitirse a la bibliografía. Supervisor_2 Amateur. de backups. Tienden a imponer su manera de manejar las cosas. Se ocupan demasiado de las formas.Clase 1 15 Análisis y Diseño de Sistemas .Oper Sup_22 Op_221 Op_222 Análisis y Diseño de Sistemas .Clase 1 17 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 1 16 Otros participantes Personal de Operación Responsables de la red.Clase 1 14 Cliente y Usuarios Gerente Otros participantes Auditores Personal de control de calidad.Clase 1 18 Estas transparencias proveen sólo una referencia a los temas. Tienen la decisión sobre el futuro del proyecto.Cuatrimestre de 2007. Tienen una visión local. Se interesan por funciones e interfaz. Revisan modelos. sistemas de hardware. Cuanto mayor sea el nivel de gerencia menos le interesará la tecnología informática. Tener en cuenta: Op_221 Ej_1 Ej_2 Sup_11 Sup_12 Sup_21 Sup_22 Op_111 Op_121 Op_211 Op_112 Op_122 Op_212 Op_222 Pueden aparecer en juego tarde. Una pirámide de participantes Gerente Auditor Ej_1 Sup_11 Op_111 Op_112 Sup_12 Op_121 Op_122 Op_123 Sup_21 Op_211 Op_212 Ej_2 ¿? Ing. Op_123 Análisis y Diseño de Sistemas . de SW P. Les interesa las nuevas posibilidades de negocio. Manejan términos físicos. La comunicación solo se requiere para coordinar tareas. Análisis y Diseño de Sistemas . Usuarios Operativos Características Gerentes (Clientes en la transparencia 7) Características Son los que tendrán contacto diario con el nuevo sistemas. Verifican que se respeten estándares. Diferentes gerentes pueden tomar posiciones encontradas con relación al proyecto. Para su estudio debe remitirse a la bibliografía. Sus prioridades pueden estar en conflicto con la de los usuarios. 3 .Clase 1 13 Análisis y Diseño de Sistemas . Clase 1 23 Estas transparencias proveen sólo una referencia a los temas.Clase 1 20 El equipo de desarrollo Análisis y Definición de Requerimientos Diseño del Sistema Diseño de Programas Implementación de programas Prueba de programa Prueba de Sistema Entrega del Sistema Mantenimiento Análisis y Diseño de Sistemas . Personal de Operación Para discutir: ¿Qué le puede interesar a cada tipo de usuario? Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Distintos niveles de usuarios: Alumnos.Clase 1 19 Analista: trabaja con el cliente desglosando en requerimientos separados lo que el cliente desea. Análisis y Diseño de Sistemas .Cuatrimestre de 2007. etc. Experiencia en proyectos similares. Para discutir: Testeador Ventajas y desventajas que los roles programador y testeador sean cubiertos por distintas personas. Testeadores: trabajan con el equipo de implementación para verificar que el sistema se comporta de acuerdo a la especificación. Rector El auditor. Diseñador: a partir de los requerimientos documentados. Capacitador 21 Análisis y Diseño de Sistemas . Programadores: a partir del diseño escriben el código. experiencia con las herramientas … Análisis y Diseño de Sistemas . Respetar los perfiles y habilidades naturales de cada persona: La ingeniería de software tiene como objetivo producir software de calidad. Para su estudio debe remitirse a la bibliografía. Otros: capacitador. Docentes de cátedra.Clase 1 Analista El equipo de desarrollo Diseñador Programador Dependiendo del proyecto. generan una descripción de lo que el sistema debe hacer.Clase 1 22 El equipo de desarrollo Entre los roles asignados al IS está el de componer un equipo desarrollo: El producto de software Determinar la cantidad de personas de cada rol que se necesitan. habilidad de comunicación. capacidad para trabajar en equipo. cada uno de estos roles puede ser cubierto por una o más personas y una misma persona puede cubrir uno o más roles. 4 . Secretarios Académicos de Departamentos. personal de atención a usuarios. Asignar a distintas personas distintos roles y responsabilidades. Ejemplo El equipo de desarrollo Para el desarrollo de un portal educativo para la UNS. se puede dividir en tres fases genéricas: El la vida de un sistema comprende desde la concepción de la idea de un desarrollo de software.Clase 1 27 El proceso de desarrollo de Software Ciclo de vida El proceso define un marco de trabajo para un conjunto de tareas claves en la producción de software. El software es maleable. Para obtener el producto se dice que el sistema tiene un ciclo de vida compuesto por varias etapas.Clase 1 26 Curvas de Fallo de HW y SW Diferencias de comportamiento entre el HW y SW Mortalidad infantil Indice de Fallos Se estropea Incremento del índice de fallos por efectos laterales El proceso de producción de software El objetivo de un proceso de producción es lograr productos confiables. Análisis y Diseño de Sistemas . predecibles y eficientes. El producto de ingeniería de software es un sistema de software que es distribuido a un cliente junto con su documentación. Fase de desarrollo (cómo se va hacer). Fase de definición (qué se espera del producto). no importa el área de aplicación. Su construcción requiere de creatividad.Cuatrimestre de 2007. tamaño o complejidad del producto.Clase 1 Estas transparencias proveen sólo una referencia a los temas. Indice de Fallos Tiempo Cambio Curva real Curva idealizada Curva de fallos de HW Tiempo Curva de fallos de SW Análisis y Diseño de Sistemas . 5 .Clase 1 30 Análisis y Diseño de Sistemas .Clase 1 25 Análisis y Diseño de Sistemas . El software no se estropea (pero se deteriora). en cualquier proceso de ingeniería de software. El producto El producto de Software SW – Características A diferencia de otros productos de ingeniería el software es un producto particular. y aún después hasta que deja de usarse. La industria tiende a ensamblar componentes. Para su estudio debe remitirse a la bibliografía. El software se desarrolla no se fabrica. 29 Análisis y Diseño de Sistemas . Fase de mantenimiento. El ciclo de vida de un sistema define el orden en el cual se realizan las actividades para construir software. hasta que es implementado y entregado. pero aún la mayor parte del software se construye es a medida. Generalmente.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. La ingeniería de software apunta a la construcción de software como una actividad de ingeniería: Producir productos de calidad El software es lógico y no físico. Características Code & Fix Etapas Escribir código Corregirlo (mejorar o agregar funcionalidades). El tamaño de los sistemas hace difícil manejar la complejidad. por lo que no es fácil de automatizar. Análisis.Clase 1 32 Evolución del proceso de desarrollo Code-Fix Fue la primera aproximación de desarrollo. el ciclo de vida debe ser anticipado y controlado. Se requiere mayor calidad. Análisis y Diseño de Sistemas . Diseño. Análisis y Diseño de Sistemas . El ciclo de vida es define el proceso a seguir para: construir. La tarea de corregir código se torna muy dificultosa. Posible en aplicaciones cortas y bien entendidas. Su proceso de desarrollo es altamente intelectual. predecibles y mantenibles. Los requerimientos cambian constantemente y debe ser capaz de evolucionar. entregar y hacer evolucionar al producto de software. Para lograr las calidades deseadas en el producto. Se necesitan modelos de comunicación.Cuatrimestre de 2007. El objetivo de un proceso de producción: obtener producciones confiables. Un ciclo de vida está compuesto por varias etapas. Necesidad de aplicaciones más complejas. Los lenguajes de programación bajo nivel. Surge la necesidad de identificar nuevas etapas: El desarrollo se convierte en una actividad grupal. Para su estudio debe remitirse a la bibliografía. No es un ciclo de vida. 6 .Clase 1 36 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . Ciclo de vida (CV) El producto de Software Recordamos El software es un producto particular.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 1 34 Evolución del Proceso Cambian las necesidades Se separan los roles programador y usuario. Implementación. Es maleable. El software se caracteriza por su alta inestabilidad.Clase 1 31 Análisis y Diseño de Sistemas . Modelo Semi-Estructurado Las actividades codificar y corregir no fueron suficientes El producto no satisface las necesidades del usuario. Después de algunas evoluciones se torna no confiable. El problema era sencillo y bien entendido.Clase 1 35 Modelo Se miEstructurad o: Análisis y Diseño de Sistemas . Observaciones: El desarrollo de software era una tarea unipersonal.Clase 1 33 Análisis y Diseño de Sistemas . Clase 1 39 Análisis y Diseño de Sistemas . donde se definen costos y beneficios del software.Clase 1 42 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Diseño arquitectónico (o de alto nivel): define la organización y estructura modular Diseño detallado: se diseñan en detalle cada uno de los módulos.Clase 1 41 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . se entrega al cliente. código para testeos. 7 . Cuando se llega a la etapa de mantenimiento depende del proceso de desarrollo utilizado.Clase 1 37 Tiene lugar después del estudio de factibilidad. Actividades del Ciclo de Vida Actualmente. Ejemplo: prototipos. En esta etapa participan tanto desarrolladores como clientes y usuarios. Cuando el sistema pasa todos los testeos. Mantenimiento.Clase 1 40 Integración y testeo de sistemas Entrega y Mantenimiento Todos los módulos desarrollados y testeados individualmente se combinan o integran.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Pruebas de integración. Se identifican y documentan los requerimientos exactos del sistema. Se produce el código que será distribuido al cliente como sistema en producción. Implementación de programas. Pruebas unitarias. Se prueba el sistema como un todo.Clase 1 38 Diseño y Especificación Codificación y Testeo de Módulos Se diseña el sistema de software para alcanzar los requerimientos. Los requerimientos se plantean en términos de las necesidades de los usuarios del sistema. Diseño de programas. Los módulos desarrollados deben ser testeados. Estos desarrollos son para el uso interno. en el desarrollo de software se incluye las siguientes actividades (no excluyentes): Análisis de Requerimientos y Especificación Análisis y definición de requerimientos. Análisis y Diseño de Sistemas . Esta relacionado con ¿cómo? Se divide en: Obs: pueden existir otras etapas que incluyan desarrollo de códigos. Para su estudio debe remitirse a la bibliografía. Diseño de sistemas. Las modificaciones hechas al sistema después de su primer entrega pertenecen a esta etapa. Entrega del sistema. Pfleeger. “Ingeniería de Software – Un enfoque práctico” – Roger S. Para su estudio debe remitirse a la bibliografía. El producto de software. el equipo de desarrollo. “Fundamentals of Software Engineering” – C. Los procesos de construcción de software también evolucionaron en la medida que evolucionaron la tecnología y los requerimientos a satisfacer. El proceso de desarrollo. 3. Bibliografía “Análisis Estructurado Moderno” – E. evolución y actividades. Características. Definición.1.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Shari L.Clase 1 44 Estas transparencias proveen sólo una referencia a los temas.Clase 1 43 Otras lecturas sugeridas “Ingeniería de Software -Teoría y práctica” . Cascada. Pressman. Análisis y Diseño de Sistemas . El ingeniero de software. Vamos a definir y estudiar modelos de procesos o ciclos de vida para la construcción de software. Evolutivo Transformacional Espiral Análisis y Diseño de Sistemas . los usuarios. Yourdon – Cap.Cuatrimestre de 2007. Ghezzi – Cap. Modelos Producción de Software Temas de la Clase de hoy Participantes. 8 . equipos. con especificación de las características más relevantes que lo diferencian de los existentes en el mercado. precios vigentes y previstos para el proyecto. Empresa o Dependencia Universitaria que presenta el proyecto Breve Descripción del Proyecto. Constituye el marco referencial del Proyecto acorde a sus principales elementos: mercado. rentabilidad). empleo y otras repercusiones. ASPECTOS GENERALES Nombre del Proyecto. el mercado que cubrirá el proyecto. tecnología. objetivos. Denominación que se le ha dado al proyecto. EVALUACION FINANCIERA: . en el cual se resalten los aspectos mas relevantes de las actividades a desarrollar con el proyecto a emprender (Oportunidad. estrategias de mercadeo. requerimientos de personal y evaluación de la disponibilidad de materiales e insumos requeridos en el proyecto. inversión. ASPECTOS DEL MERCADO El alcance del estudio de mercado varía en función de la naturaleza del proyecto que se pretende desarrollar. Caracterización.1/3 - . JUSTIFICACION La justificación se apoya en los análisis de los distintos elementos que componen el estudio formulado que reflejen su viabilidad. En este capitulo se presenta la información relativa a costos de inversión. usos y usuarios o clientes.Departamento de Ciencias e Ing. Responsables Promotores. demanda. fundamentados en la problemática existente. financiamiento. necesidad a satisfacer u oportunidad empresarial. aprovechamiento del potencial existente en la Institución universitaria en personal. la situación de la competencia. insumos. ASPECTOS TÉCNICOS En este punto se debe indicar la capacidad prevista de instalación. instalaciones físicas. Productos o Servicios a Ofrecer Se trata de una descripción de los productos o servicios. ingresos. programa de producción y/o prestación de servicio. de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas ANÁLISIS Y DISEÑO DE SISTEMAS ESTUDIO DE FACTIBILIDAD 1er Cuatrimestre 2007 COMO ELABORAR UN ESTUDIO DE FACTIBILIDAD RESUMEN Consiste en una explicación sucinta de las características más sobresalientes. descripción del proceso o actividades. Objetivos. costos de operación y los ingresos previstos durante el periodo de vida útil del proyecto. Los objetivos definen los cambios esperados con la ejecución del proyecto. así mismo. ventajas competitivas entre otras. En este sentido. los efectos generados con la ejecución del proyecto. entre otros. debe proporcionar ciertos datos básicos sobre la demanda actual y futura. ASPECTOS FINANCIEROS. 2/3 - . para respetar los plazos de entrega definidos al cliente. deben presentarse las proyecciones financieras para todo el período de vida útil previsto a precios constantes y/o precios corrientes EJEMPLO PROYECTO VEMB Nombre del Proyecto: VEMB – Venta Electrónica de Material Bibliográfico. autor. La información de libros para el catálogo de libros se tomará de la base de datos con la que actualmente cuenta la librería. Para ello contarán con mecanismos de búsqueda por ISBN. o La funcionalidad será de uso público. o Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. María Gutierrez Objetivo: o Proveer un nuevo servicio de venta electrónica de libros por Internet. Empresa: Librería UNS Responsable de la Empresa: Lic.Departamento de Ciencias e Ing. o Los clientes podrán consultar el catálogo de libros disponibles. de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas Con la finalidad de demostrar las bondades del proyecto. Aspectos Importantes o o La notificación de pedidos de compras al departamento de ventas debe ser diaria. Opcionalmente podrán efectuar sus pedidos de compra por uno más libros o El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo. sin embargo se requiere que los clientes compradores se registren previamente. María Mercedes Vitturini Descripción del Problema: El objetivo es desarrollar una aplicación que permita la venta electrónica de libros con las siguientes características. El servicio estará en funcionamiento todo el día y todos los días. . Usuarios o Los usuarios que se identifican para este sistema son el “cliente de Internet” y la interfaz con el Departamento de Ventas. Responsable de sistemas: Lic. título o área de interés. 2.Departamento de Ciencias e Ing. Próximas evoluciones o o Queda fuera del alcance de este proyecto ofrecer un sistema de pedidos mayoristas. Tiempo estimado: 1 mes y medio. de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas Alternativas de Desarrollo Propuestas: 1. En caso de contratar personal adicional se deberá contar con la adquisición de equipos para desarrollo. Contratar a un nuevo programador dedicado exclusivamente al proyecto. Las búsquedas de libros por palabras claves. Tiempo estimado: 2 meses y medio. un programador y un analista del área de sistemas 4 horas diarias. Destinar diariamente a este proyecto 4 horas de dos programadores del personal de sistemas y un analista.3/3 - . . Otros recursos: o o El proyecto se puede encarar con los recursos de software y hardware disponibles. Para su estudio debe remitirse a la bibliografía.9 . Booch. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Azul: primer parcial – Rojo: segundo parcial 2 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Fase de mantenimiento. Para obtener el producto se dice que el sistema tiene un ciclo de vida compuesto por varias etapas.3 . Rumbaugh Object Oriented Modeling and Design . hasta que es implementado y entregado. Fase de desarrollo (cómo). El ciclo de vida de un sistema define el orden en el cual se realizan las actividades para construir software.11 12 . 5 Análisis y Diseño de Sistemas . 21 de junio. Fundamentos de Base de Datos . 1 . Fundamentals of Software Engineering .Clase 3 6 Análisis y Diseño de Sistemas . CUATRIMESTRE 2007 The RAISE Specification Language El Proceso Unificado de Desarrollo de Software Jacobson. Bibliografía Material Bibliográfico Capítulos 2 . no importa el área de aplicación.13 y 14 1-2-3–4y7 2y7 Sólo el capítulo 1 Todo Sólo el capítulo 7 Primera y segunda parte (capítulos 2 a 16) Análisis y Diseño de Sistemas Clase 3 – Modelos de Proceso Análisis Estructurado Moderno – Edward Yourdon. tamaño o complejidad del producto. en cualquier proceso de ingeniería de software.Rumbaugh Dpto. Tercera entrega: 23 de junio. El proceso de desarrollo de Software Primer entrega: 10 de abril. Generalmente.Abraham Silberschatz The RAISE Method Lic. Para lograr las calidades deseadas en el producto. el ciclo de vida debe ser anticipado y controlado. Segunda entrega: 10 de mayo.Carlo Ghezzi. predecibles y mantenibles. y aún después hasta que deja de usarse. Análisis y Diseño de Sistemas .Cuatrimestre de 2007. se puede dividir en tres fases genéricas: Fase de definición (qué).Clase 3 4 Objetivos Ciclo de vida El objetivo de un proceso de producción: obtener producciones: confiables. El proceso define un marco de trabajo para un conjunto de tareas claves en la producción de software.Clase 3 3 Análisis y Diseño de Sistemas . María Mercedes Vitturini 1er.Clase 3 Estas transparencias proveen sólo una referencia a los temas.10 . El la vida de un sistema comprende desde la concepción de la idea de un desarrollo de software.Clase 3 Fe de Errata Proyecto de cursado Entregas. Un sistema de juegos en red. Diseño arquitectónico (o de alto nivel): define la organización y estructura modular Diseño detallado: se diseñan en detalle cada uno de los módulos. Un sistema operativo. Se prueba el sistema como un todo. Mantenimiento. Actividades del Ciclo de Vida Actividades del Ciclo de Vida Análisis de Requerimientos y Especificación El desarrollo de software incluye las siguientes actividades (no excluyentes): Análisis y definición de requerimientos. Análisis y Diseño de Sistemas . Diseño de sistemas. La relación empresa-equipo de desarrollo (consultora. Diseño de programas. Estas transparencias proveen sólo una referencia a los temas. Entrega del sistema.Clase 3 11 Modelos de Proceso Genéricos Un modelo de proceso es una representación abstracta del proceso de producción del software Según el tipo de proyecto. Un sistema de control de vuelos de un aeropuerto. Para su estudio debe remitirse a la bibliografía. Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Pruebas unitarias. Integración y Testeo de sistema Todos los módulos desarrollados y testeados individualmente se combinan o integran. etc.) Análisis y Diseño de Sistemas .Clase 3 7 Actividades del Ciclo de Vida Codificación y Testeo de Módulos Actividades del Ciclo de Vida Entrega y Mantenimiento El sistema se entrega al cliente cuando pasa todos los testeos Las modificaciones hechas al sistema después de su primer entrega pertenecen a la etapa de mantenimiento. área de sistemas. Según el tipo de producto. En esta etapa participan tanto desarrolladores como clientes y usuarios.Clase 3 9 Análisis y Diseño de Sistemas . Pruebas de integración. Un sistema de gestión de ventas de pasajes aéreos. Los módulos desarrollados deben ser testeados.Cuatrimestre de 2007. Diseño y Especificación Se diseña el sistema de software para alcanzar los requerimientos. Implementación de programas. Se produce el código que será distribuido al cliente como sistema en producción. Se identifican y documentan los requerimientos exactos del sistema.Clase 3 8 Análisis y Diseño de Sistemas . 2 .Clase 3 10 Personalizar el Proceso No existen dos proyectos iguales por lo que es necesario personalizar el proceso según cada caso. Contarán con mecanismos de búsqueda por ISBN. Metodología Modelo de CASCADA (MC) El modelo o metodología de desarrollo provee: El orden de las distintas actividades El marco para administrar proyectos (estimar recursos y controlar el proyecto). Las tareas se organizan en cascada. Se usó para las primeras aplicaciones es crítica y compleja. Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail.Clase 3 13 Modelo CASCADA MC – Estudio de Factibilidad Depende de cada desarrollo. El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo.Control (comportamiento) Análisis y Diseño de Sistemas . Opcionalmente podrán efectuar pedidos de compra por uno más libros. Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. Paradigmas: Origen Cascada o secuencial. título o área de interés. Los clientes podrán consultar el catálogo de libros disponibles. Sin embargo.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. La salida (output) de una etapa es la entrada (input) de la siguiente etapa.funciones .Clase 3 17 MC – Análisis de requerimientos y especificación Identificar las calidades requeridas por la aplicación: funcionales y no funcionales.Clase 3 18 Estas transparencias proveen sólo una referencia a los temas. Separar en distintas visiones del software: Datos .Clase 3 14 Análisis y Diseño de Sistemas . una después de la otra. Creado en los años ’70 en un proyecto de defensa de EEUU. Se evalúan costos y beneficios de la aplicación. Recursos requeridos. Incluye: No incluídas originalmente Una definición general del problema. Salida: documento denominado estudio de factibilidad Análisis y Diseño de Sistemas . no se le puede destinar demasiado tiempo. sin embargo se requiere que los clientes compradores se registren previamente.Clase 3 15 Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB) Objetivo: proveer el servicio venta de libros vía Internet.Clase 3 16 Análisis y Diseño de Sistemas . Identificar qué? y no cómo? Separar. tiempos.Cuatrimestre de 2007. Soluciones alternativas y beneficios esperados. Evolutivos o de entregas refinadas. fechas de entrega para cada solución alternativa. abstraer y particionar Descripción en distintos niveles de abstracción. 3 . Cuanto más conocimiento se tenga del problema mejor. Separar en partes analizables. costos. Análisis y Diseño de Sistemas . ¿Qué debemos hacer a continuación? ¿Cuánto tiempo debemos seguir haciendo una actividad? Las etapas se pueden dividir en actividades ejecutadas concurrentemente. autor. Descripción: La funcionalidad será de uso público. Requerimientos en el proceso de desarrollo. Describir módulos y su relaciones. 2. Requerimientos funcionales. Salida: documento de especificación de requerimientos.Clase 3 21 Análisis y Diseño de Sistemas . Es importante definir y adoptar convenciones de programación. Control de calidad Walk-through. 4 . Dividir el sistema en módulos. Salida: conjunto de módulos implementados y probados. El 42% de los costos de mantenimiento se atribuyen a cambios en los requerimientos. MC – Análisis de requerimientos y especificación MC – Diseño y especificación 1. Se realiza el ensamblaje y prueba de la aplicación. Según las necesidades se pueden incluir revisiones de código (debbuging y testeo y chequeos de performance). El costo de mantenimiento en muchos casos representa más del 60% del costo del producto. Administración Definición de estándares.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.. Análisis y Diseño de Sistemas . Requerimientos no funcionales. Plan de pruebas. Salida: documento de especificación de diseño Análisis y Diseño de Sistemas . Dependiendo del tipo de desarrollo puede ser necesario incorporar nuevas actividades: El mantenimiento incluye todas las tareas luego del desarrollo. procedimientos de prueba. 3. completo. Documento de especificación: conciso. Testeo de volumen. prioridades de funciones.Clase 3 20 MC – Codificación y testeo de módulos MC – Testeo de sistema e integración Escribir programas en lenguajes de programación. En la etapa final incluye el testeo con usuarios reales (alfa test). Para su estudio debe remitirse a la bibliografía. Tratamiento con recursos (personas). Para verificar con el cliente. Análisis y Diseño de Sistemas . entendible. Diferentes enfoques: Testeo de integración. Salida: documento con el conjunto de datos de prueba y el plan de prueba. Se deben identificar: Las composición de las salidas son fijadas por la organización y la metodología utilizada.Clase 3 23 Análisis y Diseño de Sistemas . Diseño preliminar y diseño detallado. no ambiguo y fácil de modificar. Documentación.Clase 3 24 Estas transparencias proveen sólo una referencia a los temas. Validación. Especificar interfaces. Testeo del usuario.Clase 3 22 MC – Entrega y Mantenimiento MC – Otras actividades El sistema desarrollado de instala para usuarios Usuarios seleccionados (beta test) y luego a clientes.. Análisis y Diseño de Sistemas . Verificación.Cuatrimestre de 2007.Clase 3 19 Descripción de la arquitectura. Versión preliminar del manual del usuario. Ajustar diseño y objetivos. El cliente debe tener paciencia hasta ver resultados.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. No provee anticipación al cambio.Clase 3 25 Análisis y Diseño de Sistemas .Clase 3 26 Modelos Evolutivos Modelos de Procesos Evolutivos Motivación – las fallas de la primer versión de una aplicación conducen a la necesidad de rehacerla. HACERLO DOS VECES. Introduce disciplina al proceso. Parece burocrático. Estrategia – Solución – aproximaciones flexibles y evolutivas o incrementales. Para su estudio debe remitirse a la bibliografía. Contribuciones: Introduce rigidez.Clase 3 27 Análisis y Diseño de Sistemas . Mini-procesos de cascada. Difícil la estimación de recursos. Problema – gap entre la definición de requerimientos y la distribución de la aplicación.Cuatrimestre de 2007. Problemas – Entregar algo y medir el valor agregado. 5 . MC – Conclusiones MC – Conclusiones Desventajas: Es un modelo conducido o guiado por la documentación. Los costos se trasladan al mantenimiento fácilmente. Requiere herramientas. Investigación repetida de requerimientos y diseño. Cuidar que no sea code & fix Análisis y Diseño de Sistemas .Clase 3 30 Estas transparencias proveen sólo una referencia a los temas.Clase 3 28 Modelo de PROTOTIPO (MP) Modelo de Prototipos Se considera un modelo por si mismo. Alternativas – Prototipo evolutivo. Análisis y Diseño de Sistemas . Reducir el riesgo que la aplicación no se ajuste a las necesidades del cliente. El usuario necesita conocer todos sus requerimientos. Impone puntos de control claros. Basado en documentación. Es lineal y los proyectos reales raras veces siguen un modelo lineal. Es el paradigma más antiguo y más extensamente usado en ingeniería de software.Clase 3 29 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Pospone la implementación hasta que los objetivos estén claros. Objetivo De la revisión de cada etapa puede resultar que se necesite revisar los requerimientos de las etapas anteriores. Se toman decisiones rápidas para poder construir el prototipo.. Es cíclico. o reusar y las restricciones a esas alternativas. Para su estudio debe remitirse a la bibliografía. Incremento 2: funciones de edición más sofisticadas (gráficos. centrado en los aspectos del software que son visibles a los usuarios (enfoques de entrada y formatos de salida).Clase 3 Al primer incremento se lo denomina producto esencial. que son difíciles de revertir (por ejemplo el lenguaje de programación). conducidos por la evolución determinada según la experiencia operativa. Incremento integrado: es una unidad de software auto-contenida que realiza algún propósito útil.. Modelo de Prototipos Modelo Evolutivo (o Incremental) Etapas Recolección requerimientos del sistema: desarrollador y cliente definen los objetivos globales. incremento Tiempo calendario . Análisis Incremento 3 Diseño Código Prueba Entrega del 3er. etc.Clase 3 35 Se identifican los objetivos de la porción del producto bajo consideración. 33 Análisis y Diseño de Sistemas .Clase 3 32 Modelo Evolutivo Incremental Incremento 1 Análisis Diseño Código Prueba Entrega del 1er. Análisis y Diseño de Sistemas .Clase 3 31 Análisis y Diseño de Sistemas . 6 . Desventajas El cliente ve el prototipo y lo confunde con el sistema real.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Los incrementos se distribuyen a medida que se completan. incremento Incremento 1: administración de archivos básicos y producción de documentos. Análisis y Diseño de Sistemas . incremento ME – Ejemplo Un ejemplo de desarrollo incremental para un procesador de textos: Análisis Incremento 2 Diseño Código Prueba Entrega del 2do. prototipear. para minimizar y controlar el riesgo. Análisis y Diseño de Sistemas . diseñar.Clase 3 36 Segunda etapa Estas transparencias proveen sólo una referencia a los temas. Es un meta-modelo. etc. Riesgo: circunstancias potencialmente adversas que pueden perjudicar el proceso de desarrollo y la calidad de los productos. La evaluación del riesgo puede requerir distintas clases de actividades a ser planificadas (simulación.Clase 3 34 Modelo Espiral (MEs) Modelo Espiral Primera etapa El modelo combina las actividades del desarrollo con la gestión del riesgo. Es un modelo cuyas etapas consisten de incrementos expandidos de un producto de software operativo. Se elabora un diseño rápido. Plantear alternativas: comprar. en términos de calidades a lograr. tablas.). Se evalúan las alternativas y se identifican las áreas de riesgo potencial.Cuatrimestre de 2007. Administración del riesgo: disciplina cuyos objetivos son manejar y eliminar los ítems de riesgo del software antes que se transformen en amenaza. Análisis y Diseño de Sistemas .) Incremento 3: corrección gramatical y ortográfica. Clase 3 39 Modelo Transformacional Basado en especificaciones formales: el desarrollo de software como una secuencia de pasos que gradualmente transforma una especificación en implementación. Pretende reducir errores automatizando pasos del desarrollo.Clase 3 41 Análisis y Diseño de Sistemas . (+) Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida de cascada. Se deben transformar requerimientos informales en especificaciones formales: métodos de especificación formal. (+) Considera los riesgos técnicos en todas las etapas. Si los requerimientos se entienden bien. Garantiza resultados correctos. (-) No existe demasiada experiencia en su uso. Para su estudio debe remitirse a la bibliografía. Modelo Transformacional Ejemplos: Transformaciones automáticas para implementaciones recursivas en no recursivas. Cuarta etapa Se revisan los resultados para planificar la próxima vuelta de espiral. En la medida que progresa. Análisis y Diseño de Sistemas . logra reducirlos. El proceso está conducido por el riesgo. Modelo Espiral Tercera etapa Consiste del desarrollo y verificación del próximo nivel del producto. pero incorpora el marco de trabajo iterativo.Clase 3 37 Análisis y Diseño de Sistemas .Clase 3 38 Modelo Espiral (+) Constituye un enfoque realista del desarrollo de sistemas de software de gran escala.Clase 3 42 Estas transparencias proveen sólo una referencia a los temas. 7 . Análisis y Diseño de Sistemas . y aplicado adecuadamente. podría pensarse el modelo de cascada. (-) Requiere de habilidades para la evaluación del riesgo. Optimizadores de consultas.Cuatrimestre de 2007. Todo queda documentado. desarrollador y cliente comprenden y manejan mejor los riesgos. Los cambios se hacen en la especificación. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . como un modelo de espiral de una sola vuelta. Características Busca reusar componentes y construir componentes reusables. si un riesgo importante no se descubre pierde eficacia.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 3 40 Modelo Transformacional Etapas Especificación de requerimientos Optimización. 7. 8 . Espiral Fundamentals of Software Engineering. Capítulo 2.Clase 3 44 Resumen . R. Utiliza prototipos Requiere herramientas de prototipeo Modelos de procesos (Ciclos de vida). Para su estudio debe remitirse a la bibliografía. C. Modelo Transformacional Desventajas: El desarrollo de modelos formales es caro y lleva tiempo. Resumen Modelo Cod-Fix Cascada Conducido Prueba y error Documentación Observaciones No es un modelo de desarrollo Extremadamente rígido Tiene problemas de debugging e ntegración Metamodelo Espiral Riesgo Análisis y Diseño de Sistemas . Modelo Conducido Evolutivo Incremento Temas de la Clase de hoy Observaciones Con sólo implementación evolutiva. Transformacional. Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Cascada. se corre el riesgo de descubrir tarde los errores de diseño.Clase 3 43 Análisis y Diseño de Sistemas . Ingeniería del Software – Un enfoque Práctico.Clase 3 45 Estas transparencias proveen sólo una referencia a los temas. Se requiere de estudios detallados y personal capacitado. Utiliza técnicas de IA Lecturas sugeridas. Es difícil utilizar el modelo como medio de comunicación con el cliente. Cap. Pressman.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.. Evolutivo.. Guezzi.Clase 3 46 Bibliografía Transform acional Especificación Aplicable a problemas pequeños y críticos. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Los principales factores fueron: … Análisis y Diseño de Sistemas . Un requerimiento es: Lic.Clase 4 5 ¿Por qué son importantes los requerimientos? (lectura) . Falta de compromiso del usuario (12.1%).Clase 4 4 ¿Por qué son importantes los requerimientos? (lectura) . usualmente expresado como algo que el sistema debe hacer.3%). la documentación y la gestión de los requerimientos puede llevar a una gran cantidad de problemas: construir un sistema que resuelve el problema equivocado. durante la etapa de definición..Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er...7%). en las grandes compañías. 10$ durante la codificación..Clase 4 2 ¿Por qué son importantes los requerimientos? (lectura) En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar cómo les estaba yendo. Para comprender el por qué. Para su estudio debe remitirse a la bibliografía.9%). Es más. Falta de soporte ejecutivo (9. Análisis y Diseño de Sistemas . Requerimientos y especificaciones cambiantes (8.. Los resultados son desencantadores: El 31% de los proyectos de software fueron cancelados antes de completarse. 16% satisfizo esto. La falta de cuidado en la comprensión.Clase 4 3 Análisis y Diseño de Sistemas .4%). 20$ durante la prueba unitaria.Clase 4 6 Estas transparencias proveen sólo una referencia a los temas. Ingeniería de Software – Shari Pfleeger – Pág. Standish (1995) pidió a los participantes en el estudio que explicaran las causas de los proyectos fallidos. puede costar 5$ repararlo durante el diseño. Fin de la necesidad del sistema (7. el ¿Por qué son importantes los requerimientos? (lectura) . Es más un proceso de requerimientos mediocre puede en realidad resultar muy caro. Expectativas no realistas (9. María Mercedes Vitturini 1er. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Una característica del sistema. o que presenta dificultades para que los usuarios puedan comprenderlo y utilizarlo. y la gestión del proceso de los requerimientos participaron en casi todas estas causas.Cuatrimestre de 2007. 1 .6%). Falta de planeamiento (8. y hasta 200$ después de la entrega del sistema. Los principales factores fueron: … Requerimientos incompletos (13. Una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito de usuarios y clientes. En el trabajo de Boehm y Papaccio se consigna que si cuesta 1$ localizar y subsanar un problema debido a requerimientos. y obtener los requerimientos correctos desde el primer momento. que no funciona como se espera. sólo el 9% de los proyectos fue entregado en término y dentro del costo presupuestados.5%). Notemos que cierta parte de las etapas de la extracción. CUATRIMESTRE 2007 Dpto. Falta de recursos (10. Conclusión – es rentable tomarse el tiempo que sea necesario para comprender el problema y su contexto.. Requerimientos Análisis y Diseño de Sistemas Clase 4 – Ingeniería de Requerimientos Cada sistema basado en software tiene un propósito. la definición. 157 Análisis y Diseño de Sistemas . en pequeñas empresas.1%). El sistema debe funcionar en el servidor. Requerimientos NO Funcionales – Son las restricciones sobre los servicios o funciones ofrecidas por el sistema. Para su estudio debe remitirse a la bibliografía. Indican a los testeadores qué demostraciones llevar a cabo para que el cliente se convenza de que el sistema que se le entrega es lo que había solicitado. Incluyen restricciones de tiempo. Ejemplo: para un sistema de alumnos: ¿Cómo es que un alumno pierde su regulariadad? ¿Cuándo ocurre? ¿Se generan reportes? Análisis y Diseño de Sistemas .. Revisar que no existan conflictos.Clase 4 10 Requerimientos NO FUNCIONALES Identificar los Requerimientos Un requerimiento no funcional describe una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. Identificar actores (jugadores).Clase 4 12 Análisis y Diseño de Sistemas ... Propósito de los requerimientos Requerimientos – Clasificación Los requerimientos sirven a distintos propósitos: Permiten que los analistas expliquen cómo han entendido lo que el cliente y usuarios pretende del sistema.Clase 4 7 Análisis y Diseño de Sistemas . Se refieren al sistema como un todo.. •Arquitectos del sistema Análisis y Diseño de Sistemas . Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante.. las consultas en mostrador no deben demorar más de. etc.. Identificar necesidades no funcionales.. la selección se realiza en la etapa de diseño.Clase 4 9 Requerimientos FUNCIONALES Un requerimiento funcional describe un servicio o una interacción entre el sistema y su ambiente. el informe debe salir después de 2 horas de. Cómo identificar requerimientos NO FUNCIONALES. plataforma. Ejemplos: Cómo identificar requerimientos FUNCIONALES. Describen cómo debe comportarse el sistema ante determinados estímulos. sobre el proceso de desarrollo y estándares a respetar. Revisar que no existan conflictos. sin embargo. Debe ser precisa. 2 . Requerimientos del sistema: servicios y restricciones operativas en detalle: •Clientes gerentes •Usuarios finales •Arquitectos del sistema Corresponde con la especificación funcional.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 4 8 Requerimientos .Cuatrimestre de 2007.Clase 4 11 Estas transparencias proveen sólo una referencia a los temas. Establecen para los desarrolladores la especificación del comportamiento del sistema. Según el nivel de descripción los requerimientos se clasifican en: Requerimientos del usuario: sentencias en lenguaje natural más diagramas con los servicios que se espera que el sistema provea y las restricciones bajo las cuales debe operar. cómo debe reaccionar ante los estímulos que recibe y cómo el sistema debe comportarse en situaciones particulares. Para determinar los requerimientos funcionales se deciden cuáles son los estados aceptables para el sistema.. Análisis y Diseño de Sistemas . Identificar necesidades funcionales. Análisis y Diseño de Sistemas .Clasificación Requerimientos Funcionales – Representan los servicios que el sistema debe proveer. Estas restricciones limitan la selección del lenguaje. •Desarrollado res. •Usuarios finales.. El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo.Clase 4 13 Ingeniería de Requerimientos Los requerimientos son la descripción de: El proceso de determinación de los Requerimientos Extracción y Análisis de Requerimientos Analizar el problema •Entrevistar •¿Capturamos todo lo que el usuario necesita? ¿Hay contradicciones?. El proceso de Extracción y Análisis de Requerimientos 1. Definición y Especificación de Requerimientos Documenta ción y Validación ¿Hemos capturado todo lo que el usuario espera? Ingeniería de Requerimientos (IR) – es el proceso de Describir el problema •Documentar. Usuarios y factores humanos. usar prototipos. Verificar los requerimientos. hacer demostraciones. Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. Análisis y Diseño de Sistemas . Documentación. a Vamos r trabaja en la ia mater 3.Cuatrimestre de 2007. Para su estudio debe remitirse a la bibliografía.Clase 4 17 Elegir descripciones matemáticas o gráficas. Opcionalmente podrán efectuar pedidos de compra por uno más libros. •Usar técnicas. •Verificar con el usuario. Fases del proceso de extracción de requerimientos Trabajar con clientes y usuarios del sistema para extraer los requerimientos. 3 . Datos. Ver Apéndice. Etc. analizar. 15 los servicios que debe proveer el sistema y sus restricciones operativas. sin embargo se requiere que los clientes compradores se registren previamente. Incluye formular preguntas.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Prototipos y pruebas ¿Responde a las necesidades? encontrar. título o área de interés. autor. Los clientes podrán consultar el catálogo de libros disponibles. documentar y chequear los requerimientos Análisis y Diseño de Sistemas . Documentar los requerimientos. Contarán con mecanismos de búsqueda por ISBN. Interfaces.Clase 4 18 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas .Clase 4 Análisis y Diseño de Sistemas . Los requerimientos deben ser documentados y revisados con el cliente para comprobar exactitud y completitud. El objetivo primario de la extracción de los requerimientos: la comprensión de lo que los clientes y usuarios esperan que haga el sistema. Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB) Requerimientos . 2.Clase 4 16 Extracción de Requerimientos La extracción de requerimientos tiene lugar después de que es aceptado el estudio de factibilidad. etc. Encontrar requerimientos funcionales y no funcionales Los requerimientos también se pueden encontrar y ordenar según el tipo de requerimiento: Ambiente físico. Validar si son completos.Clasificación La funcionalidad será de uso público.Clase 4 14 Análisis y Diseño de Sistemas . exactos y consistentes. Contar con un libreta de direcciones. Estudiando el comportamiento de sistemas similares. Análisis y Diseño de Sistemas . Resulta útil organizar a los requerimientos en: ¿Por qué es útil organizar los requerimientos en mandatorios.Clase 4 21 Desarrollos Evolutivo Análisis y Diseño de Sistemas . Mostrar los mensajes con distinto color según una jerarquía de remitentes. Para su estudio debe remitirse a la bibliografía. Fijar roles en el equipo: secretario de actas. Documentar las relaciones entre ellos. deseables. etc.Clase 4 22 Ejemplo Consejos Prácticos – Entrevistas Consejos para la conducción de entrevistas Estudiar previamente el dominio del problema. Desarrollando prototipos. controlador de tiempos. moderador. se eliminan los requerimientos no prioritarios y se negocian los requerimientos deseables. Es importante desglosar el problema en piezas más pequeñas más fáciles de comprender.Clase 4 20 Análisis de requerimientos Mandatorios.Clase 4 19 Análisis y Diseño de Sistemas . En la etapa de análisis del problema se trabaja para: Se trabaja con el cliente y los usuarios para identificar los requerimientos del sistema: Identificar las personas. Concertar la entrevista por anticipado e indicar la duración. Seleccionar a las personas que se va a entrevistar. los procesos y recursos involucrados. Estudiando el sistema actual: puntos fuertes y puntos débiles. Documentar todas las decisiones tomadas.Clase 4 23 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Determinar el objetivo y contenido de la entrevista. Requerimientos deseables: Requerimientos no prioritarios: Análisis y Diseño de Sistemas . Dada una aplicación para proveer servicios de correo electrónico: Requerimientos mandatorios: Facilidades para enviar y recibir mensajes. Ser puntual – Respetar tiempos. deseables y no prioritarios? Requerimientos que deben ser absolutamente satisfechos (mandatorios). Formulando preguntas: entrevistar a los distintos usuarios del sistema.Cuatrimestre de 2007. etc. pero que podrían eliminarse (no prioritarios).Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 4 24 Estas transparencias proveen sólo una referencia a los temas. Requerimientos que son muy deseables pero no indispensables (deseables). Requerimientos que son posibles. un principio fundamental para la resolución de problemas. crear nuevos mensajes. Cuando el proyecto está restringido en tiempo y recursos. 4 . Sirve para que los participantes comprendan lo que realmente se necesita. Estudiar el Problema Estudiar el Problema La extracción de requerimientos es crítica: se debe analizar el problema antes de considerar cualquier solución posible. facilidades filtrar mensajes. responder mensajes. no prioritarios Se interroga a las personas involucradas y se intenta determinar el límite del sistema. Trabajar en el ámbito del usuario para comprender el contexto. Análisis y Diseño de Sistemas . por lo que la especificación en lenguaje natural no se aconseja por los siguientes problemas: Falta de claridad: el lenguaje natural no es preciso. Es demasiado flexible: existen muchas maneras de decir lo mismo. Req_del_sistema A veces un único documento sirve para ambos propósitos.Clase 4 29 Confía que lectores y escritores usan las mismas palabras para los mismos conceptos. Consensuar próximos pasos. La extracción y el análisis permiten escribir la especificación de requerimientos (términos técnicos.Clase 4 30 Estas transparencias proveen sólo una referencia a los temas. pantallas. pero Req_del_usuario relacionados: La extracción permite escribir un documento de definición de requerimientos (términos que el cliente entiende). Para su estudio debe remitirse a la bibliografía. ¿Describe cada requerimiento algo que es necesario? Existen requerimientos que se puedan eliminar ¿Los requerimientos son verificables? Se necesitan pruebas que los demuestren 27 La extracción y el análisis del problema sirve a dos propósitos diferentes. Usar lenguaje claro y simple. acompañado de tablas.Clase 4 Análisis de requerimientos Documentos de requerimientos ¿Los requerimientos son correctos? Cliente y analista deben revisarlos.Clase 4 26 Durante la entrevista: Mantener la entrevista en foco. Solicitar ejemplos de documentos fuentes. Entrevistar a los usuarios actuales y potenciales. Investigar los documentos existentes. Es difícil de modularizar y de mantener los documentos actualizados.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. ¿Los requerimientos son consistentes? No poseen inconsistencia ni ambigüedades. Análisis y Diseño de Sistemas . Problemas de los requerimientos de usuario: Documentar Requerimientos Requerimientos del sistema: Son más detallados que los requerimientos de usuario. Requerimientos compuestos: varios requerimientos se expresan como un único requerimiento Análisis y Diseño de Sistemas . Definir compromisos. que habilita el diseño del sistema). Consejos prácticos – Entrevistas Consejos Prácticos Consejos para la de extracción y análisis de requerimientos: Revisar la situación actual. Observar las estructuras y los patrones. Al finalizar. Confusión entre requerimientos funcionales y no funcionales.Clase 4 Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Realizar lluvia de ideas con los usuarios actuales y potenciales. ¿Los requerimientos son completos? Se consideraron todos los estados. Realizar demostraciones de cómo podría funcionar el sistema. los problemas y las relaciones. entradas. productos y restricciones. salidas del sistema. formularios y diagramas intuitivos. Análisis y Diseño de Sistemas . 5 .Clase 4 28 Documentar requerimientos Requerimientos del Usuario Deben describir los requerimientos funcionales y no funcionales de manera entendible para el usuario y sin especificar conocimiento técnico. leer las conclusiones. 25 Análisis y Diseño de Sistemas . ¿Los requerimientos son realistas? Es posible cumplir con los requerimientos. título o área de interés Análisis y Diseño de Sistemas . Autor y Fecha. Términos definidos en el Glosario. autor. Para su estudio debe remitirse a la bibliografía. Registrar pedidos de compra: el usuario ingresará el o los libros que desea adquirir.Clase 4 33 Ejemplo: Requerimiento del usuario Definición de requerimientos de usuario 1. sin embargo se requiere que los clientes compradores se registren previamente. Opcionalmente podrán efectuar pedidos de compra por uno más libros.Clase 4 31 Análisis y Diseño de Sistemas .Clase 4 32 Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB) Objetivo: proveer el servicio venta de libros vía Internet. Ingresar al sistema: los usuarios registrados podrán ingresar al sistema proveyendo su identificación y contraseña. Categoría. Los clientes podrán consultar el catálogo de libros disponibles. Vamos ar trabaj la en Especificaciones matemáticas: notaciones materia basadas en conceptos matemáticos. como máquinas de estados o conjuntos. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . 6 . Lenguaje natural Estructurado Usar notación gráfica: usar un lenguaje gráfico acompañado con texto para definir los requerimientos del sistema. título o área de interés. diagramas de a secuencia. Patrón para documentar requerimientos: los requerimientos deben contar con las siguientes secciones: Ventajas de usar Patrones: Ejemplos: diagramas de casos de uso.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Aseguran la descripción completa de los requerimientos. El sistema guarda el pedido e informa al cliente el número de transacción. Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. Es más simple de mantener. Normalizan la forma de trabajo. El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo. Para ello contarán con mecanismos de búsqueda por ISBN. Los clientes podrán consultar el catálogo de libros disponibles.Clase 4 36 Análisis y Diseño de Sistemas .Notación Algunas variantes de notación: Lenguaje natural estructurado: definir patrones para expresar la especificación de requerimientos.Clase 4 34 Ejemplo: Requerimiento del Sistema Ejemplo: Requerimientos Funcionales Registrar nuevos clientes: el sistema pedirá datos personales al cliente que se mantendrán en un repositorio de clientes. Contarán con mecanismos de búsqueda por ISBN. Requerimientos del sistema . Descripción detallada.Cuatrimestre de 2007. Consultar libros: los usuarios tendrán acceso a consultar libros disponibles por distintos parámetros de búsqueda.Clase 4 35 Estas transparencias proveen sólo una referencia a los temas. Descripción: La funcionalidad será de uso público. autor. Prioridad. Análisis y Diseño de Sistemas . Problema: son más difíciles de usar con los usuarios Identificador. Procesar pedidos del día: la base de pedidos del día se envía al sistema de ventas. Descripción corta. Objetivos. Clasificación: funcionales y no funcionales.Clase 4 42 Estas transparencias proveen sólo una referencia a los temas. Documentación. Recursos. Interfaces. Análisis y Diseño de Sistemas . debe definirse una interfaz capaz de comunicarse con el Sistema de pedidos por gestión. Debe ser capaz de atender 100 usuarios concurrentemente consultando y/o cargando pedidos correctamente.Clase 4 37 Análisis y Diseño de Sistemas . El proceso de extracción de requerimientos.Clase 4 41 Interfaces ¿Quién usará el sistema? ¿Habrá varios tipos de usuarios? ¿Cuál es el nivel de habilidad de cada tipo de usuario? ¿Qué clase de entrenamiento requerirá cada tipo de usuario? ¿Cuán fácil le será a un usuario comprender y utilizar el sistema? ¿Cuán difícil le resultará a un usuario hacer un uso indebido del sistema? Análisis y Diseño de Sistemas . Aseguramiento de la calidad. incluyendo los siguientes aspectos: Requerimientos Requerimientos. Capítulos 6 y 7.Cuatrimestre de 2007.Clase 4 38 Temas de la clase de hoy Apéndice Tipos de Requerimientos Los documentos de definición y especificación de requerimientos describen cómo el sistema interactúa con su ambiente. Debe trabajar conectado al servidor de base de datos con el que están conectadas el resto de las aplicaciones. Capítulos 1 y 4. Fases. Para su estudio debe remitirse a la bibliografía. Usuarios y factores humanos. Ingeniería de Software – I. Ambiente físico. Ejemplo Ingeniería de Software -Teoría y práctica – Shari L. 8va.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 4 40 Ambiente físico e Interfaces Usuarios y factores humanos Ambiente Físico ¿Dónde está el equipamiento que necesita el sistema para funcionar? ¿Existe una localización o varias? ¿Existen restricciones ambientales: temperatura.Clase 4 39 Bibliografía. En relación con el subsistema de pedidos por Internet. Funcionalidad. Pfleeger. o interferencia magnética? ¿La entrada proviene de uno o más sistemas? ¿La salida va a uno o más sistemas? ¿Existe una manera prescripta en que deben formatearse los datos? ¿Existe un medio prescripto que los datos deban utilizar? Análisis y Diseño de Sistemas . Sommerville. Análisis de Requerimientos Requerimientos no funcionales ¿Están todos los requerimientos funcionales definidos? ¿Se le ocurre algún otro requerimiento funcional? El sistema VEMB vía Internet debe cumplir con las siguientes restricciones: Debe funcionar las 24 hs. Análisis y Diseño de Sistemas . Documentación de requerimientos. 7 . del usuario y del sistema. Edición. Análisis y Diseño de Sistemas . Datos. Seguridad. Debe ser capaz de correr en las plataformas más comunes disponibles en el mercado. humedad. .Clase 4 44 Recursos Seguridad ¿Qué recursos materiales. utilizar y mantener el sistema? ¿Qué habilidades deben tener los desarrolladores? ¿Cuánto espacio físico será ocupado por el sistema? ¿Cuáles son los requerimientos de energía. tiempo de respuesta o rendimiento? ¿Cuánta documentación se requiere? ¿Debe estar en línea. seguridad. y los restantes atributos de calidad? ¿Cómo deben demostrarse las características del sistema a terceros? ¿Debe el sistema detectar y aislar defectos? ¿Cuál es el promedio de tiempo prescripto entre fallas? ¿Cómo puede el sistema incorporar los cambios al diseño? ¿El mantenimiento sólo corregirá errores o incluirá evolución? Análisis y Diseño de Sistemas . ¿Cuáles son los requerimientos para la confiabilidad.Clase 4 48 Estas transparencias proveen sólo una referencia a los temas. o el robo? Análisis y Diseño de Sistemas . disponibilidad. facilidad de mantenimiento.Clase 4 47 ¿Existe un tiempo máximo permitido para la recuperación del sistema después de una falla? ¿Qué medidas de eficiencia se aplicarán al uso de recursos y al tiempo de respuesta? ¿Cuán fácil debe ser de mover el sistema de una ubicación a otra o de un tipo de computadora a otra? Análisis y Diseño de Sistemas . calefacción o acondicionamiento de aire? ¿Existe un cronograma prescripto para el desarrollo? ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware o en software? ¿Debe controlarse el acceso al sistema o a la información? ¿Cómo se podrán aislar los datos de un usuario de los de otros? ¿Cómo podrán aislarse los programas de usuario de los otros programas y del sistema operativo? ¿Con qué frecuencia deben hacerse las copias de respaldo? ¿Dónde se almacenarán las copias de respaldo? ¿Se deben tomar precauciones contra el fuego. o en ambos? ¿A qué audiencia está orientado cada tipo de información? Análisis y Diseño de Sistemas . el daño provocado por agua.Clase 4 46 Aseguramiento de la calidad Aseguramiento de la calidad . en papel.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. personales o de otro tipo se requieren para construir. 8 .. Funcionalidad y Documentación Datos Funcionalidad ¿Qué hará el sistema? ¿Cuándo lo hará? ¿Existen varios modos de operación? ¿Cómo y cuándo se puede cambiar o mejorar un sistema? ¿Existen restricciones de la velocidad de ejecución. Para su estudio debe remitirse a la bibliografía.Clase 4 43 Documentación ¿Cuál será el formato de los datos tanto para entrada como para salida? ¿Cuán a menudo serán recibidos o enviados? ¿Cuán exactos deben ser? ¿Con qué grado de precisión deben hacerse los cálculos? ¿Cuántos datos fluyen a través del sistema? ¿Debe retenerse algún dato por algún período de tiempo? Análisis y Diseño de Sistemas .Cuatrimestre de 2007.Clase 4 45 Análisis y Diseño de Sistemas . . Es más un proceso de requerimientos mediocre puede en realidad resultar muy caro.9%). La falta de cuidado en la comprensión.. Expectativas no realistas (9.Clase 4 6 Estas transparencias proveen sólo una referencia a los temas. Notemos que cierta parte de las etapas de la extracción. Fin de la necesidad del sistema (7.. 1 . María Mercedes Vitturini 1er. puede costar 5$ repararlo durante el diseño.Clase 4 5 ¿Por qué son importantes los requerimientos? (lectura) .Clase 4 4 ¿Por qué son importantes los requerimientos? (lectura) . Para comprender el por qué. Falta de compromiso del usuario (12.Cuatrimestre de 2007. y obtener los requerimientos correctos desde el primer momento.1%). Una descripción de algo que el sistema es capaz de hacer con el objeto de satisfacer el propósito de usuarios y clientes. en las grandes compañías. Para su estudio debe remitirse a la bibliografía.1%). usualmente expresado como algo que el sistema debe hacer. Conclusión – es rentable tomarse el tiempo que sea necesario para comprender el problema y su contexto.4%). Falta de soporte ejecutivo (9. Requerimientos y especificaciones cambiantes (8. 16% satisfizo esto. En el trabajo de Boehm y Papaccio se consigna que si cuesta 1$ localizar y subsanar un problema debido a requerimientos. la definición.Clase 4 3 Análisis y Diseño de Sistemas . Es más. Requerimientos Análisis y Diseño de Sistemas Clase 4 – Ingeniería de Requerimientos Cada sistema basado en software tiene un propósito. el ¿Por qué son importantes los requerimientos? (lectura) .. Análisis y Diseño de Sistemas . 20$ durante la prueba unitaria. 157 Análisis y Diseño de Sistemas . 10$ durante la codificación. que no funciona como se espera. y hasta 200$ después de la entrega del sistema.6%). Análisis y Diseño de Sistemas . Falta de recursos (10. durante la etapa de definición.3%). la documentación y la gestión de los requerimientos puede llevar a una gran cantidad de problemas: construir un sistema que resuelve el problema equivocado. y la gestión del proceso de los requerimientos participaron en casi todas estas causas.. o que presenta dificultades para que los usuarios puedan comprenderlo y utilizarlo. CUATRIMESTRE 2007 Dpto. Standish (1995) pidió a los participantes en el estudio que explicaran las causas de los proyectos fallidos. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Una característica del sistema.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Los principales factores fueron: … Requerimientos incompletos (13. sólo el 9% de los proyectos fue entregado en término y dentro del costo presupuestados.5%). Los resultados son desencantadores: El 31% de los proyectos de software fueron cancelados antes de completarse. Ingeniería de Software – Shari Pfleeger – Pág.Clase 4 2 ¿Por qué son importantes los requerimientos? (lectura) En 1994 el Standish Group hizo un estudio sobre 350 compañías y cerca de 8000 proyectos de software para averiguar cómo les estaba yendo. en pequeñas empresas. Un requerimiento es: Lic. Falta de planeamiento (8..7%). Los principales factores fueron: … Análisis y Diseño de Sistemas . Se refieren al sistema como un todo.. Propósito de los requerimientos Requerimientos – Clasificación Los requerimientos sirven a distintos propósitos: Permiten que los analistas expliquen cómo han entendido lo que el cliente y usuarios pretende del sistema. Debe ser precisa. etc. Revisar que no existan conflictos. •Arquitectos del sistema Análisis y Diseño de Sistemas ..Clase 4 10 Requerimientos NO FUNCIONALES Identificar los Requerimientos Un requerimiento no funcional describe una restricción sobre el sistema que limita nuestras elecciones en la construcción de una solución al problema. •Usuarios finales.. Análisis y Diseño de Sistemas . Establecen para los desarrolladores la especificación del comportamiento del sistema. Indican a los testeadores qué demostraciones llevar a cabo para que el cliente se convenza de que el sistema que se le entrega es lo que había solicitado. Requerimientos del sistema: servicios y restricciones operativas en detalle: •Clientes gerentes •Usuarios finales •Arquitectos del sistema Corresponde con la especificación funcional.. Requerimientos NO Funcionales – Son las restricciones sobre los servicios o funciones ofrecidas por el sistema.Clase 4 7 Análisis y Diseño de Sistemas . sobre el proceso de desarrollo y estándares a respetar. Ejemplo: para un sistema de alumnos: ¿Cómo es que un alumno pierde su regulariadad? ¿Cuándo ocurre? ¿Se generan reportes? Análisis y Diseño de Sistemas .Clase 4 11 Estas transparencias proveen sólo una referencia a los temas.. Según el nivel de descripción los requerimientos se clasifican en: Requerimientos del usuario: sentencias en lenguaje natural más diagramas con los servicios que se espera que el sistema provea y las restricciones bajo las cuales debe operar.Clase 4 12 Análisis y Diseño de Sistemas . Incluyen restricciones de tiempo. •Desarrollado res.Clase 4 9 Requerimientos FUNCIONALES Un requerimiento funcional describe un servicio o una interacción entre el sistema y su ambiente. el informe debe salir después de 2 horas de. 2 .. Identificar necesidades funcionales.. cómo debe reaccionar ante los estímulos que recibe y cómo el sistema debe comportarse en situaciones particulares. la selección se realiza en la etapa de diseño. plataforma. Identificar actores (jugadores). Análisis y Diseño de Sistemas . las consultas en mostrador no deben demorar más de. Ejemplos: Cómo identificar requerimientos FUNCIONALES..Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Para su estudio debe remitirse a la bibliografía. Revisar que no existan conflictos.. El sistema debe funcionar en el servidor. Para determinar los requerimientos funcionales se deciden cuáles son los estados aceptables para el sistema. Describen cómo debe comportarse el sistema ante determinados estímulos. Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante.Clasificación Requerimientos Funcionales – Representan los servicios que el sistema debe proveer. Estas restricciones limitan la selección del lenguaje.Clase 4 8 Requerimientos .Cuatrimestre de 2007. Identificar necesidades no funcionales. sin embargo. Cómo identificar requerimientos NO FUNCIONALES. Fases del proceso de extracción de requerimientos Trabajar con clientes y usuarios del sistema para extraer los requerimientos. Documentación. Contarán con mecanismos de búsqueda por ISBN. Definición y Especificación de Requerimientos Documenta ción y Validación ¿Hemos capturado todo lo que el usuario espera? Ingeniería de Requerimientos (IR) – es el proceso de Describir el problema •Documentar. a Vamos r trabaja en la ia mater 3. •Usar técnicas. El proceso de Extracción y Análisis de Requerimientos 1. 2. Documentar los requerimientos. Verificar los requerimientos. analizar. hacer demostraciones. Etc. Análisis y Diseño de Sistemas . Prototipos y pruebas ¿Responde a las necesidades? encontrar. título o área de interés. Encontrar requerimientos funcionales y no funcionales Los requerimientos también se pueden encontrar y ordenar según el tipo de requerimiento: Ambiente físico. 15 los servicios que debe proveer el sistema y sus restricciones operativas. sin embargo se requiere que los clientes compradores se registren previamente. Usuarios y factores humanos. etc. Ver Apéndice. usar prototipos. El objetivo primario de la extracción de los requerimientos: la comprensión de lo que los clientes y usuarios esperan que haga el sistema. Datos. Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB) Requerimientos . Opcionalmente podrán efectuar pedidos de compra por uno más libros.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. exactos y consistentes. Los clientes podrán consultar el catálogo de libros disponibles. Análisis y Diseño de Sistemas . Los requerimientos deben ser documentados y revisados con el cliente para comprobar exactitud y completitud.Clase 4 16 Extracción de Requerimientos La extracción de requerimientos tiene lugar después de que es aceptado el estudio de factibilidad. Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. Validar si son completos.Cuatrimestre de 2007. 3 . autor.Clase 4 17 Elegir descripciones matemáticas o gráficas.Clase 4 Análisis y Diseño de Sistemas .Clasificación La funcionalidad será de uso público. Interfaces.Clase 4 18 Estas transparencias proveen sólo una referencia a los temas. Incluye formular preguntas. •Verificar con el usuario. documentar y chequear los requerimientos Análisis y Diseño de Sistemas .Clase 4 13 Ingeniería de Requerimientos Los requerimientos son la descripción de: El proceso de determinación de los Requerimientos Extracción y Análisis de Requerimientos Analizar el problema •Entrevistar •¿Capturamos todo lo que el usuario necesita? ¿Hay contradicciones?. Análisis y Diseño de Sistemas .Clase 4 14 Análisis y Diseño de Sistemas . El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo. Para su estudio debe remitirse a la bibliografía. deseables y no prioritarios? Requerimientos que deben ser absolutamente satisfechos (mandatorios). pero que podrían eliminarse (no prioritarios). Formulando preguntas: entrevistar a los distintos usuarios del sistema. Contar con un libreta de direcciones.Clase 4 22 Ejemplo Consejos Prácticos – Entrevistas Consejos para la conducción de entrevistas Estudiar previamente el dominio del problema.Clase 4 21 Desarrollos Evolutivo Análisis y Diseño de Sistemas . Cuando el proyecto está restringido en tiempo y recursos. no prioritarios Se interroga a las personas involucradas y se intenta determinar el límite del sistema. moderador. Requerimientos deseables: Requerimientos no prioritarios: Análisis y Diseño de Sistemas . Es importante desglosar el problema en piezas más pequeñas más fáciles de comprender. Documentar las relaciones entre ellos. Ser puntual – Respetar tiempos.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Determinar el objetivo y contenido de la entrevista. Documentar todas las decisiones tomadas. Estudiar el Problema Estudiar el Problema La extracción de requerimientos es crítica: se debe analizar el problema antes de considerar cualquier solución posible. los procesos y recursos involucrados.Clase 4 24 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. Análisis y Diseño de Sistemas . Requerimientos que son posibles.Clase 4 23 Análisis y Diseño de Sistemas . deseables. responder mensajes. 4 . Estudiando el sistema actual: puntos fuertes y puntos débiles. Resulta útil organizar a los requerimientos en: ¿Por qué es útil organizar los requerimientos en mandatorios.Clase 4 19 Análisis y Diseño de Sistemas . Concertar la entrevista por anticipado e indicar la duración. se eliminan los requerimientos no prioritarios y se negocian los requerimientos deseables. controlador de tiempos. etc. Análisis y Diseño de Sistemas . crear nuevos mensajes. Estudiando el comportamiento de sistemas similares. etc. Seleccionar a las personas que se va a entrevistar.Cuatrimestre de 2007. Desarrollando prototipos.Clase 4 20 Análisis de requerimientos Mandatorios. Dada una aplicación para proveer servicios de correo electrónico: Requerimientos mandatorios: Facilidades para enviar y recibir mensajes. Sirve para que los participantes comprendan lo que realmente se necesita. facilidades filtrar mensajes. Mostrar los mensajes con distinto color según una jerarquía de remitentes. Requerimientos que son muy deseables pero no indispensables (deseables). En la etapa de análisis del problema se trabaja para: Se trabaja con el cliente y los usuarios para identificar los requerimientos del sistema: Identificar las personas. Fijar roles en el equipo: secretario de actas. un principio fundamental para la resolución de problemas. Solicitar ejemplos de documentos fuentes. entradas. Realizar lluvia de ideas con los usuarios actuales y potenciales.Clase 4 29 Confía que lectores y escritores usan las mismas palabras para los mismos conceptos. Al finalizar. pantallas.Clase 4 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . productos y restricciones. 25 Análisis y Diseño de Sistemas . Consensuar próximos pasos. Realizar demostraciones de cómo podría funcionar el sistema. Definir compromisos. que habilita el diseño del sistema). Investigar los documentos existentes. Confusión entre requerimientos funcionales y no funcionales.Clase 4 30 Estas transparencias proveen sólo una referencia a los temas. Es demasiado flexible: existen muchas maneras de decir lo mismo. formularios y diagramas intuitivos. ¿Los requerimientos son completos? Se consideraron todos los estados. Entrevistar a los usuarios actuales y potenciales.Clase 4 28 Documentar requerimientos Requerimientos del Usuario Deben describir los requerimientos funcionales y no funcionales de manera entendible para el usuario y sin especificar conocimiento técnico. Observar las estructuras y los patrones.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas .Clase 4 Análisis de requerimientos Documentos de requerimientos ¿Los requerimientos son correctos? Cliente y analista deben revisarlos. por lo que la especificación en lenguaje natural no se aconseja por los siguientes problemas: Falta de claridad: el lenguaje natural no es preciso.Clase 4 26 Durante la entrevista: Mantener la entrevista en foco. Trabajar en el ámbito del usuario para comprender el contexto. Es difícil de modularizar y de mantener los documentos actualizados. acompañado de tablas. pero Req_del_usuario relacionados: La extracción permite escribir un documento de definición de requerimientos (términos que el cliente entiende). salidas del sistema. La extracción y el análisis permiten escribir la especificación de requerimientos (términos técnicos. ¿Los requerimientos son consistentes? No poseen inconsistencia ni ambigüedades. Consejos prácticos – Entrevistas Consejos Prácticos Consejos para la de extracción y análisis de requerimientos: Revisar la situación actual. Problemas de los requerimientos de usuario: Documentar Requerimientos Requerimientos del sistema: Son más detallados que los requerimientos de usuario. Req_del_sistema A veces un único documento sirve para ambos propósitos. leer las conclusiones.Cuatrimestre de 2007. los problemas y las relaciones. ¿Los requerimientos son realistas? Es posible cumplir con los requerimientos. ¿Describe cada requerimiento algo que es necesario? Existen requerimientos que se puedan eliminar ¿Los requerimientos son verificables? Se necesitan pruebas que los demuestren 27 La extracción y el análisis del problema sirve a dos propósitos diferentes. Usar lenguaje claro y simple. 5 . Para su estudio debe remitirse a la bibliografía. Requerimientos compuestos: varios requerimientos se expresan como un único requerimiento Análisis y Diseño de Sistemas . Categoría. Es más simple de mantener. Consultar libros: los usuarios tendrán acceso a consultar libros disponibles por distintos parámetros de búsqueda. Normalizan la forma de trabajo. Términos definidos en el Glosario. Ingresar al sistema: los usuarios registrados podrán ingresar al sistema proveyendo su identificación y contraseña. título o área de interés. 6 . Los pedidos de compras confirmados serán remitidos al final de cada día al departamento de ventas y notificados de su recepción al cliente vía mail. El cliente podrá cancelar el pedido de compra en cualquier momento antes de confirmarlo. Contarán con mecanismos de búsqueda por ISBN. Aseguran la descripción completa de los requerimientos. diagramas de a secuencia. autor.Cuatrimestre de 2007. Para ello contarán con mecanismos de búsqueda por ISBN. Problema: son más difíciles de usar con los usuarios Identificador.Notación Algunas variantes de notación: Lenguaje natural estructurado: definir patrones para expresar la especificación de requerimientos. título o área de interés Análisis y Diseño de Sistemas . Opcionalmente podrán efectuar pedidos de compra por uno más libros. Requerimientos del sistema . como máquinas de estados o conjuntos. Análisis y Diseño de Sistemas .Clase 4 31 Análisis y Diseño de Sistemas . Lenguaje natural Estructurado Usar notación gráfica: usar un lenguaje gráfico acompañado con texto para definir los requerimientos del sistema. Descripción: La funcionalidad será de uso público. Descripción corta. autor.Clase 4 32 Ejemplo: Venta Electrónica de Material Bibliográfico (VEMB) Objetivo: proveer el servicio venta de libros vía Internet. Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. Prioridad. Vamos ar trabaj la en Especificaciones matemáticas: notaciones materia basadas en conceptos matemáticos. Los clientes podrán consultar el catálogo de libros disponibles.Clase 4 36 Análisis y Diseño de Sistemas .Clase 4 35 Estas transparencias proveen sólo una referencia a los temas. Autor y Fecha.Clase 4 34 Ejemplo: Requerimiento del Sistema Ejemplo: Requerimientos Funcionales Registrar nuevos clientes: el sistema pedirá datos personales al cliente que se mantendrán en un repositorio de clientes. Procesar pedidos del día: la base de pedidos del día se envía al sistema de ventas. Análisis y Diseño de Sistemas . Patrón para documentar requerimientos: los requerimientos deben contar con las siguientes secciones: Ventajas de usar Patrones: Ejemplos: diagramas de casos de uso. El sistema guarda el pedido e informa al cliente el número de transacción.Clase 4 33 Ejemplo: Requerimiento del usuario Definición de requerimientos de usuario 1. Registrar pedidos de compra: el usuario ingresará el o los libros que desea adquirir.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Los clientes podrán consultar el catálogo de libros disponibles. Descripción detallada. sin embargo se requiere que los clientes compradores se registren previamente. Debe ser capaz de atender 100 usuarios concurrentemente consultando y/o cargando pedidos correctamente. Ingeniería de Software – I. Análisis de Requerimientos Requerimientos no funcionales ¿Están todos los requerimientos funcionales definidos? ¿Se le ocurre algún otro requerimiento funcional? El sistema VEMB vía Internet debe cumplir con las siguientes restricciones: Debe funcionar las 24 hs. Edición. 8va. Ambiente físico. Fases. Objetivos.Clase 4 41 Interfaces ¿Quién usará el sistema? ¿Habrá varios tipos de usuarios? ¿Cuál es el nivel de habilidad de cada tipo de usuario? ¿Qué clase de entrenamiento requerirá cada tipo de usuario? ¿Cuán fácil le será a un usuario comprender y utilizar el sistema? ¿Cuán difícil le resultará a un usuario hacer un uso indebido del sistema? Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Análisis y Diseño de Sistemas . Interfaces. humedad.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Recursos.Clase 4 39 Bibliografía. Funcionalidad.Clase 4 42 Estas transparencias proveen sólo una referencia a los temas. Aseguramiento de la calidad. Ejemplo Ingeniería de Software -Teoría y práctica – Shari L. Seguridad. Capítulos 6 y 7. Pfleeger. Clasificación: funcionales y no funcionales. Capítulos 1 y 4. El proceso de extracción de requerimientos. Debe ser capaz de correr en las plataformas más comunes disponibles en el mercado. Debe trabajar conectado al servidor de base de datos con el que están conectadas el resto de las aplicaciones. Para su estudio debe remitirse a la bibliografía.Clase 4 37 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . o interferencia magnética? ¿La entrada proviene de uno o más sistemas? ¿La salida va a uno o más sistemas? ¿Existe una manera prescripta en que deben formatearse los datos? ¿Existe un medio prescripto que los datos deban utilizar? Análisis y Diseño de Sistemas . Datos.Clase 4 38 Temas de la clase de hoy Apéndice Tipos de Requerimientos Los documentos de definición y especificación de requerimientos describen cómo el sistema interactúa con su ambiente. Usuarios y factores humanos. 7 . debe definirse una interfaz capaz de comunicarse con el Sistema de pedidos por gestión. incluyendo los siguientes aspectos: Requerimientos Requerimientos. Documentación de requerimientos. Sommerville. Documentación. En relación con el subsistema de pedidos por Internet.Clase 4 40 Ambiente físico e Interfaces Usuarios y factores humanos Ambiente Físico ¿Dónde está el equipamiento que necesita el sistema para funcionar? ¿Existe una localización o varias? ¿Existen restricciones ambientales: temperatura. Análisis y Diseño de Sistemas . del usuario y del sistema. seguridad. disponibilidad. calefacción o acondicionamiento de aire? ¿Existe un cronograma prescripto para el desarrollo? ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware o en software? ¿Debe controlarse el acceso al sistema o a la información? ¿Cómo se podrán aislar los datos de un usuario de los de otros? ¿Cómo podrán aislarse los programas de usuario de los otros programas y del sistema operativo? ¿Con qué frecuencia deben hacerse las copias de respaldo? ¿Dónde se almacenarán las copias de respaldo? ¿Se deben tomar precauciones contra el fuego. Funcionalidad y Documentación Datos Funcionalidad ¿Qué hará el sistema? ¿Cuándo lo hará? ¿Existen varios modos de operación? ¿Cómo y cuándo se puede cambiar o mejorar un sistema? ¿Existen restricciones de la velocidad de ejecución. o en ambos? ¿A qué audiencia está orientado cada tipo de información? Análisis y Diseño de Sistemas .Clase 4 46 Aseguramiento de la calidad Aseguramiento de la calidad . en papel.Clase 4 47 ¿Existe un tiempo máximo permitido para la recuperación del sistema después de una falla? ¿Qué medidas de eficiencia se aplicarán al uso de recursos y al tiempo de respuesta? ¿Cuán fácil debe ser de mover el sistema de una ubicación a otra o de un tipo de computadora a otra? Análisis y Diseño de Sistemas ..Clase 4 48 Estas transparencias proveen sólo una referencia a los temas. facilidad de mantenimiento.Clase 4 43 Documentación ¿Cuál será el formato de los datos tanto para entrada como para salida? ¿Cuán a menudo serán recibidos o enviados? ¿Cuán exactos deben ser? ¿Con qué grado de precisión deben hacerse los cálculos? ¿Cuántos datos fluyen a través del sistema? ¿Debe retenerse algún dato por algún período de tiempo? Análisis y Diseño de Sistemas . y los restantes atributos de calidad? ¿Cómo deben demostrarse las características del sistema a terceros? ¿Debe el sistema detectar y aislar defectos? ¿Cuál es el promedio de tiempo prescripto entre fallas? ¿Cómo puede el sistema incorporar los cambios al diseño? ¿El mantenimiento sólo corregirá errores o incluirá evolución? Análisis y Diseño de Sistemas . ¿Cuáles son los requerimientos para la confiabilidad. 8 . o el robo? Análisis y Diseño de Sistemas . el daño provocado por agua.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. utilizar y mantener el sistema? ¿Qué habilidades deben tener los desarrolladores? ¿Cuánto espacio físico será ocupado por el sistema? ¿Cuáles son los requerimientos de energía.. personales o de otro tipo se requieren para construir. tiempo de respuesta o rendimiento? ¿Cuánta documentación se requiere? ¿Debe estar en línea. Para su estudio debe remitirse a la bibliografía.Clase 4 44 Recursos Seguridad ¿Qué recursos materiales.Clase 4 45 Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Metodologías de Desarrollo Análisis y Diseño de Sistemas Clase 5 – Ingeniería de Requerimientos – El modelo de Casos de Uso Lic. María Mercedes Vitturini 1er. CUATRIMESTRE 2007 Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur A lo largo del tiempo se han desarrollado distintas metodologías para encarar el desarrollo de un sistema. En este curso vamos a estudiar: Metodologías Orientadas a Objetos. El Proceso Unificado de Desarrollo de Software (Rumbaugh, Booch, Jacobson) Metodología OMT (J. Rumbaugh) Metodología de Eduard Yourdon. Método RAISE. mos Esta í aqu Metodologías Estructuradas. Metodología Rigurosa/Formales Análisis y Diseño de Sistemas - Clase 5 2 Metodología Orientado a Objetos UML Objetivo: proveer métodos, técnicas y herramientas que colaboren con la descripción del software y sus características para satisfacer los requisitos definidos por el cliente y los usuarios. El Proceso de Unificado de Desarrollo de Software: un enfoque unificado de modelado siguiendo la metodología Orientada a Objetos propuesta por: G. Booch, J.Rumbaugh y I. Jacobson: El lenguaje de modelado que unifica las ideas de los métodos más reconocidos de Ingeniería de Software Orientada a Objetos. Objetivos: Modelar sistemas siguiendo el enfoque OO. Cubrir diferentes tipos y tamaños de sistemas. Crear un lenguaje de modelado que pueda ser utilizado por personas y máquinas. Lenguaje de Modelado Unificado (UML) UML permite expresar un modelo de análisis con notación de modelado formada por reglas sintácticas y semánticas. UML es un lenguaje que sirve para visualizar, especificar, construir y documentar sistemas. Análisis y Diseño de Sistemas - Clase 5 3 Análisis y Diseño de Sistemas - Clase 5 4 Vistas de un Sistema Vistas de un sistema Un modelo es una representación abstracta de un problema. Los modelos de IS representan distintas vistas de un problema: Otras vistas del problema que están fuera del alcance de este curso son: Vista del usuario: representa un sistema (producto) desde la vista del usuario (actor). Se modela con casos de uso. Vista estructural: modela la estructura estática (clases, objetos y relaciones). Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. Muestra las interacciones entre los elementos estructurales. Análisis y Diseño de Sistemas - Clase 5 5 Vista de implementación: representa cómo van a ser implementados los aspectos estructurales y de comportamiento. Vista del entorno: aspectos estructurales y de comportamiento en el que el sistema a implementar se representa. Análisis y Diseño de Sistemas - Clase 5 6 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 1 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Modelo de Casos de Uso - Introducción Modelo de Casos de Uso (MCU) El Modelo de Caso de Uso describe la funcionalidad total del sistema Los Casos de Uso fueron creados por Jacobsen e integrados al Proceso Unificado de Desarrollo de Software. Modelan la vista del sistema que representa la vista del usuario y de comportamiento. Todos los casos de uso juntos constituyen el Modelo de Caso de Uso Es uno de los modelos provistos por UML. Modela la funcionalidad y entorno de un sistema. El Proceso Unificado define al Modelo de Casos de Uso en la disciplina de requerimientos. Análisis y Diseño de Sistemas - Clase 5 8 Requerimientos – Repaso Requerimientos Funcionales Req. no funcional. Req. funcional Un requerimiento es: Una característica del sistema. Una descripción de algo que el sistema es capaz de hacer. El mayor esfuerzo de requerimientos es desarrollar un modelo del sistema a construir: Utilizar casos de uso. Los casos de uso se emplean para: Durante la actividad de Análisis y Especificación los requerimientos del sistema deben ser: Capturar el comportamiento deseado del sistema. Identificar interacciones individuales con el sistema. Identificar actores y las funcionalidades con las que trabajan. Especificados (y documentados) y revisados con el cliente. Lenguaje natural estructurado. Usar notación . Se sugiere usar alguna notación: gráfica. Los requerimientos funcionales están naturalmente estructurados como casos de uso. Análisis y Diseño de Sistemas - Clase 5 10 Análisis y Diseño de Sistemas - Clase 5 9 Casos de Uso Casos de Uso (CU) Características: Los CU se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin especificar cómo se va a implementar. Modelan el comportamiento de un elemento que puede ser un sistema, subsistema o una clase. Los casos de uso se crean con la captura de requerimientos, evolucionan en la medida que se adquiere conocimiento del sistema y se usan durante todo el proceso. Se dice que los CU Guían el proceso de desarrollo. Objetivos Definir los requisitos funcionales y operativos del sistema, diseñando un escenario de uso acordado entre el usuario y el equipo de desarrollo. Proporcionar una descripción clara y sin ambigüedades para el diseño. Proporcionar la base para la validación de las pruebas. Análisis y Diseño de Sistemas - Clase 5 11 Se presentan a diferentes niveles de abstracción. Modelan el sistema desde el punto de vista del usuario. Son conceptualmente simples de entender y resultan un buen medio de comunicación con el usuario. Análisis y Diseño de Sistemas - Clase 5 12 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 2 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. UML y el Modelo de Casos de Usos MCU – Componentes UML provee el Modelo de Casos de Uso para representar la vista del sistema que se corresponde con la vista del usuario. En UML la representación visual de los casos de uso es el diagrama de casos de uso (DCU) Las últimas tendencias de ingeniería de software orientadas a objetos hablan del “Proceso Unificado, dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental”. Análisis y Diseño de Sistemas - Clase 5 13 El diagrama de casos de uso (DCU) utiliza tres elementos básicos: Actores, para modelar los diferentes roles que los elementos externos al sistema pueden representar. Casos de uso, para representar todo aquello que el actor ha de poder realizar en el sistema. Relaciones, que vinculan a los elementos anteriores. El MCU se completa con la descripción de casos de uso, esto es, la especificación del comportamiento de cada uno de los casos de uso. Análisis y Diseño de Sistemas - Clase 5 14 Actores ión sentac Repre Actores El MCU describe qué hace el sistema para cada tipo de usuario. Cada uno de éstos se representa por uno o más actores. Un actor puede representar a una persona física, otro sistema, un dispositivo. Son terceros fuera del sistema y que colaboran con él. Un actor es como una clase, que se define por la descripción de su comportamiento. Un usuario puede desempeñar varios roles, esto es, puede actuar como diferentes actores. La identificación de actores, sirve para definir el contexto externo del sistema, esto es, delimitar los elementos que se encuentran fuera y dentro del sistema. Un actor juega un rol para cada caso de uso en el que colabora. Cada vez que un usuario concreto interactúa con el sistema, la instancia correspondiente de ese actor está jugando ese rol. Una instancia de un actor es un usuario específico interactuando con el sistema. Ejemplo: Juan Díaz puede cubrir el rol de cajero y cliente del banco para el que trabaja Análisis y Diseño de Sistemas - Clase 5 15 Análisis y Diseño de Sistemas - Clase 5 16 Actores – Ejemplos Casos de Uso cliente Repre sentac ión <nombre del CU> Actores de un sistema bancario: Cajero, cliente, gerente, sistema de tarjetas electrónicas, etc. Socio, empleado de atención al público, empleado catalogador, el director, etc. Cajero, vendedor, el sistema de stock, sistemas de tarjetas electrónicas, etc. Actores en un sistema de bibliotecas: Actores de un sistema de facturación: Los casos de uso son “trozos” de funcionalidad que el sistema ofrece para agregar un resultado de valor a sus actores. Representan las formas en la que los actores interactúan con el sistema. Un CU se constituye en una secuencia completa de mensajes que especifica la interacción que tiene lugar entre un actor y el sistema. El conjunto de todos los casos de uso describe la funcionalidad completa del sistema. Análisis y Diseño de Sistemas - Clase 5 18 Análisis y Diseño de Sistemas - Clase 5 17 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 3 El remitente decide cancelar el procedimiento antes de enviar el mensaje. La descripción debe ser clara para que alguien ajeno al equipo de desarrollo lo entienda. Algunos caminos o secuencias alternativas: Normalmente. Casos de Uso Imprimir Factura Ejemplo El diagrama de casos de uso se acompaña con la especificación o descripción de los CU que incluye: Descripción INFORMAL: CU – Enviar Mail Secuencia básica “armar el mensaje y enviarlo al servidor de correo para que lo distribuya a los destinatarios”. Al ejecutar una instancia de un CU.Clase 5 23 Análisis y Diseño de Sistemas . Debe incluir: En UML.Clase 5 21 Diagrama de actividades: describe el ciclo de vida en más detalle describiendo secuencia de acciones que ocurren en las transiciones. Estos diagramas se ven más adelante en este curso Análisis y Diseño de Sistemas .Clase 5 20 Descripción de CU <nombre del CU> Casos de Uso El comportamiento de un caso de uso se especifica describiendo un flujo de eventos en forma textual: descripción del caso de uso. solicita extraer $400. Diagramas de colaboración y de secuencia: describen la interacción entre una instancia del actor y una instancia del caso de uso. es la ejecución particular de un CU. Son las alternativas de secuencias de acción para el caso de uso.Clase 5 22 Casos de Uso <nombre del CU> Ejemplo Para el CU Extraer Dinero de un ATM Una instancia de un CU. Análisis y Diseño de Sistemas . Múltiples caminos son posibles. 4 .Clase 5 19 No existe el destinatario. Instancia #2: Juan ingresa su PIN.Clase 5 24 Estas transparencias proveen sólo una referencia a los temas. se rechaza la transacción por falta de fondos. el flujo básico y los flujos alternativos. Análisis y Diseño de Sistemas . en términos de estados y transiciones entre estados. Extraer Dinero ATM cliente Análisis y Diseño de Sistemas . se ejecuta una secuencia de acciones. <nombre del CU> cómo y cuándo empieza y se acaba el caso de uso. cuáles son las responsabilidades del sistema Análisis y Diseño de Sistemas . y pueden ser muy similares. obtiene el dinero.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. un CU tiene una única secuencia básica y uno o más secuencias alternativas. solicita extraer $100. Para su estudio debe remitirse a la bibliografía. Instancia #1: María ingresa su PIN. a través de la secuencia de mensajes más importantes. Las variantes o secuencias alternativas de mensajes (por ejemplo los posibles errores). cuándo interactúa con actores y qué objetos se intercambian. La descripción de la secuencia básica o comportamiento normal. según se especifica en el CU y siguiendo uno de los posibles caminos del CU. El mensaje debe ser enviado con alta prioridad. una descripción de CU puede incluir: Diagrama de estados: especifica el ciclo de vida de las instancias del CU. La asociación entre actores y CU se representa en el diagrama de casos de uso mediante una línea llena. Ejemplo: en el CU de Extraer Dinero. Tanto el padre como el hijo pueden tener instancias concretas. El nivel de abstracción se refina en la medida que se conoce al problema. Actores-Casos de Uso.Clase 5 27 Análisis y Diseño de Sistemas . es decir. sea ingresándole información o consumiendo los datos que provee el CU.Clase 5 25 Diagrama de CU – Relaciones Relación Actor . Análisis y Diseño de Sistemas . poniendo ese comportamiento en otros CU que lo extienden. extrayendo ese comportamiento común de los CU en que se incluye. pero sin interferencias. La generalización entre CU se representa por una línea continua con una punta de flecha vacía. Se piensa en las instancias de los CU como atómicas. Análisis y Diseño de Sistemas . Los atributos representan los valores que una instancia de un CU utiliza y maneja durante la ejecución. Los actores se “comunican” con los casos de uso. Significa que el CU hijo hereda el comportamiento y el significado del CU padre. Las instancias de los CU no interactúan entre sí. Análisis y Diseño de Sistemas . Casos de Uso Los casos de uso poseen atributos.Clase 5 29 Análisis y Diseño de Sistemas . Las relaciones pueden ser: Generalización Extensión. Modelo de Casos de Uso – Conceptos Avanzados La construcción del MCU responde a un proceso iterativo e incremental. inclusión y extensión entre ellos. que se ejecutan completamente o no. Estas relaciones sirven para: Entre distintos CU se puede establecer una relación de generalización.Clase 5 28 Organización del Diagrama de Casos de Uso Relaciones entre CU’s : Generalización Varios CU se pueden organizar especificando relaciones entre ellos de generalización. Casos de uso distintos. Número de cuenta. Los conflictos entre la ejecución de distintos CU simultáneamente se resuelven en la etapa de diseño. 5 . Inclusión.Caso de Uso Las relaciones o asociaciones identifican la comunicación o vínculo que existe entre: Actores distintos. Una asociación entre un actor y un caso de uso indica que ese actor “usa” el CU.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Factorizar variantes. Importe de la extracción.Clase 5 30 Estas transparencias proveen sólo una referencia a los temas. PIN. Para su estudio debe remitirse a la bibliografía. Factorizar el comportamiento común.Cuatrimestre de 2007. Generalización – Ejemplo Relaciones entre CU’s : Incluye Ejemplo: los CU´s Obtener Parámetros. Para su estudio debe remitirse a la bibliografía.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. La extensión puede verse como que CU que extiende incorpora su comportamiento en el CU base. Una relación de inclusión se representa como una dependencia estereotipada con la palabra <<include>>. Sirve para evitar describir el mismo flujo de eventos repetidas veces. Ejemplo: cliente Cliente minorista Análisis y Diseño de Sistemas .Clase 5 32 Análisis y Diseño de Sistemas .Clase 5 33 La relación de extensión se utiliza para: Modelar la parte de comportamiento que se ve como opcional.Clase 5 36 Estas transparencias proveen sólo una referencia a los temas. Incluye. Obtener Parámetros desde Archivo. La relación de inclusión significa que un CU base incorpora explícitamente el comportamiento de otro CU. que es compartida y aumentada por una o más descripciones específicas. Una relación de extensión se representa como una dependencia estereotipada con la palabra <<extend>>. 6 .Clase 5 31 Relaciones entre CU´s: Extiende Relaciones entre CU´s: Extiende Una relación de extensión entre CU´s significa que un CU base incorpora implícitamente el comportamiento de otro CU. Modelar un subflujo separado que se ejecuta sólo bajo determinadas condiciones. Modelar varios subflujos que se pueden insertar en un punto dado. Obtener Parámetros desde Pantalla. En la descripción del CU base se debe indicar el punto donde se realiza la inclusión. Análisis y Diseño de Sistemas .Clase 5 34 Ejemplo: Extiende. Generaliza Relaciones entre Actores: Generalización Generalización entre actores: organiza a los distintos actores. Análisis y Diseño de Sistemas .Clase 5 35 Cliente mayorista Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . indicando que una descripción abstracta del actor. Análisis y Diseño de Sistemas . 6. Actor Principal: el que recurre a los servicios. Curso Básico de Eventos: 1.Cuatrimestre de 2007. 4. Informar al cliente. 9.2 El cajero no cuenta con dinero.Clase 5 39 Análisis y Diseño de Sistemas . Precondiciones y Poscondiciones. Representa el camino correcto. El cliente ingresa su clave personal. También puede incluir: Personal involucrado. Continúa en 8.Clase 5 38 Descripción de CU .1 El cliente cancela la operación. 8. 3. El cliente ingresa el importe a extraer. El cliente ingresa su clave personal y el importe a extraer. Para su estudio debe remitirse a la bibliografía. Finalizar. Requisitos especiales.1 La cuenta no tiene dinero suficiente. Continúa en 9. Descripción Detallada del Análisis y Diseño de Sistemas . El sistema entrega la tarjeta. Resumen: Un cliente extrae dinero de un ATM.Clase 5 37 Organización de CU – Sistemas complejos Cuando el número de CU es considerable como para manejarlos en un único diagrama. Caminos Alternativos: muestra los caminos no tan comunes que se necesitan. 7 . Curso Básico de Eventos: describe los pasos que los actores y el sistema deberán realizar para lograr el objetivo del CU.Plantilla Descripción de CU – Plantilla Nombre: provee una identificación única. El sistema valida los datos y le entrega el dinero. UML propone agruparlos en paquetes. El conjunto de todos los casos de uso representa la funcionalidad completa del sistema en algún nivel de detalle.Clase 5 CU Extraer dinero ATM Estas transparencias proveen sólo una referencia a los temas. El sistema valida la clave. Caminos Alternativos: Caminos alternativos: 2. Reglas de negocio relacionadas. 4. El sistema entrega el dinero. comprobante y tarjeta. 2. Fecha: de creación/actualización.1 La clave es incorrecta.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Si el cliente se equivocó menos de tres veces Volver a 1 La clave es incorrecta. Frecuencia de ejecución Autor: responsable de la especificación. El importe no es válido.Clase 5 41 Sino Quitar tarjeta. Continúa en 3. El sistema valida la operación. 7. El cliente es un cliente válido Análisis y Diseño de Sistemas . Organización del DCU Resumiendo: El sistema involucra a un conjunto de actores y casos de uso. Los actores quedan fuera del rectángulo Análisis y Diseño de Sistemas . Precondición 5. El cliente confirma la operación 5. Informar al cliente. Descripción resumida: describe en una o dos oraciones las interacciones que ocurrirán en el CU. El sistema entrega el comprobante de la operación.Clase 5 40 Ejemplo: Descripción de CU CU Extraer dinero de ATM – Descripción Informal Curso básico de eventos: Nombre: Extraer dinero de un ATM. E J E M P L O 42 5. El diagrama de casos de uso se completa con un rectángulo que contiene a todos los casos de uso con el nombre del sistema. Cada paquete puede contener otros paquetes o varios CU. El cajero no tiene dinero. Continúa en 8. Análisis y Diseño de Sistemas . Incluyen situaciones en las que se requiere un procesamiento especial. El conjunto de todos los actores representa a todos los objetos a los que el sistema sirve. Capítulos 7 y 8.Cuatrimestre de 2007... Rumbaugh .Clase 5 43 Análisis y Diseño de Sistemas . Bibliografía Object-Oriented Modeling and Design with UML.Clase 5 45 Análisis y Diseño de Sistemas . cambiada o usada por los trabajadores cuando trabajan con el sistema. Jacobson.Clase 5 Trabajadores y Artefactos Trabajador: Analista de Sistemas Es responsable de . “El Proceso Unificado de Desarrollo de Software”.Capítulo 7. Temas de la clase de hoy Apéndice . Para cada trabajador se especifican las responsabilidades y habilidades requeridas. producida. Artefacto: es un término general para cualquier clase de descripción o información creada. Para su estudio debe remitirse a la bibliografía. Rumbaugh.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. UML y el Modelo de casos de uso. un elemento del modelo.Capítulos 16 y 17. 8 . Rumbaugh . El principal artefacto usado en la captura de requerimientos es el modelo de casos de uso (MCU). Blaha. Análisis y Diseño de Sistemas . Por ejemplo: un modelo. El Modelo Casos de uso Usos. Booch. etc. Trabajador: representa una posición que se puede asignar a una persona o equipo en una organización de desarrollo de software. Jacobson. Casos de Uso y Trabajadores Analista Busca actores y CU Estructura el MCU Arquitecto Prioriza CU Artefacto: Modelo de Casos de Uso Actores Glosario Especificador de CU Detalla un CU Diseñador de Interfaces Análisis y Diseño de Sistemas . M.Clase 5 Prototipea Interface Usuario 46 Estas transparencias proveen sólo una referencia a los temas. Booch. Vistas de un sistema. J.Terminología UML Metodologías del Desarrollo de Sistemas. “El Lenguaje Unificado de Modelado”. 44 Diagrama de Casos de Uso y Descripción de Casos de Uso. Clase 6 5 Análisis y Diseño de Sistemas . Como herramienta de comunicación con los trabajadores del negocio. casos de uso y sus relaciones.Clase 6 4 Análisis y Diseño de Sistemas . Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Los casos de uso se crean con la captura de requerimientos. Análisis y Diseño de Sistemas .Clase 5 2 Repaso Repaso UML provee el Modelo de Casos de Uso para representar la vista del sistema que se corresponde con la vista del usuario. Las relaciones identifican la comunicación que existe entre los elementos anteriores. Incluyen situaciones en las que se requiere un procesamiento especial. evolucionan en la medida que se adquiere conocimiento del sistema y se usan durante todo el proceso. Repaso . Caminos Alternativos: muestra los caminos no tan comunes que se necesitan. Actor Principal: el que recurre a los servicios. CUATRIMESTRE 2007 Dpto. Se dice que los CU Guían el proceso de desarrollo. Generalización-Especialización Usa. Definir la vista de la arquitectura de un sistema. Análisis y Diseño de Sistemas . Representa el camino correcto. extend Análisis y Diseño de Sistemas . diseñando un escenario de uso acordado entre el usuario y el equipo de desarrollo. include. di de de La especificación de las distintas posibilidades de comportamiento en la descripción de los casos de uso. Proporcionar una descripción clara y sin ambigüedades para el diseño. Descripción resumida: describe en una o dos oraciones las interacciones que ocurrirán en el CU. Para su estudio debe remitirse a la bibliografía. Proporcionar la base para la validación de las pruebas. para planificar iteraciones y priorizar casos de uso.Clase 5 6 Estas transparencias proveen sólo una referencia a los temas. Curso Básico de Eventos: describe los pasos que los actores y el sistema deberán realizar para lograr el objetivo del CU. María Mercedes Vitturini 1er. El modelo incluye: La representación visual de los casos de uso en el diagrama d casos d uso.Plantilla El modelo de casos de uso (MCU) sirve a los siguientes propósitos: Definir el alcance o contexto de problema.Clase 6 3 Modelo Casos de Uso Descripción de CU . Son terceros fuera del sistema que colaboran con él. Objetivos Definir los requisitos funcionales y operativos del sistema. otros sistemas o un dispositivo. determinar el contexto y que parte queda fuera del sistema. Un CU constituye una secuencia completa d mensajes que especifica i l t de j ifi la interacción que tiene lugar entre un actor y el sistema. Actores: representan a personas físicas. Casos de Uso: son “trozos” de funcionalidad que el sistema ofrece para agregar un resultado de valor a sus actores.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Nombre: provee una identificación única. 1 . Los elementos básicos para la construcción del DCU son: actores.Casos de Uso Análisis y Diseño de Sistemas Clase 6 – El modelo de Casos de Uso – Metodología para su construcción Lic. El cliente ingresa su clave personal. Si el cliente se equivocó menos de tres veces Volver a 1 Sino Quitar tarjeta. El sistema valida la operación. Describe el dominio desde la perspectiva de la clasificación de objetos: La identificación de los conceptos o clases y relaciones más significativas del dominio del problema. Captura la semántica del problema. E J E M P L O 9 Modelo de Conceptos de Negocio (MCN) Es una descripción del dominio como un conjunto de objetos relacionados 5. Continúa en 8. Continúa en 8. El sistema entrega el dinero.1 La cuenta no tiene dinero suficiente. 9. donde se presentan las clases del negocio o dominio del problema a resolver. La clave es incorrecta. 4.Clase 6 12 Análisis y Diseño de Sistemas .1 El cliente cancela la operación. Requisitos especiales.Clase 6 11 Estas transparencias proveen sólo una referencia a los temas. Personal involucrado.Cuatrimestre de 2007. sin especificar atributos ni operaciones. Resumen: Un cliente extrae dinero de un ATM. El sistema entrega la tarjeta. q p Frecuencia de ejecución CU Extraer dinero de ATM – Descripción Informal Curso básico de eventos: El cliente ingresa su clave personal y el importe a extraer. Finalizar. El cajero no tiene dinero. comprobante y tarjeta. 2.1 La clave es incorrecta. El cliente ingresa el importe a extraer. El sistema valida los datos y le entrega el dinero. 4. Para su estudio debe remitirse a la bibliografía.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Continúa en 9. Informar al cliente. Precondición Análisis y Diseño de Sistemas . El cliente confirma la operación 5.Clasedel CU Extraer dinero ATM Análisis del Dominio Durante el análisis existen dos estados: Modelo de Conceptos de Negocio (MCN) Análisis de Dominio Se enfoca en los objetos del mundo real. Curso Básico de Eventos: 1. 6. Análisis y Diseño de Sistemas . Análisis de la Aplicación Se ocupa de los aspectos tecnológicos de la aplicación que son visibles a los usuarios Se denomina Modelo de Dominio o Modelo de Conceptos de Negocio. El cliente es un cliente válido Análisis y Diseño de Sistemas . Informar al cliente. Fecha: de creación/actualización. 5. Descripción de CU – Plantilla Ejemplo: Descripción de CU También puede incluir: Precondiciones y Postcondiciones. 8. 2 .Clase 5 8 Caminos Alternativos: Autor: responsable de la especificación. El sistema valida la clave. Es un primer modelo de clases básico. Continúa en 3.Clase 5 7 Nombre: Extraer dinero de un ATM. El importe no es válido. Caminos alternativos: 2. El sistema entrega el comprobante de la operación. Reglas de negocio relacionadas. 3. Descripción Detallada 5 Análisis y Diseño de Sistemas . 7.2 El cajero no cuenta con dinero. alumno Análisis y Diseño de Sistemas .Clase 6 15 Análisis y Diseño de Sistemas . gerente. Se recorren los actores y se sugieren CU para cada actor.Clase 6 13 ¿Cómo construir un MCU? Buscar Actores y CU Construir un MCU consiste de 4 etapas: 1. Ejemplo Modelo de Casos de Uso Una metodología para su construcción Modelo de Conceptos de Negocio para un Juego de Dados Análisis y Diseño de Sistemas . generalmente son ejecutados en forma concurrente. Ejemplo: cliente.Cuatrimestre de 2007. 4.Clase 6 18 Estas transparencias proveen sólo una referencia a los temas. revisar modificar revisar. Ejemplo: empleado de atención al público. Cuando hay un modelo de negocio. 3 . Delimitar el sistema del entorno (definir el contexto o alcance). Para su estudio debe remitirse a la bibliografía. 3. Describir brevemente cada caso de uso. Análisis y Diseño de Sistemas . (descripciones de los CU). 4 Se identifican actores y CU para: Identificar los actores. testear y manejar como unidad. No existe orden para ejecutar estos pasos.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Tratar de crear CU que sean fáciles de modificar. y qué funcionalidades (CU) se esperan del sistema. Delinear quiénes y qué (actores) van a interactuar con el sistema. Buscar los casos de uso. Capturar y definir en un glosario términos comunes esenciales para crear descripciones detalladas de la funcionalidad del sistema.Clase 6 16 Buscar Actores Buscar Casos de Usos Depende del punto de partida: Tipo de sistema a construir. 2. Priorizar los CU. Un actor por cada “actor” del negocio que use el sistema de información. es directo: Un actor por cada trabajador en el negocio.Clase 6 17 Análisis y Diseño de Sistemas . se descubrirán en próximos niveles de abstracción. las acciones de uno influyen en el camino de acciones del otro. los casos de uso son artefactos que participan en todo el proceso del software.Clase 6 22 Cómo estructurar la descripción Descripción de CU Las alternativas surgen de: El actor puede elegir distintos caminos. Describir brevemente cada CU con pocas oraciones que resumen las acciones. El camino básico debe ser el camino normal. Si las desviaciones son sencillas se incluyen dentro del camino básico (definir políticas).Clase 6 21 Análisis y Diseño de Sistemas . eliminar o estudiar los objetos del negocio. monitorear. Los primeros diagramas de CU.Cuatrimestre de 2007. Análisis y Diseño de Sistemas . Informar al sistema de eventos externos. Escribir algunas palabras para aclarar el CU o sólo poner el nombre. Hacer una descripción paso a paso de lo que el sistema debe hacer para interactuar con los actores. Ejemplos: Registrar Alquiler. Algunos candidatos no serán CU por sí mismos. Buscar el nombre apropiado para el CU de tal modo que conduzca a pensar en la secuencia de acciones que agregará valor al actor. Describir el resto de los caminos como alternativas o desviaciones del camino básico. Análisis y Diseño de Sistemas . 3 4. El sistema detecta entrada de datos (inputs) erróneas del actor.Clase 6 20 Describir brevemente cada CU 1. 3. Cómo estructurar la descripción 2.Clase 6 19 Análisis y Diseño de Sistemas . Elegir un camino básico completo desde el estado inicial hasta el estado final y describirlo. Que el sistema le informe sobre algún evento. 4 . Lo mismo ocurre con la descripción (niveles de abstracción). Para su estudio debe remitirse a la bibliografía. El nombre del CU debe comenzar con un verbo y reflejar la interacción entre el sistema y el actor.Clase 6 23 Análisis y Diseño de Sistemas . formarán parte de otros. cambiar. Confirmar Pedido ! El MCU es una herramienta de interacción con el usuario Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Es importante definir convenciones. El modelo de CU evoluciona junto con el proyecto.Clase 6 24 Estas transparencias proveen sólo una referencia a los temas. Si hay más de un actor involucrado en el CU. maduran a l l d lo largo d l proyecto en l medida del t la did que se tiene más conocimiento del problema. Para el Proceso Unificado de Desarrollo de Software. Validar el CU con los usuarios finales del sistema. Algún recurso del sistema puede estar funcionando mal. Buscar Casos de Uso Buscar Casos de Uso Los actores necesitan CU’s para: Crear. Clase 6 25 Ejemplo – Problema Un restaurante desea automatizar el proceso de reservas de mesas así como el de registro de los pedidos de consumición de las mesas. Desarrollo de un ejemplo de aplicación: Diagrama de Casos de Uso.Clase 6 Estas transparencias proveen sólo una referencia a los temas. Booch. Definir prioridades. Bandeja. Usualmente se describe como un evento iniciado por un disparador. Indica sus datos personales y fecha y horario de la reserva. Identificar los principales CU de cada actor.Capítulos 16 y 17 Análisis y Diseño de Sistemas . Cada cliente puede elegir que mesa o mesas desea reservar. La actividad transforma una cosa en otra cambiando alguna característica.Clase 6 30 Análisis y Diseño de Sistemas . Los clientes del restaurante a través de unos terminales punto de reserva (TPR) ubicados en la entrada del restaurante pueden reservar una mesa. g CU con funcionalidad opuesta.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Descripción de Casos de Uso. Priorizar los CU Determinar qué CU necesitan desarrollarse en iteraciones más tempranas y cuáles en iteraciones más tardías. SISTEMA DE CORREO Una metodología para construir CU.Clase Actividades y Entidades Temas de la clase de hoy Actividad (o evento): es algo que sucede en el sistema.Cuatrimestre de 2007. Una metodología para el Análisis de Requerimientos con CU Identificar los Actores.Clase 6 28 Una solución posible para este problema6 se desarrollará en clase 27 Análisis y Diseño de Sistemas . Cada plato y bebida tiene asignado un precio. Entidad (u objeto): son los elementos involucrados en las actividades.Capítulo 7. CU que suceden a los existentes. Enviar. Crear descripciones de CU de “trazo grueso”. Actividad Abrir mensaje. Seleccionar destinatario. Un ejemplo Subsistema de Reservas y Asignaciones de Mesas para un Restaurante Análisis y Diseño de Sistemas . Todos los pedidos de platos y bebidas que haga se asocian a la mesa. Análisis y Diseño de Sistemas . Agenda. Jacobson. “El Lenguaje Unificado de Modelado”. Cuando un cliente llega al restaurante (con o sin reserva) el encargado le asigna una mesa. Rumbaugh . Jacobson. Rumbaugh . Pueden considerarse no sólo aspectos técnicos sino también políticos o comerciales comerciales. Identificar las clases del dominio (MCN) Identificar nuevos CU a partir de los existentes: Variaciones significativas de CU existentes. Las mesas están separadas en fumador y no fumador y además cada una indica la cantidad de personas que puede alojar. Refinar el modelo. Para su estudio debe remitirse a la bibliografía. Diagrama de Conceptos de Negocio. Entidad Mensaje. 5 . Destinatario. Imprimir. Diagrama de Casos de Uso Refinado. CU que preceden a los existentes. Booch. Reenviar Responder … 29 Bibliografía “El Proceso Unificado de Desarrollo de Software”. Se desea poder calcular automáticamente el importe de lo consumido al momento de cerrar la mesa. A la firma le interesa poder obtener antes del mediodía y antes de la cena un listado con todas las mesas reservadas ordenado por el apellido del cliente. Convenciones de la Cátedra Otros Artefactos Los CU se nombran con un verbo en infinitivo más un objeto directo. Análisis y Diseño de Sistemas . 6 . para las entidades.e “registrar”.Clase 6 32 Estas transparencias proveen sólo una referencia a los temas. bajas y modificaciones. quedan para etapas más avanzadas. “cancelar”) para los eventos.Cuatrimestre de 2007. Glosario: define términos importantes y comunes usados por los desarrolladores cuando describen el sistema. Prototipo de Interfaces de Usuario: ayudan en el análisis de requerimientos para comprender la interacción entre los actores humanos y el sistema Refinamientos progresivos del Diagrama de Casos de Uso requieren de enunciados muy detallados. para consultas y reportes.Clase 6 31 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Presupone las funcionalidades para altas. En general usaremos: Actualizar. Generar. “validar”. Se usa para lograr consenso en el equipo. Un verbo representativo (i. Para su estudio debe remitirse a la bibliografía. Descripciones Estructuradas de Proceso (DEP). Análisis y Diseño de Sistemas . Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2 Análisis Estructurado Análisis Estructurado Construye 3 modelos: Modelo de funcional: modela las funcionalidades de un sistema (¿Qué funciones debe realizar el sistema?) Diagrama de Flujo de Datos (DFD). con detalles de textuales de apoyo. Describir lo que requiere el usuario.Clase 13 Objetivos: Dpto. Discutir modificaciones con el usuario. Diccionario de Datos (DD).Clase 13 4 Análisis y Diseño de Sistemas . Se deben usar distintos modelos mínimamente redundantes e independientes.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Establecer una base para la creación y diseño se software. ( ) Modelo de comportamiento en el tiempo: modela el comportamiento del sistema (¿Cómo evoluciona un sistema?) Diagrama de Transición de Estados (DTE). Diccionario de Datos (DD). Modelado Funcional Conjunto de herramientas para modelar las funcionalidades del sistema. 1 .Clase 13 3 Herramientas de Modelado Una buena herramienta para modelar debe respetar las siguientes características: Ser gráfica. Análisis y Diseño de Sistemas . requerimientos Es simple cambiarlo y hasta construir otro si es necesario. Modelo de datos retenido: modela los datos que maneja un sistema (¿Qué datos maneja y como se relacionan?) Diagrama de Entidad Relación (DER). Para su estudio debe remitirse a la bibliografía.Clase 13 5 Estas transparencias proveen sólo una referencia a los temas. Diccionario de Datos (DD). Herramientas para Modelar Generalidades Análisis y Diseño de Sistemas Clase 13 – Metodología Estructurada: Modelo Funcional Lic. CUATRIMESTRE 2007 Se construyen modelos del sistema para: Resaltar características importantes del sistema.Cuatrimestre de 2007. Debe mostrar al sistema por niveles y en forma descendente. María Mercedes Vitturini 1er. Debe ser transparente. Verificar si se comprendieron correctamente los requerimientos. Definir un conjunto de requisitos que se puedan validar una vez que se construya el software Análisis y Diseño de Sistemas . Terminador Almacenamientos: objetos que almacenan pasivamente. transformación.Clase 13 8 DFD Terminador 1 Información de entrada Diagrama de Flujo de Datos (DFD) Terminador 2 Información de salida Datos intermedios Proceso 1 Datos intermedios Proceso 4 Datos intermedios Proceso 3 Información de salida Proceso 2 Información de entrada Entrada alamacenam.Clase 13 12 Ejemplo: “Calcular descuento”.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Consiste de “verbo en infinitivo + objeto”. p que p A medida que se desciende sus niveles. Se representa como un arco con dirección que entra o sale de un proceso. se pueden describir las funciones básicas de un sistema. Proceso P1 Flujos de Datos: cañerías por donde fluyen los datos dato x Objetos terminadores: objetos que producen o consumen los datos. El DFD se usa para modelar las funcionalidades de un sistema. Permite mostrar al sistema en término de las piezas q lo componen. Terminador 3 Almacenamiento Terminador 2 Análisis y Diseño de Sistemas .Clase 13 9 Análisis y Diseño de Sistemas . Todos los procesos se numeran. Análisis y Diseño de Sistemas . Diagrama de Flujo de Datos (DFD) DFD .Componentes El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la información y las transformaciones que se le aplican al moverse desde la entrada hacia la salida Procesos: transforman los datos. 2 . bj t ” Definición: es una “cañería” por donde fluye información con estructura conocida. Los procesos tienen un nombre que describe la función que realiza. Un proceso transforma entradas en salidas. Puede estar etiquetado (salvo los que van o vienen de almacenamientos) . Describen el movimiento de bloques o paquetes de información de una parte del sistema a otra otra. Ejemplo: factura – factura-validada. Para su estudio debe remitirse a la bibliografía. El número está en relación con el nivel del diagrama al que pertenece el proceso. Ayuda a la partición del problema en subproblemas.Clase 13 10 Procesos Flujos de datos Definición: es una transformación de los flujos de datos de entrada en los flujos de datos de salida. función.Clase 13 7 Análisis y Diseño de Sistemas . El nombre debe ser representativo de la totalidad del flujo y representar todo el conocimiento que se tenga de él. Sinónimos: burbuja. Salida de almacenam. almacenamiento Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas .Clase 13 11 Estas transparencias proveen sólo una referencia a los temas.Cuatrimestre de 2007. etc.Clase 13 16 Almacenamientos Los almacenamientos surgen: Almacenamientos Los almacenamientos pueden: El almacenamiento existe por un requerimiento.Clase 13 14 Flujos de datos Almacenamientos Los flujos convergentes pueden ser: A AB B AB AB AB Definición: es un depósito temporario de datos.Cuatrimestre de 2007. forman un paquete de AB? Las respuestas no están en el DFD. Se utilizan para modelar un conjunto de datos en reposo con características similares. Se necesitan las Descripciones Estructuradas de Proceso (DEP) Análisis y Diseño de Sistemas . Los almacenamientos pueden responder a un requerimiento del usuario. Convergentes Divergentes Los flujos divergentes pueden ser: A AB AB B AB AB Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . otro proceso. Leerse con flujos de datos que salen desde el almacenamiento y van hacia el proceso que lo requiere.Clase 13 13 Análisis y Diseño de Sistemas . Los flujos no responden a dudas de procedimiento. como un área de almacenamiento diferida en el tiempo. necesaria entre dos procesos que ocurren en diferentes momentos. Flujos de Datos Flujos de datos Especiales Los flujos de datos entran o salen de procesos y pueden conectar dicho proceso con: Existen flujos: un terminador. responde a una necesidad de diseño. 3 . Escribirse con flujos de datos que vienen desde los procesos al almacenamiento: P1 Para agregar nuevos datos. alm P1 Los almacenamientos se conectan a los procesos mediante flujos.Clase 13 17 Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. P t li l t id de los datos i t t Ejemplo: backups. Sinónimos: archivos. o por algún aspecto conveniente de la implementación del sistema. un almacenamiento. El almacenamiento existe por conveniencia de implementación. bases de datos. alm Para borrar algunos de los datos existentes Para actualizar el contenido d l d t existentes. Ejemplo: ¿Cuántos paquetes de A y cuántos de B. Algunos ejemplos de almacenamiento en un g j p sistema manual son carpetas.Clase 13 18 Estas transparencias proveen sólo una referencia a los temas.Clase 13 15 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. ficheros. Ej: leer todos los clientes de Bahía Blanca.Cuatrimestre de 2007. sistema Los flujos con ellos representan la interface del sistema.Clase 13 19 Almacenamientos Terminadores Los almacenamientos son pasivos: Los datos no viajan a los largo del flujo. almacenamiento Ej: modificación de los códigos postales de los clientes.Clase 13 22 DFD.1 Niveles del DFD Supongamos un sistema con 25 procesos. Se debe recordar: Los flujos conectados a un almacenamiento. un departamento dentro de la misma empresa. o la manera en que trabaja. una organización externa. Análisis y Diseño de Sistemas . Ej: leer datos del cliente X.Clase 13 21 Sinónimos: Entidad Externa. Análisis y Diseño de Sistemas . 4 . Se recuperan porciones de más de un paquete Ej: leer los domicilios de los clientes de Bahía Blanca. El almacenamiento no cambia cuando un paquete se mueve del almacenamiento al proceso. Proceso Se modifican uno o más paquetes del almacenamiento. un grupo. es el de it de l i t l proceso el responsable de realizar los cambios. sólo pueden transportar los datos que el almacenamiento guarda. Para evitar un DFD complejo ¿cómo representamos tantas funciones? Los DFD´s se organizan por niveles. Cada nivel p p proporciona sucesivamente más detalles sobre una porción del nivel anterior. El proceso recupera un solo paquete de datos. En l E el caso d escritura d un almacenamiento. (Actor en AOO) Análisis y Diseño de Sistemas . el almacenamiento cambió luego de estas operaciones. Ej: eliminar un(os) cliente(s). Para su estudio debe remitirse a la bibliografía. Definición: es una persona u organización apoyada fuera del contexto del sistema Ejemplos: una persona. Almacenamientos Almacenamientos Un almacenamiento se muestra: Escritura de un almacenamiento: Con un flujo de un proceso al almacenamiento Con un flujo de un almacenamiento a un proceso. Un primer Ejemplo Registrar Ventas 1.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Ej: grabar datos de (los) cliente (s). En todos estos casos.Clase 13 24 Reporte_Diario_Caja Empleado Ventas Análisis y Diseño de Sistemas .Clase 13 20 Análisis y Diseño de Sistemas . Las relaciones que existen entre terminadores no se muestran en el DFD. j Proceso P Se recupera más de un paquete de datos. Lectura de un almacenamiento: El proceso guarda uno o más paquetes en el almacenamiento. Niveles: Empleado Ventas VENTAS Cerrar Caja 1. almacenamiento Se recupera una porción de un paquete Ej: leer el domicilio del cliente X.2 Nivel Top Nivel Bottom Niveles intermedios Análisis y Diseño de Sistemas . Son externos al sistema.Clase 13 23 Estas transparencias proveen sólo una referencia a los temas. Se borran uno o más paquetes del almacenamiento. No es posible que el analista o el sistema cambie el contenido de un terminador. a menos que el proceso lo solicite. No contiene almacenamientos en su interior.Clase 13 26 Diagrama de Nivel Uno Diagrama de Nivel 2 . Usar el sentido común. que tiene el nombre del sistema. Este diagrama es importante por que determina los límites del sistema. i lid d tó i El limite de cuando se llego a una burbuja primitiva no esta formalmente definido. El DFD sirve para comunicación con los usuarios. En el Diagrama de Contexto se muestran todos los terminadores y las interfaces con ellos. Cuando tiene un único flujo de entrada o un único flujo de salida. Consta de una sola burbuja.Clase 13 29 Cuando el proceso que realiza la burbuja se puede describir en una hoja.2 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. no pretende describir algoritmos .3 P_3 archivo P_5 P_4 P_3.1 P_3. Nivel Uno.Clase 13 30 Estas transparencias proveen sólo una referencia a los temas.Clase 13 25 A C El Sistema B A Análisis y Diseño de Sistemas .Clase 13 27 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Niveles del DFD Diagrama de Contexto El nivel top es llamado Diagrama de Contexto o Diagrama de Nivel Cero. 5 . El nivel que sigue. ¿Se usa el mismo criterio para determinar que una burbuja es primitiva en todos los niveles? Test: Análisis y Diseño de Sistemas . Dependerá de la política de documentación adoptada. se muestran las principales funciones del sistema y las interfaces entre ellas. Análisis y Diseño de Sistemas .Proceso 3 P_1 P_2 P_3. Procesos o funciones primitivas: son aquellos procesos con f funcionalidad atómica. Para su estudio debe remitirse a la bibliografía.Cuatrimestre de 2007.Clase 13 28 Tipos de Procesos ¿Se llego a una primitiva? En un DFD se pueden distinguir Algunos criterios: Procesos no primitivos: son los que van a permitir definir próximos niveles en el DFD. procesos 4. Vendedores. I. 5.. Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Empleado Atención al Público Análisis y Diseño de Sistemas . almacenamiento y terminadores. 3. Ejemplos: Clientes. como por ejemplo: procesar.Cuatrimestre de 2007. Evitar DFD complejos y hacer uso de los niveles. En una aplicación práctica y dependiendo de los usuarios que se manejen el primero podría resultar de interés. El primer resultado es el diagrama de contexto. aclarar usuario. 3 Numerar los procesos. 6 .Clase 13 36 Terminadores: usar nombres del dominio de aplicación Estas transparencias proveen sólo una referencia a los temas. Identificar las entradas y salidas del Sistema Ligado a la definición del alcance o contexto del sistema. Para su estudio debe remitirse a la bibliografía. . Se determina ¿qué va hacer el sistema?. flujos.Clase 13 35 Procesos: usar un verbo en infinitivo más un objeto. Pautas para Construir un DFD 1. Ejemplos: Novedades_Clientes. Elegir verbos que indiquen la acción específica para los nombres de procesos. Elegir cuidadosamente nombres Elegir cuidadosamente nombres No poner como nombre de proceso a nombres de personas o sectores. En caso de duda “aclarar” con el usuario duda. que den idea del significado del componente.Clase 13 33 Análisis y Diseño de Sistemas . No usar términos de computación. Identificar las entradas y salidas del sistema.Clase 13 31 Análisis y Diseño de Sistemas . En este curso sólo nos ocuparemos del último.. Cliente_Código. Elegir cuidadosamente los nombres para cada uno de los elementos del diagrama: procesos. Estar preparado para corregir el modelo. Análisis y Diseño de Sistemas . Ejemplos: Actualizar Clientes. Clientes. Usar nombres claros.Clase 13 32 Ejemplo: Diagrama de Contexto Observación Podríamos construir un DFD que modele el sistema físico actual y otro DFD para modelar el nuevo sistema informático que se esta diseñando. Calcular Descuento Flujos de datos: usar nombres claros y evitar agrupar varios datos en un mismo flujo. No usar abreviaturas en los nombres. Alquileres Ejemplos: Encargado de Compras. 6. hacer. Análisis y Diseño de Sistemas . p _ _ Reporte_Alfabético_Clientes Almacenamientos: usar nombres representativos de la información que tienen (en plural). manejar.Clase 13 34 II. No verbos vagos. 2. Revisar el diagrama con el usuario y volver a dibujarlo tantas veces como sea necesario. Lo importante es la tarea que se realiza y no quién la realiza. La numeración no da idea de orden de proceso. Un proceso de control es una burbuja supervisora. interrupciones) como un flujo.Clase 13 41 Estas transparencias proveen sólo una referencia a los temas. Sea claro. Numerar los procesos IV. Extensiones para mostrar control. Análisis y Diseño de Sistemas .Cuatrimestre de 2007.Clase 13 40 Extensiones del DFD para sistemas de tiempo real Se modelan los flujos de control (señales. pero con el contorno punteado. 7 . Un flujo de control es un conducto que porta una señal binaria No porta datos con valores binaria. como para mostrarlo a los usuarios de primer nivel. pero en vez de una línea llena. Análisis y Diseño de Sistemas . fácilmente asimilado. Para su estudio debe remitirse a la bibliografía. Se muestran procesos de control. Ubicar las entradas a la izquierda y las salidas a la derecha. Análisis Estructurado Herramientas DFD Componentes. hasta que: Sea técnicamente correcto. propuestas Pregunta Yourdon: Bibliografía: ¿Le gustaría a usted volar en un avión diseñado por ingenieros que se aburrieron de sus dibujos de ingeniería luego de la segunda iteración? “Análisis Estructurado Moderno”. valores. Se usa para referenciar a los p p procesos. Usar numeración jerárquica en base a los niveles del DFD.Clase 13 39 Análisis y Diseño de Sistemas . y placentero a la vista: Si un proceso lleva el número 3. El DFD debe caber cómodamente en una hoja. Volver a dibujar el DFD Temas de la clase de hoy Se debe dibujar tantas veces como sea necesario. III. cuya tarea es coordinar las actividades de otras burbujas en el diagrama.Clase 13 37 V.4 podemos afirmar que se trata de un proceso que pertenece al segundo nivel del DFD y que ese nivel está asociado con la “explotación” de la burbuja 3 del nivel anterior. con una notación de burbuja. Sea aceptado por el usuario. Análisis y Diseño de Sistemas . La excepción es el Diagrama de Contexto. Evitar los DFD´s complejos Agregar un número a cada proceso. Usar 7 + -2 como límite. Particiones propuestas. No definir demasiados procesos en un nivel. Edward Yourdon – Capítulos 8 y 9. niveles y balanceo.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. El diagrama debe ser fácilmente entendido. con una línea punteada. Evitar E it en l medida de lo posible cruzar fl j en un la did d l ibl flujos nivel. Ejemplo: El propósito del DFD es que debe ser leído y comprendido por el usuario. Sus entradas y salidas son sólo flujos de control.Clase 13 38 Análisis y Diseño de Sistemas . Estar preparado para corregir el modelo. Análisis Estructurado Análisis y Diseño de Sistemas Clase 14 – Modelo Funcional: Diagrama de Flujo de Datos Lic. 3 Numerar los procesos. Para su estudio debe remitirse a la bibliografía. María Mercedes Vitturini 1er. Evitar DFD complejos y hacer uso de los niveles.Clase 14 3 Análisis y Diseño de Sistemas . El primer resultado es el diagrama de contexto. Se determina ¿qué va hacer el sistema?.Componentes El diagrama de flujo de datos (DFD) es una técnica que representa el flujo de la información y las transformaciones que se le aplican al moverse desde la entrada hacia la salida Procesos: transforman los datos. Identificar las entradas y salidas del Sistema Ligado a la definición del alcance o contexto del sistema. Dpto. almacenamiento y terminadores. Descripciones Estructuradas de Proceso (DEP). Identificar las entradas y salidas del sistema.Clase 14 4 Pautas para Construir un DFD 1. Análisis y Diseño de Sistemas . Elegir cuidadosamente los nombres para cada uno de los elementos del diagrama: procesos. flujos.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 14 5 I. Terminador Almacenamientos: objetos que almacenan pasivamente. aclarar usuario. almacenamiento Análisis y Diseño de Sistemas . En caso de duda “aclarar” con el usuario duda.Cuatrimestre de 2007. 2.Clase 14 6 Estas transparencias proveen sólo una referencia a los temas.Clase 14 2 Diagrama de Flujo de Datos (DFD) DFD . Revisar el diagrama con el usuario y volver a dibujarlo tantas veces como sea necesario. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas . 3. Diccionario de Datos (DD). CUATRIMESTRE 2007 Construye 3 modelos: Modelo de funcional: modela las funcionalidades de un sistema (¿Qué funciones debe realizar el sistema?) Diagrama de Flujo de Datos (DFD). Proceso P1 Flujos de Datos: cañerías por donde fluyen los datos dato x Objetos terminadores: objetos que producen o consumen los datos. procesos 4. 6. 5. Análisis y Diseño de Sistemas . 1 . Ejemplos: Clientes. De las entrevista se llego a las siguientes conclusiones.4 podemos afirmar que se trata de un proceso que pertenece al segundo nivel del DFD y que ese nivel está asociado con la “explotación” de la burbuja 3 del nivel anterior.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. hacer. fácilmente asimilado. La excepción es el Diagrama de Contexto. Análisis y Diseño de Sistemas .Clase 14 8 Terminadores: usar nombres del dominio de aplicación III. De ellos se registra el número de socio. De cada película mantiene el código. Ejemplo: El propósito del DFD es que debe ser leído y comprendido por el usuario. Calcular Descuento Flujos de datos: usar nombres claros y evitar agrupar varios datos en un mismo flujo. hasta que: Sea técnicamente correcto. como por ejemplo: procesar. Volver a dibujar el DFD Ejemplo Se debe dibujar tantas veces como sea necesario. duración y actores p principales. p Ingresar al sistema los nuevos socios.Clase 14 12 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Pregunta Yourdon: ¿Le gustaría a usted volar en un avión diseñado por ingenieros que se aburrieron de sus dibujos de ingeniería luego de la segunda iteración? Se desea hace un sistema para un Video Club.Clase 14 11 Estas transparencias proveen sólo una referencia a los temas. Usar nombres claros. título. nombre. No verbos vagos. No definir demasiados procesos en un nivel.. Para su estudio debe remitirse a la bibliografía. Empleado Atención al Público Análisis y Diseño de Sistemas . Necesita que el sistema le permita consultar. Usar numeración jerárquica en base a los niveles del DFD. Clientes. Evitar E it en l medida de lo posible cruzar fl j en un la did d l ibl flujos nivel. II. como para mostrarlo a los usuarios de primer nivel. Elegir cuidadosamente nombres Elegir cuidadosamente nombres No poner como nombre de proceso a nombres de personas o sectores. teléfono. Alquileres Ejemplos: Encargado de Compras.Clase 14 7 Procesos: usar un verbo en infinitivo más un objeto. Ejemplos: Actualizar Clientes. que den idea del significado del componente. El diagrama debe ser fácilmente entendido. Se usa para referenciar a los p p procesos. El dueño es quien se encarga de: Ingresar al sistema las nuevas películas que se adquieren. Cliente_Código. Una persona para ser socio del video club debe presentar el documento o un comprobante de servicio con el domicilio actualizado. Usar 7 + -2 como límite. Sea claro. Ejemplos: Novedades_Clientes. La numeración no da idea de orden de proceso. Sea aceptado por el usuario. Vendedores. p _ _ Reporte_Alfabético_Clientes Almacenamientos: usar nombres representativos de la información que tienen (en plural). Ubicar las entradas a la izquierda y las salidas a la derecha. Análisis y Diseño de Sistemas . Los usuarios del sistema son: el dueño y el empleado de atención al público. Elegir verbos que indiquen la acción específica para los nombres de procesos. Evitar los DFD´s complejos Agregar un número a cada proceso.Clase 14 9 V.Clase 14 10 Análisis y Diseño de Sistemas . y placentero a la vista: Si un proceso lleva el número 3. No usar abreviaturas en los nombres.. 2 . El DFD debe caber cómodamente en una hoja. manejar. No usar términos de computación. Numerar los procesos IV. . el apellido. dado un socio las películas que tiene reservadas y poder emitir dos informes: un con las películas más alquiladas en un período y otro con los socios sancionados. Lo importante es la tarea que se realiza y no quién la realiza.Cuatrimestre de 2007. Es necesario proporcionar un medio organizado para representar las características de ellos. Introducción Diccionario de Datos . 3 . Análisis y Diseño de Sistemas . Contiene definiciones precisas y rigurosas para que tanto el analista como el usuario tengan un entendimiento común de todas las entradas. los datos juegan un rol importante.Clase 14 17 Diccionario de Datos Flujos de Datos Almacenamientos de Datos Estructuras de Datos Datos Elementales Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. p que prestan p un día ( por (estrenos) y otras p ) por Existen películas q se p dos o tres días. Análisis y Diseño de Sistemas .Clase 14 13 Diccionario de Datos .Clase 14 15 Diccionario de Datos En el DD encontramos: El significado de los flujos y almacenamientos del DFD.Clase 14 16 Análisis y Diseño de Sistemas . Los socios pueden solicitar reservas de películas para una fecha. Análisis y Diseño de Sistemas . Diccionario de Datos . almacenamientos. Las películas se pueden alquilar siempre que el socio no esté sancionado y la película no haya sido reservada para el día. Ejemplo El empleado de atención al público nos explicó su trabajo: Los socios elijen las películas y se presentan al mostrador para efectuar el alquiler informando su número de socio y película que desean alquilar. Los valores y unidades relevantes de piezas elementales de información de los flujos de datos y de los almacenamientos.Definición: Es una lista organizada de todos los elementos de datos que se pueden encontrar en el sistema bajo estudio.Clase 14 18 Estas transparencias proveen sólo una referencia a los temas.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. es decir flujos complejos que se pueden descomponer en datos más elementales. Si el socio no recuerda su número consulta por apellido Cada película tiene asociado un plazo de préstamo en días.Caracterísitcas En el DFD. La composición de los flujos agregados de datos. El diccionario de datos debe ser casi una gramática formal para definir el contenido de los objetos definidos durante el análisis estructurado. Es un repositorio de datos sobre datos. Cuando el socio devuelve la película el sistema registra la fecha de devolución y controla que la misma fue en término o en su defecto se sanciona al socio. elementales La composición de los paquetes de datos de almacenamientos. Al momento de ingresar el préstamo se indica además la forma de pago que puede ser en efectivo o con abono. Debe tener definiciones precisas y rigurosas de manera de garantizar que tanto usuarios como analistas entienden lo mismo. salidas. y cálculos intermedios.Cuatrimestre de 2007.DD El DD es una lista organizada de todos los elementos de datos que se pueden encontrar en el sistema bajo estudio. Es un conjunto organizado de todos los datos pertinentes al sistema. Sólo un domicilio para enviar la factura. { } iteración. al ordenar alfabéticamente. Ayuda a clarificar la terminología con los usuarios. todas las definiciones de una entidad quedan agrupadas.Cuatrimestre de 2007. Ejemplo: A = B + C Se puede leer como Cuando digamos “A”.Clase 14 21 Análisis y Diseño de Sistemas . queremos decir una “B” y una “C”. Convención Si esta última posibilidad no fuera posible.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.F. Un DD sin DFD tampoco es útil. Forma parte de la especificación estructurada.Clase 14 19 Análisis y Diseño de Sistemas . 4 . | Sra. Ejemplos: Significa que el domicilio puede consistir de: Nombre del cliente: cliente_nombre Fecha de nacimiento: cliente_fecha-nacimiento Sólo un domicilio de envío. Ninguno de los dos.D. ] nombre = {carácter_legal} segundo_nombre = { á t l d b {carácter_legal} l} apellido = {carácter_legal} carácter_legal = [A-Z | a-z | ´ | | ] La definición de un dato se introduce con el símbolo “=“. Análisis y Diseño de Sistemas . Con esta convención. Un domicilio de envío y otro para enviar las facturas. El “=“ se lee como “se define como”. Un DFD sin DD no es posible de entender completamente. | Srta.Clase 14 24 Estas transparencias proveen sólo una referencia a los temas. | Dr. [ ] seleccionar una d varias alternativas. Relevancia del DD Notación Es un complemento al D. = + está compuesto por y ( ) optativo – puede estar presente o no. entonces se podría definir: Domicilio = [domicilio_envío | domicilio_factura | domicilio_envío + domicilio_factura] NombreEntidad_Atributo. “A” se compone de “B” y “C” “A” se define como “B” y “C” Análisis y Diseño de Sistemas . l i de i l i | separa alternativas en la construcción. o “significa”. Análisis y Diseño de Sistemas .Clase 14 23 Análisis y Diseño de Sistemas . Acompaña a los otros modelos gráficos. F t d l ifi ió t t d No es gráfico. título_cortesía = [Sr.Clase 14 20 Definiciones del DD – Ejemplos Definiciones nombre_completo = título_cortesía + nombre + (segundo_nombre) + apellido. Para su estudio debe remitirse a la bibliografía.Clase 14 22 Datos elementales Datos opcionales Domicilio = (domicilio_envío) + (domicilio_factura) Dato Elemental: son los datos para los cuales no existe una descomposición con significado dentro del contexto del ambiente del usuario. Para su estudio debe remitirse a la bibliografía.Cuatrimestre de 2007.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Análisis y Diseño de Sistemas .Clase 14 28 Estas transparencias proveen sólo una referencia a los temas.Clase 14 27 Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . 5 . Ejemplos: Se puede indicar con un límite inferior y superior de ocurrencias. p Se debe evitar el uso de sinónimos. Modelo Funcional Diagrama de Flujo de Datos – Desarrollo de un Ejemplo Diccionario de Datos Definición Componentes C Bibliografía: “Análisis Estructurado Moderno” Edward Yourdon – Capítulos 9 y 10. Iteración Selección La notación de iteración se usa para indicar la ocurrencia repetida de un componente de un dato. Se relaciona con el nombre primario del dato. ocurrencias de alumnos.Clase 14 26 Cota inferior Análisis y Diseño de Sistemas . Alumnos_inscriptos = materiaNombre + año_cuatrimestre + 0 {alumnoApellido + alumnoNombre}50 sexo = [ femenino | masculino ] estado_civil = [soltero | casado | divorciado | separado | viudo] Asegurarse que se contemplaron todas las alternativas posibles.Clase 14 Cota superior 25 Alias o Sinónimos Temas de la clase de hoy Un alias o sinónimo es una alternativa de nombre para un dato. hasta donde sea posible. Las opciones se encierran entre [ ] y se separan por una barra vertical “|”. Es común cuando se trata con usuarios de distintas áreas. Alumnos_inscriptos = materiaNombre + año_cuatrimestre + {alumnoApellido + alumnoNombre} Significa que Alumnos_inscriptos contiene un nombre de materia un año-cuatrimestre y también cero o más materia. La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de alternativas. Diccionario de Datos Análisis y Diseño de Sistemas Clase 15 – Diccionario de Datos Diccionario de Datos: Es una lista organizada de todos los elementos de datos que se pueden encontrar en el sistema bajo estudio.Clase 15 6 Estas transparencias proveen sólo una referencia a los temas. Código: si ya existiera. La forma de señalarla es subrayando los datos que la componen Análisis y Diseño de Sistemas . La clave puede no ser única.Cuatrimestre de 2007. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas . Los valores y unidades relevantes de piezas elementales de información de los flujos de datos y de los almacenamientos. La composición de los paquetes de datos de almacenamientos. La clave (o llave) para un almacenamiento es el/los atributo/s que identifican a un único l/l t ib t / id tifi ú i registro de todos los registros que integran el almacenamiento. datos Podría ser un DE (dato elemental) Composición: nombre_almacenamiento = dato1 + dato2 + dato3 + .Clase 15 2 Diccionario de Datos Flujos de Datos Almacenamientos de Datos Estructuras de Datos Datos Elementales Resumen de la Notación Análisis y Diseño de Sistemas ....Clase 14 3 Análisis y Diseño de Sistemas . AD (+ ED) – Se identifica que es un almacenamiento y generalmente también es una estructura de datos. Dpto. La composición de los flujos agregados de datos. Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. María Mercedes Vitturini 1er. es su nombre físico Sinónimo: (si tuviera). CUATRIMESTRE 2007 El significado de los flujos y almacenamientos del DFD.Clase 15 4 Almacenamientos de Datos Almacenamientos .Clase 15 5 En la definición de componentes de un almacenamiento se subrayan el/los atributo/s que conforman la clave.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.. 1 .Claves Nombre: con el que aparece en el DFD. Lic. Notación: En la definición de los almacenamiento se debe identificar la clave primaria. Clase 15 11 Estas transparencias proveen sólo una referencia a los temas. Claves .Ejemplos Ejemplo: Almacenamientos de Datos Para el almacenamiento PERSONAS: Persona_Tipo_Doc + Persona_Nro_Doc Para el almacenamiento VENTAS: Factura_Número Para el almacenamiento PRESTAMOS: Nombre: Clientes Código: Sinónimo: AD + ED Composición: clientes = cliente_tipo-doc + cliente_nro-doc + cliente_nombre + cliente_dirección + cliente_fecha-alta Libro_ISBN + Ejemplar_Nro + Socio_Número + Fecha_Préstamo ¿Otra clave? Préstamo_Nro Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía. 2 . Podría ser un dato elemental (DE) Composición: nombre_flujo = dato1 + dato2 + (dato3) + Nombre: Nodedades_clientes Código: Sinónimo: FD + ED Composición: p Novedades_clientes = [cliente_tipo-doc + cliente_nro-doc + cliente_nombre + cliente_dirección | cliente_tipo-doc + cliente_nro-doc | cliente_tipo-doc + cliente_nro-doc + (cliente_nombre) + (cliente_dirección )] Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.) (numérica. Análisis y Diseño de Sistemas .Clase 15 12 Análisis y Diseño de Sistemas .Clase 15 7 Análisis y Diseño de Sistemas .. fecha. Código: puede ser el número de formulario..Clase 15 9 Otra definición posible Datos Elementales Nombre: Nodedades_clientes Código: Sinónimo: FD + ED Composición: Novedades_clientes = cliente_tipo-doc + cliente_nro-doc + (cliente_nombre) + (cliente_dirección) Nombre: Código: si existiera en el DD de la BD Sinónimo: DE Clase: (numérica alfanumérica. Sinónimo: (si tuviera) FD ( + ED) – Se identifica que es un flujo de dato y generalmente también es una estructura de datos.Clase 15 10 Análisis y Diseño de Sistemas . .Cuatrimestre de 2007. alfanumérica fecha ) Longitud: Subconjunto válido / Significado: Fórmula de Cálculo: Unidad: (unidad de medida en el caso de un dato medible).Clase 15 8 Flujos de Datos Ejemplo: Flujo de Datos Nombre: con el que aparece en el DFD. Debe ser fácil de mantener actualizado. 3 .Cuatrimestre de 2007. Factura = Factura_Encabezado + 1{Factura_Detalle}n + Factura_Pie. Análisis y Diseño de Sistemas . los diagramas de entidad relación o los de transición de estados? Análisis y Diseño de Sistemas .Clase 15 14 Modularizar Ejemplo Definición Modularizada Puede darse el caso de un elemento de dato lo suficientemente complejo como para necesitar ser descripto en términos de datos más simples. Ejemplo: ¿Cuántos paquetes de A y cuántos de B. Se necesitan las Descripciones Estructuradas de Proceso (DEP) Análisis y Diseño de Sistemas . Factura_Detalle = Artículo_Código + Artículo_Descripción + Artículo_Cantidad + Artículo_Precio + Artículo_Importe. A su vez. Los flujos no responden a dudas de j p procedimientos que puedan surgir.Clase 15 17 El DD no debe tener redundancia.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Factura_Encabezado= Factura_Número + Factura_Fecha + Cliente_Descripción Factura_Pie = Factura_Subtotal + Factura_Descuento + Factura_Total Factura = Factura_Número + Factura_Fecha + Cliente_Descripción + 1{Artículo_Código + Artículo_Descripción + Artículo_Cantidad + Artículo_Precio + Artículo_Importe}n + Factura_Subtotal + Factura_Descuento + Factura_Total Versus: Análisis y Diseño de Sistemas . los elementos de datos más simples se definen en términos de las unidades legítimas de los valores que pueden asumir. forman un paquete de AB? Las respuestas no están en el DFD. Para su estudio debe remitirse a la bibliografía.Clase 15 15 Análisis y Diseño de Sistemas .Clase 15 16 Consistencia del DD y DFD Consideraciones Generales ¿Se ha definido en el DD cada flujo del DFD? ¿Se ha definido en el DD cada almacenamiento del DFD? ¿Se han definido todos los componentes de los datos en el DD? ¿Se ha utilizado la notación correcta para todas las definiciones? ¿Hay elementos que no estén relacionados con los DFD´s. esto es. Ejemplo: Dato Elemental Ejemplo: Dato Elemental Nombre: estado_civil Código: Sinónimo: DE Clase: alfanumérico Longitud: 1 Subconjunto válido / Significado S : soltero D : divorciado C : casado P : separado V : viudo O : otro Fórmula de Cálculo Unidad: Análisis y Diseño de Sistemas . información que puede obtenerse en algún otro elemento de la especificación estructurada.Clase 15 18 Estas transparencias proveen sólo una referencia a los temas.Clase 15 13 Nombre: cantidad_descargada Código: Sinónimo: DE Clase: numérico Longitud: 2 enteros y 3 decimales. Subconjunto válido / Significado: Fórmula de Cálculo: Unidad: toneladas. Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. 4 . Para su estudio debe remitirse a la bibliografía.Clase 15 19 Estas transparencias proveen sólo una referencia a los temas.Cuatrimestre de 2007. Componentes. Notación Bibliografía: Análisis Estructurado Moderno – Edward Yourdon – Capítulo 10. Temas de la clase de hoy Diccionario de Datos Definición. Análisis y Diseño de Sistemas . Clase 16 2 Dependencias Funcionales Ejemplos Se dice que un atributo B de una relación R (o almacenamiento) depende funcionalmente del atributo A de R.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. La normalización se basa en los conceptos de dependencia funcional y llave primaria. si en todo instante de tiempo.Cuatrimestre de 2007. artículo_código Æ artículo_precio + artítculo_descripción. alumno_legajo + materia_código + fecha_examen Æ examen_nota. María Mercedes Vitturini 1er. se selecciona uno de ellos y se lo denota como llave primaria. Ejemplo: Artículos (AD+ED) = artículo_código + artículo_descripción + artículo-precio. Toma la definición de un almacenamiento y a través de una serie de test verifica que se satisfaga una determinada forma normal. reserva_número Æ reserva_fecha + cliente_número + vuelo_número persona_tipoDoc + persona_nroDoc Æ persona_nombre + persona_apellido + persona_fechaNac. Esto es. Lic. A Æ B Un atributo puede depender funcionalmente de un conjunto de atributo: AB Æ C Análisis y Diseño de Sistemas . cada valor de A no tiene más de un atributo asociado de B en la relación R. Normalización Análisis y Diseño de Sistemas Clase 16 – Normalización Es un proceso que se aplica sobre los almacenamientos y que permite determinar una mejor organización de almacenamientos lógicos. Análisis y Diseño de Sistemas . 1 .Clase 16 3 Llave de una Relación Llave de una Relación Un conjunto de atributos A en una relación R constituyen una clave ó llave si todos los atributos de R dependen funcionalmente de A.Clase 16 6 Estas transparencias proveen sólo una referencia a los temas. (Codd 1972). Generalmente. Para su estudio debe remitirse a la bibliografía.Clase 16 4 B depende funcionalmente de A Notación: Si B depende funcionalmente a A. A identifica a B. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas . A´ A tal que A´determine funcionalmente a A determine R. Ejemplo Una relación R puede tener más de un conjunto de atributos que sean llaves de R. y no existe ningún subconjunto A A A´. CUATRIMESTRE 2007 Dpto. A Æ R. Alumnos (AD+ED) = alumno_registro + alumno_nombre + alumno_DNI + alumno_apellido + alumno_nombre ¿Cuál es la llave? Análisis y Diseño de Sistemas .Clase 16 5 Análisis y Diseño de Sistemas . que acompañó a los desarrollos estructurados. Ejemplo: AB Æ C Si C depende funcionalmente en forma total AÆC BÆC Análisis y Diseño de Sistemas . Es equivalente hablar del almacenamiento “personas” o de la relación “personas”. Caso contrario se di P i R C t i dice Primo. Llaves: alumno_nroRegistro _ g alumno_tipoDoc + alumno_nroDoc. Atributos no primos: alumno_apellido. alumno_nroRegistro + materia_código + examen_fecha o examen_nota. Análisis y Diseño de Sistemas . Buscan una estructura lógica de los datos que minimice los problemas de diseño: Repetición de información. Dependencias funcionales parciales: Se basa en los conceptos: materia_código + alumno_LU o materia_nombre.Clase 16 11 Análisis y Diseño de Sistemas . Segunda. el concepto de relación se relaciona con el concepto de almacenamiento de datos. 2 . Informalmente. Para su estudio debe remitirse a la bibliografía. Análisis y Diseño de Sistemas . Atributos primos: alumno_nroRegistro.Cuatrimestre de 2007.Clase 16 7 Análisis y Diseño de Sistemas . alumno_tipoDoc. si B depende funcionalmente de la totalidad de A. Observaciones Atributos Primos y No primos DEFINICIONES PREVIAS Los conceptos de normalización están formalmente definidos para el modelo de datos relacional.Clase 16 9 Ejemplos Normalización Dependencias funcionales totales: materia_código o materia_nombre.Clase 16 10 Análisis y Diseño de Sistemas . alumno_nombre. Tercera y de Boyce Codd. Incapacidad para representar información. alumno_nroDoc.Clase 16 8 Ejemplo Dependencia Funcional Total Alumnos (AD + ED) = alumno_nroRegistro + alumno_tipoDoc + alumno_nroDoc + alumno_apellido + alumno_nombre. pero de ningún subconjunto de A.Clase 16 12 Estas transparencias proveen sólo una referencia a los temas. pelicula_código+ socio_número o socio_apellido + socio_nombre. En este curso se presenta al modelo de datos p relacional intuitivamente.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Llave (o clave primaria) de los almacenamientos Dependencia funcional entre atributos del almacenamiento. Un atributo o conjunto de atributos B de una relación R se dice que depende funcionalmente en forma total de otro conjunto de atributos A de la relación R. Un atributo A de una relación R es No Primo si no forma parte de ninguna de las llaves de R. Las formas normales son: Primera. La corrección de diseño de un almacenamiento que no respetan una forma normal dada será a través de descomponerlo en dos o más almacenamientos.Clase 16 Formas Normales Primer Forma Normal (1FN) Para determinar la forma normal que respeta un almacenamiento es necesario plantear todas las dependencias funcionales entre sus atributos. pero no hay en el almacenamiento alguna persona de Viedma.Coronel S á ? l Suárez? Tipo Doc Nro.Clase 16 17 Análisis y Diseño de Sistemas . Inscripciones (AD+ED) = alumno_registro + alumno_nombre + 0{materia_código + materia_nombre + inscripción_fecha + inscripción_resultado}n Definición: Un esquema de relación respeta la Segunda Forma Normal (2FN). si: No respeta 1FN: Respeta la 1FN y Todos los atributos no primos del esquema de relación d l ió dependen t t l d totalmente de l clave ( d t d la l (no de un subconjunto de ellos). Definición: Un esquema de relación respeta la Primer Forma Normal (1FN) si no existen atributos o grupos de atributos que se repiten q dentro del esquema. Análisis y Diseño de Sistemas . Doc DNI 111111 DNI 222222 DNI 333333 DNI 444444 Apellido Díaz Suárez Lino Cané Nombre Cod. Para su estudio debe remitirse a la bibliografía.Clase 16 16 Ejemplos Segunda Forma Normal Respeta la 1FN: Clientes (AD+ED) = cliente_Número + cliente_TipoDoc + cliente_DNI + cliente_Apellido + cliente_Nombre + localidad_CP + localidad_Nombre.Cuatrimestre de 2007. Postal Nombre Localidad Alberto 8000 Bahía Blanca Patricia 8000 Bahía Blanca Lucas 8000 Coronel Suárez María 8102 Punta Alta 13 Incapacidad para representar información: si se conoce el código postal de Viedma. ¿cómo guardar este dato en el sistema? Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Bahía Blanca” tantas veces como personas.Clase 16 14 Análisis y Diseño de Sistemas . Problemas de Diseño Problemas Ejemplo: supongamos la siguiente definición en el diccionario de datos: Personas (AD+ED) = persona_TipoDocumento + persona_NroDocumento + persona_Apellido + persona_Nombre + ciudad_CódigoPostal + ciudad_Nombre Repetición de información: si la mayoría de las personas son de Bahía Blanca. Esta forma normal pide que el dominio de todos los atributos sea atómico. tendríamos que repetir la información “8000. Análisis y Diseño de Sistemas . Algunos problemas derivados: ¿Qué pasa si necesitamos cambiar el nombre de la ciudad? ¿Qué se hace con el caso “8000 C Q é h l “8000.Clase 16 15 Análisis y Diseño de Sistemas .Clase 16 18 Estas transparencias proveen sólo una referencia a los temas. 3 . Clase 16 20 Tercer Forma Normal (3FN) Ejemplos Definición 1: Un esquema de relación respeta la Tercer Forma Normal (3FN) si: Respeta la 3FN: Materias (AD+ED) = materia_Código + materia_Nombre + departamento_Código. materia_Código Æ materia_Nombre + departamento_Código. materia_Código Æ materia_Nombre + departamento_Código.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Análisis y Diseño de Sistemas . localidad_nombre Todo almacenamiento (o relación) cuyas llaves candidatas están formadas por un único atributo siempre va a respetar la 2FN. Para su estudio debe remitirse a la bibliografía.Clase 16 23 Análisis y Diseño de Sistemas . Supongamos ahora la siguiente definición para un almacenamiento Dicta. 4 . Personas (AD+ED) = persona_id + persona_nombre + localidad_códPostal + localidad_nombre Persona_id Æ persona_nombre. departamento_Código Æ departamento_Nombre Análisis y Diseño de Sistemas . Definición 2: Un esquema de relación está en la Tercer Forma Normal (3FN) si respeta la 2FN y no existen dependencias transitivas de la llave entre atributos no primos.Cuatrimestre de 2007.Clase 16 19 Análisis y Diseño de Sistemas . Ejemplos Para reflexionar Respetan la 2FN: Materias (AD+ED) = materia_código + materia_nombre.Clase 16 21 Análisis y Diseño de Sistemas . que mantiene información de los docentes y las materias que dictan cada año: Dictan (AD+ED) = prof_legajo + prof_nombre + prof_domicilio + 0{mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre}n La solución a un problema de diseño de datos es encontrar una descomposición mejor.Clase 16 24 Estas transparencias proveen sólo una referencia a los temas. Tienen problemas de: Redundancia de información. Está en 2FN y No existen dependencias entre atributos no primos. Inconsistencias Anomalías de inserción y de borrado. materia_Código Æ materia_Nombre. carrera_Código Æ carrera_Nombre Análisis y Diseño de Sistemas . Inconsistencias. No respeta la 3FN: Materias (AD+ED) = materia_Código + materia_Nombre + departamento_Código + departamento_Nombre.Clase 16 22 Descomposiciones normalizadas Descomposiciones normalizadas Los almacenamientos (o relaciones) que no respetan la 3FN no responden a un buen diseño de datos. No respeta la 2FN: Alumnos (AD+ED) = alumno_NroRegistro + carrera_Código + carrera_Nombre. localidad_códPostal. prof_domicilio.Clase 16 25 Análisis y Diseño de Sistemas . Uno con el grupo que se repite al que se le agrega la clave del esquema del inciso anterior. Atributos primos: prof_legajo. mat_nombre. dicta_año Atributos no primos: mat nombre dpto_código. Análisis y Diseño de Sistemas .Cuatrimestre de 2007.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Uno con todos los datos que no pertenecen al grupo repetitivo.Clase 16 28 El almacenamiento Dictan2 Segunda Forma Normal Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre Clave: prof_legajo + mat_código + dicta_año. mat_código o mat_nombre + dpto_código. Para contar con un modelo de datos que respete la 1FN.Clase 16 26 Descomposición en 1FN El almacenamiento Dictan1 Dictan1 = prof_legajo + prof_nombre + prof_domicilio. Dictan2 = prof legajo + mat código + prof_legajo mat_código dicta_año + mat_nombre + dpto_código + dpto_nombre. dpto código dpto_nombre Dependencias Funcionales: Prof_legajo + dicta_año + mat_código o mat_nombre + dpto_código + dpto_nombre. Análisis y Diseño de Sistemas . mat_código. Primer Forma Normal Descomposición en 1FN El almacenamiento Dictan NO RESPETA LA 1FN: Existen atributos no atómicos.Clase 16 29 Dictan1 respeta la 2FN ya que la clave esta formada por un único atributo. p p _ g j Atributos no primos: prof_nombre. la solución es descomponer.Clase 16 30 Estas transparencias proveen sólo una referencia a los temas. dpto_código o dpto_nombre. 5 . En este caso por cada docente se mantiene un grupo repetitivo con las materias que dicta. Atributos primos: prof_legajo. Clave: prof_legajo.Clase 16 27 Análisis y Diseño de Sistemas . Dictan1 (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. Análisis y Diseño de Sistemas . Análisis y Diseño de Sistemas . Dictan1 (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. Para su estudio debe remitirse a la bibliografía. Si un esquema no respeta la 1FN se debe descomponer en dos esquemas. Dependencias Funcionales: prof_legajo o prof_nombre + prof_domicilio. Para su estudio debe remitirse a la bibliografía.Clase 16 36 Estas transparencias proveen sólo una referencia a los temas.Clase 16 31 mat_código Los La solución para un almacenamiento que no respeta la 2FN es descomponer: z En un almacenamiento con la llave primaria y todos aquellos atributos que dependen totalmente de la clave primaria (si los hubiera). por lo tanto no existen dependencias entre atributos no primos. atributos no primos: mat_nombre.Clase 16 34 El almacenamiento Dictan22 zDictan22 Tercer Forma Normal (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre. primos: mat_código. zDependencias Funcionales: zAtributos zmat_código zdpto_código zClave: El almacenamiento Dictan21 respeta la 3FN ya que no posee ningún atributo que no forme parte de la clave. Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre.Clase 16 35 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. dicta_año. Atributos no primos: no posee. mat_código. Dependencias Funcionales: no posee Análisis y Diseño de Sistemas . Atributos primos: prof_legajo.Cuatrimestre de 2007. Clave: Descomposición en 2FN z prof_legajo. Análisis y Diseño de Sistemas . junto con la parte de la clave que ocasiona la dependencia. dpto_nombre. dpto_código y dpto_nombre dependen parcialmente de la clave. Dependencias funcionales: o mat_nombre + dpto_código. Análisis y Diseño de Sistemas . dicta_año. 6 . mat_código. Dictan21 (AD+ED)= prof_legajo + mat_código + dicta_año o mat_nombre + dpto_código o dpto_nombre Análisis y Diseño de Sistemas . dpto_código. mat código dicta año prof legajo mat_código. Dictan21 (AD+ED) = prof_legajo + mat_código + dicta_año z z Dictan21 (AD+ED) = prof_legajo + mat_código + dicta_año dicta año Dictan22 (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre z z Clave: prof_legajo + mat_código + dicta_año.Clase 16 32 Descomposición en 2FN El almacenamiento Dictan21 z Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre. Segunda Forma Normal Dictan2 NO RESPETA la 2FN. zAtributos no primos: mat_nombre. z Otro almacenamiento con los atributos que dependen de parte de la llave.Clase 16 33 Análisis y Diseño de Sistemas . Dictan21 (AD+ED)= prof_legajo + mat_código + dicta_año.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Tercer Forma Normal Descomposición 3FN z El almacenamiento Dictan22 NO RESPETA 3FN. 7 . z z Un esquema con la clave primaria y todos aquellos atributos que dependen totalmente de la clave primaria (sin incluir el que depende transitivamente).Cuatrimestre de 2007.Clase 16 37 Análisis y Diseño de Sistemas . z En el ejemplo: Análisis y Diseño de Sistemas . Ninguno de ellos forma parte de la clave mat_código. corresponde descomponerlo en dos esquemas. Análisis y Diseño de Sistemas . Existe una dependencia funcional entre los atributos no primos dpto_código y dpto_nombre. Para su estudio debe remitirse a la bibliografía.Clase 16 42 Estas transparencias proveen sólo una referencia a los temas. z Dependencias Funcionales: z mat_código o mat_nombre + dpto_código z z Dictan221 (AD+ED)= mat código + (AD ED) mat_código mat_nombre + dpto_código Dictan222 (AD+ED)= dpto_código + dpto_nombre z Análisis y Diseño de Sistemas . La solución está en descomponer al almacenamiento Dictan22 Si un almacenamiento no respeta la 3FN.Clase 16 38 Descomposición en 3FN z El almacenamiento Dictan221 z Dictan22 (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre. z Dictan221 (AD+ED) = mat_código + mat_nombre + dpto_código. Dictan222 (AD+ED)= dpto_código + dpto_nombre. dpto_código. Atributos primos: mat_código z Atributos no primos: mat_nombre.Clase 16 39 Análisis y Diseño de Sistemas .Clase 16 40 El almacenamiento Dictan3221 zDictan222 Descomposición en 3FN (AD+ED)= dpto_código + dpto_nombre zClave: dpto_código. zAtributos primos: dpto código dpto_código zAtributos no primos: dpto_nombre. Dictan (AD+ED)= Di t 221 (AD+ED) mat_código + t ódi mat_nombre + dpto_código. Clave: mat_código.Clase 16 41 Análisis y Diseño de Sistemas . Otro esquema con los atributos participan de la dependencia que viola la 3FN. zDependencias Funcionales: zdpto_código o dpto_nombre Dictan1 (AD+ED)= prof_legajo + prof_nombre + prof_domicilio. Atributos primos y no primos primos. Claves de almacenamiento. se descubran problemas de normalización. Normalizar las siguientes estructuras: R1 = A + B + 1{ C }n R2 = A + B + 1{ C + D} n R3 = A + B + C + D y B Æ C R4 = A + B + C + D y C Æ D R5 = A + B + 1{ C }n + 1{ D }n R6 = A + B + 1 { C + D + 1 { E + F }n }n Análisis y Diseño de Sistemas .Clase 16 43 Luego de normalizar revisar los modelos: En el Diccionario de datos: Se reemplazan las definiciones de los almacenamientos por las nuevas definiciones normalizadas. Se revisan los procesos de transformación para verificar los accesos a los almacenamientos. mat código + dicta año Materias (AD+ED)= mat_código + mat_nombre + dpto_código Departamentos (AD+ED) = dpto_código + dpto_nombre. Se reveen los diferentes niveles del DFD donde aparecen los almacenamientos que fueron normalizados y se reemplazan por los nuevos almacenamientos. Descomposición en 3FN con nombres significativos Impacto en los modelos del Análisis Estructurado Profesores (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. Para su estudio debe remitirse a la bibliografía. En l Diagrama de Flujos de Datos: E el Di d Fl j d D t Análisis y Diseño de Sistemas . Formas normales (1FN. 2FN y 3FN) Bibliografía: Database System Concepts – Abraham Silberschatz – Capítulo 7 Análisis y Diseño de Sistemas . Cuanto antes se corrijan los problemas de normalización menos modificaciones habrá que realizar.Cuatrimestre de 2007.Clase 16 46 Temas de la clase de hoy Conceptos de Normalización de almacenamientos Dependencias funcionales. 8 . Análisis y Diseño de Sistemas .Clase 16 45 Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 16 44 Observaciones Ejercicios propuestos Es de esperar que al momento de definir los almacenamientos. Dictan (AD+ED)= prof_legajo + mat_código dicta_año.Clase 16 47 Estas transparencias proveen sólo una referencia a los temas. 1 . se selecciona uno de ellos y se lo denota como llave primaria. CUATRIMESTRE 2007 Dpto.Clase 16 4 B depende funcionalmente de A Notación: Si B depende funcionalmente a A. A identifica a B. cada valor de A no tiene más de un atributo asociado de B en la relación R.Clase 16 2 Dependencias Funcionales Ejemplos Se dice que un atributo B de una relación R (o almacenamiento) depende funcionalmente del atributo A de R. Toma la definición de un almacenamiento y a través de una serie de test verifica que se satisfaga una determinada forma normal. alumno_legajo + materia_código + fecha_examen Æ examen_nota. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas . A Æ R. Normalización Análisis y Diseño de Sistemas Clase 16 – Normalización Es un proceso que se aplica sobre los almacenamientos y que permite determinar una mejor organización de almacenamientos lógicos. Análisis y Diseño de Sistemas . Para su estudio debe remitirse a la bibliografía.Clase 16 3 Llave de una Relación Llave de una Relación Un conjunto de atributos A en una relación R constituyen una clave ó llave si todos los atributos de R dependen funcionalmente de A. La normalización se basa en los conceptos de dependencia funcional y llave primaria. reserva_número Æ reserva_fecha + cliente_número + vuelo_número persona_tipoDoc + persona_nroDoc Æ persona_nombre + persona_apellido + persona_fechaNac. María Mercedes Vitturini 1er.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Ejemplo: Artículos (AD+ED) = artículo_código + artículo_descripción + artículo-precio. si en todo instante de tiempo. Generalmente. A Æ B Un atributo puede depender funcionalmente de un conjunto de atributo: AB Æ C Análisis y Diseño de Sistemas . Ejemplo Una relación R puede tener más de un conjunto de atributos que sean llaves de R. artículo_código Æ artículo_precio + artítculo_descripción. A´ A tal que A´determine funcionalmente a A determine R.Clase 16 6 Estas transparencias proveen sólo una referencia a los temas.Clase 16 5 Análisis y Diseño de Sistemas . (Codd 1972).Cuatrimestre de 2007. y no existe ningún subconjunto A A A´. Lic. Alumnos (AD+ED) = alumno_registro + alumno_nombre + alumno_DNI + alumno_apellido + alumno_nombre ¿Cuál es la llave? Análisis y Diseño de Sistemas . Esto es. Para su estudio debe remitirse a la bibliografía. Segunda. alumno_nroRegistro + materia_código + examen_fecha o examen_nota. alumno_nombre. pero de ningún subconjunto de A. Llave (o clave primaria) de los almacenamientos Dependencia funcional entre atributos del almacenamiento. Llaves: alumno_nroRegistro _ g alumno_tipoDoc + alumno_nroDoc. Buscan una estructura lógica de los datos que minimice los problemas de diseño: Repetición de información.Cuatrimestre de 2007. 2 . Tercera y de Boyce Codd. que acompañó a los desarrollos estructurados.Clase 16 7 Análisis y Diseño de Sistemas . Es equivalente hablar del almacenamiento “personas” o de la relación “personas”. el concepto de relación se relaciona con el concepto de almacenamiento de datos.Clase 16 12 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . Atributos primos: alumno_nroRegistro. Ejemplo: AB Æ C Si C depende funcionalmente en forma total AÆC BÆC Análisis y Diseño de Sistemas . Atributos no primos: alumno_apellido. alumno_nroDoc.Clase 16 10 Análisis y Diseño de Sistemas .Clase 16 9 Ejemplos Normalización Dependencias funcionales totales: materia_código o materia_nombre. En este curso se presenta al modelo de datos p relacional intuitivamente. Las formas normales son: Primera. Análisis y Diseño de Sistemas .Clase 16 8 Ejemplo Dependencia Funcional Total Alumnos (AD + ED) = alumno_nroRegistro + alumno_tipoDoc + alumno_nroDoc + alumno_apellido + alumno_nombre. Un atributo o conjunto de atributos B de una relación R se dice que depende funcionalmente en forma total de otro conjunto de atributos A de la relación R. pelicula_código+ socio_número o socio_apellido + socio_nombre. Dependencias funcionales parciales: Se basa en los conceptos: materia_código + alumno_LU o materia_nombre. Caso contrario se di P i R C t i dice Primo.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Informalmente. alumno_tipoDoc.Clase 16 11 Análisis y Diseño de Sistemas . Incapacidad para representar información. Observaciones Atributos Primos y No primos DEFINICIONES PREVIAS Los conceptos de normalización están formalmente definidos para el modelo de datos relacional. si B depende funcionalmente de la totalidad de A. Un atributo A de una relación R es No Primo si no forma parte de ninguna de las llaves de R. si: No respeta 1FN: Respeta la 1FN y Todos los atributos no primos del esquema de relación d l ió dependen t t l d totalmente de l clave ( d t d la l (no de un subconjunto de ellos).Clase 16 16 Ejemplos Segunda Forma Normal Respeta la 1FN: Clientes (AD+ED) = cliente_Número + cliente_TipoDoc + cliente_DNI + cliente_Apellido + cliente_Nombre + localidad_CP + localidad_Nombre. Problemas de Diseño Problemas Ejemplo: supongamos la siguiente definición en el diccionario de datos: Personas (AD+ED) = persona_TipoDocumento + persona_NroDocumento + persona_Apellido + persona_Nombre + ciudad_CódigoPostal + ciudad_Nombre Repetición de información: si la mayoría de las personas son de Bahía Blanca. Análisis y Diseño de Sistemas .Clase 16 15 Análisis y Diseño de Sistemas . Algunos problemas derivados: ¿Qué pasa si necesitamos cambiar el nombre de la ciudad? ¿Qué se hace con el caso “8000 C Q é h l “8000.Coronel S á ? l Suárez? Tipo Doc Nro. pero no hay en el almacenamiento alguna persona de Viedma. 3 .Cuatrimestre de 2007. Análisis y Diseño de Sistemas .Bahía Blanca” tantas veces como personas.Clase 16 17 Análisis y Diseño de Sistemas .Clase 16 18 Estas transparencias proveen sólo una referencia a los temas. Esta forma normal pide que el dominio de todos los atributos sea atómico. ¿cómo guardar este dato en el sistema? Análisis y Diseño de Sistemas . Definición: Un esquema de relación respeta la Primer Forma Normal (1FN) si no existen atributos o grupos de atributos que se repiten q dentro del esquema.Clase 16 Formas Normales Primer Forma Normal (1FN) Para determinar la forma normal que respeta un almacenamiento es necesario plantear todas las dependencias funcionales entre sus atributos. Doc DNI 111111 DNI 222222 DNI 333333 DNI 444444 Apellido Díaz Suárez Lino Cané Nombre Cod. Para su estudio debe remitirse a la bibliografía. Postal Nombre Localidad Alberto 8000 Bahía Blanca Patricia 8000 Bahía Blanca Lucas 8000 Coronel Suárez María 8102 Punta Alta 13 Incapacidad para representar información: si se conoce el código postal de Viedma. La corrección de diseño de un almacenamiento que no respetan una forma normal dada será a través de descomponerlo en dos o más almacenamientos. Inscripciones (AD+ED) = alumno_registro + alumno_nombre + 0{materia_código + materia_nombre + inscripción_fecha + inscripción_resultado}n Definición: Un esquema de relación respeta la Segunda Forma Normal (2FN). tendríamos que repetir la información “8000.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Clase 16 14 Análisis y Diseño de Sistemas . materia_Código Æ materia_Nombre + departamento_Código. materia_Código Æ materia_Nombre + departamento_Código. Está en 2FN y No existen dependencias entre atributos no primos.Clase 16 23 Análisis y Diseño de Sistemas . Ejemplos Para reflexionar Respetan la 2FN: Materias (AD+ED) = materia_código + materia_nombre.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Inconsistencias Anomalías de inserción y de borrado. localidad_nombre Todo almacenamiento (o relación) cuyas llaves candidatas están formadas por un único atributo siempre va a respetar la 2FN. Inconsistencias.Clase 16 22 Descomposiciones normalizadas Descomposiciones normalizadas Los almacenamientos (o relaciones) que no respetan la 3FN no responden a un buen diseño de datos. No respeta la 3FN: Materias (AD+ED) = materia_Código + materia_Nombre + departamento_Código + departamento_Nombre. Supongamos ahora la siguiente definición para un almacenamiento Dicta.Cuatrimestre de 2007. carrera_Código Æ carrera_Nombre Análisis y Diseño de Sistemas . que mantiene información de los docentes y las materias que dictan cada año: Dictan (AD+ED) = prof_legajo + prof_nombre + prof_domicilio + 0{mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre}n La solución a un problema de diseño de datos es encontrar una descomposición mejor. Personas (AD+ED) = persona_id + persona_nombre + localidad_códPostal + localidad_nombre Persona_id Æ persona_nombre.Clase 16 20 Tercer Forma Normal (3FN) Ejemplos Definición 1: Un esquema de relación respeta la Tercer Forma Normal (3FN) si: Respeta la 3FN: Materias (AD+ED) = materia_Código + materia_Nombre + departamento_Código. localidad_códPostal. Para su estudio debe remitirse a la bibliografía. Tienen problemas de: Redundancia de información.Clase 16 21 Análisis y Diseño de Sistemas .Clase 16 19 Análisis y Diseño de Sistemas . materia_Código Æ materia_Nombre. No respeta la 2FN: Alumnos (AD+ED) = alumno_NroRegistro + carrera_Código + carrera_Nombre. departamento_Código Æ departamento_Nombre Análisis y Diseño de Sistemas . Definición 2: Un esquema de relación está en la Tercer Forma Normal (3FN) si respeta la 2FN y no existen dependencias transitivas de la llave entre atributos no primos. 4 .Clase 16 24 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . mat_código o mat_nombre + dpto_código. dpto código dpto_nombre Dependencias Funcionales: Prof_legajo + dicta_año + mat_código o mat_nombre + dpto_código + dpto_nombre. 5 . En este caso por cada docente se mantiene un grupo repetitivo con las materias que dicta. la solución es descomponer. Uno con todos los datos que no pertenecen al grupo repetitivo. Clave: prof_legajo. Atributos primos: prof_legajo. Análisis y Diseño de Sistemas .Clase 16 30 Estas transparencias proveen sólo una referencia a los temas. p p _ g j Atributos no primos: prof_nombre.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Primer Forma Normal Descomposición en 1FN El almacenamiento Dictan NO RESPETA LA 1FN: Existen atributos no atómicos.Clase 16 25 Análisis y Diseño de Sistemas . mat_nombre. dicta_año Atributos no primos: mat nombre dpto_código.Clase 16 29 Dictan1 respeta la 2FN ya que la clave esta formada por un único atributo. Para su estudio debe remitirse a la bibliografía. Para contar con un modelo de datos que respete la 1FN. Análisis y Diseño de Sistemas . mat_código. Dictan1 (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. dpto_código o dpto_nombre.Clase 16 28 El almacenamiento Dictan2 Segunda Forma Normal Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre Clave: prof_legajo + mat_código + dicta_año. Atributos primos: prof_legajo. Uno con el grupo que se repite al que se le agrega la clave del esquema del inciso anterior. Si un esquema no respeta la 1FN se debe descomponer en dos esquemas.Clase 16 26 Descomposición en 1FN El almacenamiento Dictan1 Dictan1 = prof_legajo + prof_nombre + prof_domicilio. prof_domicilio.Clase 16 27 Análisis y Diseño de Sistemas . Dictan2 = prof legajo + mat código + prof_legajo mat_código dicta_año + mat_nombre + dpto_código + dpto_nombre. Dictan1 (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. Análisis y Diseño de Sistemas .Cuatrimestre de 2007. Análisis y Diseño de Sistemas . Dependencias Funcionales: prof_legajo o prof_nombre + prof_domicilio. mat código dicta año prof legajo mat_código. Dependencias funcionales: o mat_nombre + dpto_código. Dictan21 (AD+ED) = prof_legajo + mat_código + dicta_año z z Dictan21 (AD+ED) = prof_legajo + mat_código + dicta_año dicta año Dictan22 (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre z z Clave: prof_legajo + mat_código + dicta_año. Dictan21 (AD+ED)= prof_legajo + mat_código + dicta_año o mat_nombre + dpto_código o dpto_nombre Análisis y Diseño de Sistemas . primos: mat_código. Segunda Forma Normal Dictan2 NO RESPETA la 2FN. Análisis y Diseño de Sistemas .Clase 16 36 Estas transparencias proveen sólo una referencia a los temas. mat_código. atributos no primos: mat_nombre. dpto_nombre. dicta_año.Clase 16 34 El almacenamiento Dictan22 zDictan22 Tercer Forma Normal (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre. dpto_código y dpto_nombre dependen parcialmente de la clave. dicta_año.Clase 16 31 mat_código Los La solución para un almacenamiento que no respeta la 2FN es descomponer: z En un almacenamiento con la llave primaria y todos aquellos atributos que dependen totalmente de la clave primaria (si los hubiera). junto con la parte de la clave que ocasiona la dependencia. Atributos primos: prof_legajo.Clase 16 32 Descomposición en 2FN El almacenamiento Dictan21 z Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre. Dictan2 (AD+ED)= prof_legajo + mat_código + dicta_año + mat_nombre + dpto_código + dpto_nombre.Cuatrimestre de 2007.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. por lo tanto no existen dependencias entre atributos no primos. Atributos no primos: no posee. Análisis y Diseño de Sistemas . Dependencias Funcionales: no posee Análisis y Diseño de Sistemas . zAtributos no primos: mat_nombre.Clase 16 35 Análisis y Diseño de Sistemas . zDependencias Funcionales: zAtributos zmat_código zdpto_código zClave: El almacenamiento Dictan21 respeta la 3FN ya que no posee ningún atributo que no forme parte de la clave. mat_código. Clave: Descomposición en 2FN z prof_legajo. Para su estudio debe remitirse a la bibliografía. dpto_código. z Otro almacenamiento con los atributos que dependen de parte de la llave. 6 .Clase 16 33 Análisis y Diseño de Sistemas . Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. zDependencias Funcionales: zdpto_código o dpto_nombre Dictan1 (AD+ED)= prof_legajo + prof_nombre + prof_domicilio.Clase 16 37 Análisis y Diseño de Sistemas . z z Un esquema con la clave primaria y todos aquellos atributos que dependen totalmente de la clave primaria (sin incluir el que depende transitivamente).Clase 16 38 Descomposición en 3FN z El almacenamiento Dictan221 z Dictan22 (AD+ED)= mat_código + mat_nombre + dpto_código + dpto_nombre. Análisis y Diseño de Sistemas . Dictan21 (AD+ED)= prof_legajo + mat_código + dicta_año. Tercer Forma Normal Descomposición 3FN z El almacenamiento Dictan22 NO RESPETA 3FN. z Dependencias Funcionales: z mat_código o mat_nombre + dpto_código z z Dictan221 (AD+ED)= mat código + (AD ED) mat_código mat_nombre + dpto_código Dictan222 (AD+ED)= dpto_código + dpto_nombre z Análisis y Diseño de Sistemas . zAtributos primos: dpto código dpto_código zAtributos no primos: dpto_nombre. z Dictan221 (AD+ED) = mat_código + mat_nombre + dpto_código.Clase 16 39 Análisis y Diseño de Sistemas . 7 . Atributos primos: mat_código z Atributos no primos: mat_nombre. Dictan (AD+ED)= Di t 221 (AD+ED) mat_código + t ódi mat_nombre + dpto_código.Clase 16 40 El almacenamiento Dictan3221 zDictan222 Descomposición en 3FN (AD+ED)= dpto_código + dpto_nombre zClave: dpto_código. z En el ejemplo: Análisis y Diseño de Sistemas .Clase 16 42 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. Dictan222 (AD+ED)= dpto_código + dpto_nombre.Cuatrimestre de 2007. Existe una dependencia funcional entre los atributos no primos dpto_código y dpto_nombre. corresponde descomponerlo en dos esquemas. dpto_código. Clave: mat_código. Ninguno de ellos forma parte de la clave mat_código. La solución está en descomponer al almacenamiento Dictan22 Si un almacenamiento no respeta la 3FN. Otro esquema con los atributos participan de la dependencia que viola la 3FN.Clase 16 41 Análisis y Diseño de Sistemas . Clase 16 44 Observaciones Ejercicios propuestos Es de esperar que al momento de definir los almacenamientos. Se reveen los diferentes niveles del DFD donde aparecen los almacenamientos que fueron normalizados y se reemplazan por los nuevos almacenamientos. Dictan (AD+ED)= prof_legajo + mat_código dicta_año.Clase 16 43 Luego de normalizar revisar los modelos: En el Diccionario de datos: Se reemplazan las definiciones de los almacenamientos por las nuevas definiciones normalizadas. En l Diagrama de Flujos de Datos: E el Di d Fl j d D t Análisis y Diseño de Sistemas . Claves de almacenamiento. 8 . 2FN y 3FN) Bibliografía: Database System Concepts – Abraham Silberschatz – Capítulo 7 Análisis y Diseño de Sistemas . Formas normales (1FN. mat código + dicta año Materias (AD+ED)= mat_código + mat_nombre + dpto_código Departamentos (AD+ED) = dpto_código + dpto_nombre. Cuanto antes se corrijan los problemas de normalización menos modificaciones habrá que realizar. Se revisan los procesos de transformación para verificar los accesos a los almacenamientos. Para su estudio debe remitirse a la bibliografía.Clase 16 45 Análisis y Diseño de Sistemas .Clase 16 47 Estas transparencias proveen sólo una referencia a los temas. se descubran problemas de normalización.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Normalizar las siguientes estructuras: R1 = A + B + 1{ C }n R2 = A + B + 1{ C + D} n R3 = A + B + C + D y B Æ C R4 = A + B + C + D y C Æ D R5 = A + B + 1{ C }n + 1{ D }n R6 = A + B + 1 { C + D + 1 { E + F }n }n Análisis y Diseño de Sistemas . Descomposición en 3FN con nombres significativos Impacto en los modelos del Análisis Estructurado Profesores (AD+ED) = prof_legajo + prof_nombre + prof_domicilio. Atributos primos y no primos primos. Análisis y Diseño de Sistemas .Clase 16 46 Temas de la clase de hoy Conceptos de Normalización de almacenamientos Dependencias funcionales.Cuatrimestre de 2007. Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Modelo Entidad-Relación (MER) Análisis y Diseño de Sistemas Clase 17 – Modelo EntidadRelación Lic. María Mercedes Vitturini 1er. CUATRIMESTRE 2007 Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur El modelo entidad relación está basado en la percepción del mundo real como un conjunto de objetos básico denominados entidades y las relaciones entre estos objetos. Definición: MER es una herramienta para el modelado de datos que describe las entidades y asociaciones que existen entre los datos de un sistema. Sinónimos: Diagrama Entidad Relación, DER. Análisis y Diseño de Sistemas - Clase 17 2 Modelo Entidad Relación – Entidades Ejemplos Entidad: es una “cosa” u “objeto” del mundo real que se distingue de los demás. Puede ser: Entidades Concreta: una persona, un auto. Abstracta: vacaciones, proyecto, enfermedad. (7630, “Desarrollo de Sistemas”, “DCIC”) (5551, “Análisis Matemático I”,”DMA”) ( (7890, “Shrek”, ATP) , , ) (7892, “La Guerra de las Galaxias”, PG-13) Conjunto de tid d C j t d entidades: es l agrupación d la ió de entidades del mismo tipo, que comparten las mismas propiedades o atributos. Ejemplo: todos los clientes de un banco. Conjuntos de entidades: Los conjuntos de entidades de un problema no tienen que ser necesariamente disjuntos. Análisis y Diseño de Sistemas - Clase 17 3 Materias (código, nombre, departamento) Películas (número, título, calificación) Análisis y Diseño de Sistemas - Clase 17 4 Entidades y Conjuntos de entidades – Atributos Atributos Atributos: las entidades se describen por atributos. Los atributos definen las propiedades que posee cada miembro de un conjunto de entidades. Ejemplo: atributos posibles del conjunto de entidades Clientes podrían ser: Dominio de un atributo: es el conjunto de valores permitidos para cada atributo. Ejemplo: Cadenas de longitud 50 podría ser el dominio para el atrib to cliente_nombre. atributo cliente nombre cliente_dni, cliente_apellido, cliente_nombre, cliente_domicilio, cliente_mail, etc. Formalmente un atributo es una función que asigna un conjunto de entidades a un dominio. atributo:Entidad Æ Dominio Análisis y Diseño de Sistemas - Clase 17 6 Análisis y Diseño de Sistemas - Clase 17 5 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 1 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Atributos cliente_1 Laura Pérez Atributos Así cada entidad se describe por un conjunto de pares (atributo, valor): Ejemplo: cliente_1 Æ ((número, 123), (nombre, Laura), (apellido, Pérez), (domicilio Laura) (apellido Pérez) (domicilio, Salta 23)) cliente_2 Æ ((número, 2342), (nombre, Juan), (apellido, Manuel), (domicilio, Rodríguez 453)) cliente_2 Juan Manuel cliente_3 Ignacio Pino Entidad Dominio Análisis y Diseño de Sistemas - Clase 17 7 Análisis y Diseño de Sistemas - Clase 17 8 Claves Observaciones Las claves permiten distinguir una entidad particular del conjunto de entidades. Conceptualmente todas las entidades son distinguibles. Desde el punto de vista del modelo, las diferencias se expresan en té i términos d sus atributos. de t ib t El conjunto de atributos necesarios para representar a una entidad depende de la información que se necesite mantener en un sistema de información. Un conjunto de entidades no puede contener dos entidades idénticas en todos sus valores. Para cada conjunto de entidades se identifica el atributo o conjunto de atributos que actúa como clave, i.e., distingue a cada entidad del conjunto. Análisis y Diseño de Sistemas - Clase 15 9 Análisis y Diseño de Sistemas - Clase 17 10 Modelo Entidad-Relación – Relaciones z Conjunto de Relaciones Relación: es una asociación entre dos o más entidades no necesariamente distintas. Ejemplos: z z Un alquiler es una asociación entre una entidad cliente y una entidad película. El dictado de una materia vincula a la misma con el docente que la dicta. Correlativa define para una materia, las anteriores materias que se requieren. Análisis y Diseño de Sistemas - Clase 17 11 z z Conjunto de Relaciones: es un conjunto de relaciones del mismo tipo. Formalmente se trata de una relación matemática entre n de conjuntos de entidades ( (no necesariamente distintos), n >=2. ), Si E1, E2, ..., En son conjuntos de entidades, entonces el conjunto de relaciones R es un subconjunto de: {(e1, e2, ..., en)| e1 E1, e2 E2, ..., en En} Con (e1, e2, ..., en) una relación. Análisis y Diseño de Sistemas - Clase 17 12 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 2 Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2007. Ejemplos Conjuntos Relaciones - Aridad Supongamos el conjunto de relaciones alquileres entre socios y películas: Alquileres = (socio_número, película_código) (12345, (12345 7890) Generalmente las relaciones son binarias. Pueden existir relaciones de mayor orden (ternarias, cuaternarias, etc.) Una relación particular: Si n = 2 Æ la relación es binaria. Si n = 3 Æ la relación es ternaria ... Identifica a la película: 7890, “Harry Potter”,”ATP” Identifica al socio: 1345, “Figueroa”, “José”, “Av. Alem 32” Análisis y Diseño de Sistemas - Clase 17 13 Un conjunto relación puede tener atributos propios descriptivos. Ejemplo El conjunto relación alquileres, entre películas y socios, podría tener los atributos propios fecha del alquiler y fecha de devolución. Análisis y Diseño de Sistemas - Clase 17 14 Relaciones - Ejemplos Atributos de Relación - Ejemplos Relaciones binarias: Viajan (pasajero, viaje, forma_pago). Representan (actor, obra_teatro, papel). Cursan (alumno, materia, docente, año, cuatrimestre, resultado) Viajan (pasajero, viaje, forma_pago) Representan (actor, obra_teatro, papel). Dirigen (director, empleado). Relaciones ternarias: Cursan (alumno, materia, docente, año, cuatrimestre) Participan (empleado, proyecto, lje_programación). Ejecutan (músico, instrumento, orquesta, fecha) Análisis y Diseño de Sistemas - Clase 17 15 Análisis y Diseño de Sistemas - Clase 17 16 Restricciones de Asignación Mapping Cardinalidad – 1:1 Se pueden definir restricciones sobre las relaciones a las cuales debe ajustarse el contenido de los conjuntos de relaciones. A la restricción se la denomina cardinalidad de la relación y puede ser: Relación Uno a Uno (1:1): indica que una entidad de un conjunto entidad E1 se relaciona exactamente con única entidad del otro conjunto entidad E2 y a la inversa. Ejemplos: Ej l Uno a uno. Muchos a uno; uno a muchos. Muchos a muchos. Análisis y Diseño de Sistemas - Clase 17 17 La relación es_capital entre las entidades provincias y ciudades_capitales. La relación garantiza entre las entidades electrodomésticos y su certificado_garantía. Análisis y Diseño de Sistemas - Clase 17 18 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 3 Ciudad Provincia Conjuntos de Relaciones: relación Relación muchos a muchos (m:n). Ejemplos: La relación Dpto_a_Cargo entre los conjuntos entidades Materias y Departamentos La relación Dirige entre la entidad empleados con ella misma. Cardinalidad – (1:m) / (m:1) Cardinalidad – m:n Relaciones Uno a Muchos (1:m) (o muchos a uno (m:1)): indica que una entidad de un conjunto entidad E1 se relaciona con cero o muchas entidades del otro conjunto entidad E2. La estructura lógica global de una base de datos se puede representar por un Diagrama Entidad Relación (DER). Análisis y Diseño de Sistemas . paciente_Nro). Para su estudio debe remitirse a la bibliografía. pintor_id). es_pintor (obra_Nro. 4 . salidas (viaje_Nro.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. La relación cursa entre los conjuntos entidades materias y alumnos. Análisis y Diseño de Sistemas . Desde la inversa. localidad_CodPostal). Análisis y Diseño de Sistemas .Clase 17 21 Análisis y Diseño de Sistemas . Películas alquila Socios Líneas (o flechas) : para enlazar atributos a conjuntos de entidades y relaciones a conjuntos de entidades. El diagrama entidad-relación es un modelo de g datos. Análisis y Diseño de Sistemas . Artículo aval Garantía atributo Relación muchos a uno (m:1).Clase 17 19 La relación alquileres entre los conjuntos entidades películas y socios.Clase 17 22 Componentes de DER Conjuntos Entidades: Atributos: Entidades Representación de Cardinalidad en el DER Relación 1 a 1 (1:1).Clase 17 23 Análisis y Diseño de Sistemas .Clase 17 24 Estas transparencias proveen sólo una referencia a los temas.Clase 17 20 Ejercicios propuestos Diagrama entidad-relación Defina la cardinalidad para las siguientes relaciones: préstamos (libro_ISBN.Cuatrimestre de 2007. atiende (médico_Matricula. Ejemplos: Relaciones muchos a muchos (m:n): indica que una entidad de un conjunto entidad E1 se relaciona con cero o muchas entidades del otro conjunto entidad E2 y viceversa. una entidad de un conjunto entidad E2 se relaciona con una única entidad del otro conjunto entidad E1. socio_Nro). Existe entre un conjunto de entidades de un nivel más alto con uno o más conjuntos de entidades de nivel más bajo. Tour y Localidades Contrata y Escalas y los conjuntos relaciones: Las relaciones son muchos a muchos. La distinción entre atributos se hace a través de un proceso llamado herencia de atributos.Clase 17 29 Análisis y Diseño de Sistemas .Clase 17 Observaciones Especialización – Generalización En el diagrama anterior se puede inferir que representa los conjuntos entidades: Clientes. Para su estudio debe remitirse a la bibliografía.Clase 17 27 Persona = DNI + apellido + nombre Cliente = cliente_nro + cliente_tipo (y los de persona!) Análisis y Diseño de Sistemas .Clase 17 28 Especialización – Generalización Resalta aspectos parecidos y diferentes entre entidades de distintos niveles. Generalización – Especialización: Es un tipo de relación especial de inclusión o “herencia”. El conjunto de entidades puede incluir subgrupos de entidades. 5 .Cuatrimestre de 2007. En el DER se representan por una relación dibujada como un triángulo etiquetado “isa” o “es_un”. Un ejemplo de relación ternaria apellido registro nombre código nombre Diagrama Entidad Relación Alumnos Materias cursa cuatrimestre año Profesores apellido nombre 25 Análisis y Diseño de Sistemas . El subgrupo de entidades además de los atributos comunes al conjunto entidad ‘padre’ puede incluir su propio grupo de atributos. Ejemplo: Análisis y Diseño de Sistemas . La relación contrata tiene un atributo propio forma de pago.Clase 17 30 Estas transparencias proveen sólo una referencia a los temas.Clase 17 26 legajo Análisis y Diseño de Sistemas .Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. PADRE es_un Ejemplo Nombre Legajo Empleados Is_a Docentes HIJO-1 HIJO-2 Dedicación Cargo No Docentes Categoría Análisis y Diseño de Sistemas . El material de la biblioteca incluye libros. Para su estudio debe remitirse a la bibliografía. Ejemplo Ubicación Nombre Identificador Parques Se_divide Sectores número superficie Diseño de un Diagrama E-R Decisiones a tomar por el diseñador: cría trabajan Fecha_ingreso Guarda-Parques Animal Nro-matricula Apellido Nombre clasificación Análisis y Diseño de Sistemas . Restricciones de mapeo y cardinalidad. La oportunidad de usar generalización. relaciones. Modelo ER Componentes: entidades. Vegetal Período-flora descripcion 31 Análisis y Diseño de Sistemas .Clase 17 34 Estas transparencias proveen sólo una referencia a los temas. El uso de un atributo o de un conjunto de entidades. Bibliografía: “Fundamentos de Base de Datos”. Un concepto de un mundo real se expresa mejor mediante un conjunto de entidades o un conjunto de relaciones relaciones. Relaciones distinguidas.Cuatrimestre de 2007. Análisis y Diseño de Sistemas . El uso de un conjunto de entidades débiles o fuertes. De cada material se identifican sus autores y palabras claves.Clase 15 Se_alimenta Especies nombre-cient nombre-vulgar El uso de una relación ternaria o de una o más relaciones binarias. De los socios alumnos se sabe la/s carrera/s que está cursando.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Abraham Silberschatz – Capítulo 2.Clase 17 33 Análisis y Diseño de Sistemas . atributos. Diagrama E tid d R l ió Di Entidad-Relación. 6 .Clase 17 32 Ejemplo Temas de la clase de hoy Hacer el modelo de datos para la biblioteca de la UNS considerando: Existen asociados alumnos y docentes. Los asociados pueden retirar libros por un período de tiempo o consultarlo en la sala de lectura. revistas y videos. Por cada conjunto entidad del Diagrama Entidad Relación se define un almacenamiento que tiene como estructura los atributos de la entidad entidad.Clase 18 3 Almacenamientos a partir de las Relaciones Representación económica Por cada conjunto relación del Diagrama Entidad Relación se define un almacenamiento que tiene como estructura los atributos de la entidad entidad. Combinar almacenamientos que compartan la misma clave (si existen). Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Análisis y Diseño de Sistemas .Cuatrimestre de 2007.Clase 18 6 Estas transparencias proveen sólo una referencia a los temas. Entidad (AD + ED) = atributo_1 + atributo_2 … + atributo_n Entre el conjunto de atributos se distingue los que representan la llave o clave del conjunto entidad. Análisis y Diseño de Sistemas .Clase 18 4 Análisis y Diseño de Sistemas .Clase 18 5 Almacen_A (AD+ED) = k_1 + a_1 + a_2 + … + a_n + b_1 + b_2 + … + b_m Análisis y Diseño de Sistemas . g ( ) Diccionario de Datos (DD). Dpto.Clase 18 2 ¿Por qué construir el E-R? El diagrama entidad relación es otro camino para obtener el diseño de los almacenamientos: Almacenamientos a partir de las Entidades Hacer un almacenamiento para cada una de las entidades. Para su estudio debe remitirse a la bibliografía.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. María Mercedes Vitturini 1er. Análisis y Diseño de Sistemas . los almacenamientos se combinan Almacen_A (AD+ED) = k_1 + a_1 + a_2 + … + a_n a n Almacen_B (AD+ED) = k_1 + b_1 + b_2 + … + b_m Entre el conjunto de atributos se distingue el/los atributos que representan la llave o clave del conjunto de relaciones. Hacer un almacenamiento para cada una d l H l i t d de las relaciones. Análisis Estructurado – Modelos Análisis y Diseño de Sistemas Clase 18 – Modelo EntidadRelación Lic. Relación (AD + ED) = llave_e1 + llave_e2 … + llave_en + atributos_relación Si entre los almacenamientos existen dos o más almacenamientos que comparten la misma llave o clave. CUATRIMESTRE 2007 Modelo de datos retenido: Modela los datos que maneja un sistema (¿Qué datos se mantienen en forma permanente/semipermantente y como se relacionan?) Diagrama de Entidad Relación (DER). 1 . MATERIAS (AD+ED) = Materia_Código + Materia_Nombre. Departamentos = dpto_código + dpto_nombre. Dicta Di t = prof_legajo + mat_código + di t f l j t ódi dicta_año. DICTA (AD+ED) = Profesor_Legajo + Materia_Código + Año. nombre Análisis y Diseño de Sistemas . ES_DE (AD + ED) = Materia_Código + Dpto_Código.Clase 18 7 Análisis y Diseño de Sistemas .Clase 18 12 MATERIAS (AD+ED) = Materia_Código + Materia_Nombre ES_DE (AD + ED) = Materia_Código + Dpto_Código MATERIAS (AD+ED) = Materia_Código + Materia_Nombre + Dpto_Código en: Análisis y Diseño de Sistemas .Clase 18 10 Agrupar los almacenamientos Finalmente Los almacenamientos MATERIAS y ES_DE comparten la clave. Nombre. Código. DICTA (AD+ED) = Profesor_Legajo + Materia_Código + Año. se pueden convinar PROFESORES (AD+ED) = Profesor_Legajo+ Profesor_Nombre.Clase 18 11 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. DEPARTAMENTOS (AD+ED) = Dpto_Código +Dpto_Nombre. ñ Materias = mat_código + mat_nombre + dpto_código.Clase 18 8 El modelo ER Profesores Legajo. MATERIAS (AD+ED) = Materia_Código + p g Materia_Nombre + Dpto_Código DEPARTAMENTOS (AD+ED) = Dpto_Código +Dpto_Nombre.Cuatrimestre de 2007.Clase 18 9 Análisis y Diseño de Sistemas . 2 . Análisis y Diseño de Sistemas . Ejemplo Ejemplo En la clase pasada vimos que para la siguiente definición de un almacenamiento de datos: Dictan (AD+ED) = prof_legajo + prof_nombre + prof_domicilio {mat_código dictan_año prof domicilio + 0{mat código + dictan año + mat_nombre + dpto_código + dpto_nombre}n A partir de la normalización llegamos al siguiente diseño de datos: Profesores = prof_legajo + prof_nombre + prof_domicilio.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. domicilio Para el ejemplo Materias Código. nombre Es_de E d dicta Año Departamentos PROFESORES (AD+ED) = Profesor_Legajo+ Profesor_Nombre. Análisis y Diseño de Sistemas . Diagrama Entidad-Relación. Sea a partir de la normalización o a partir del Diagrama Entidad Relación. En la Descripción Estructurada de Procesos Se reveen los procesos que en su definición hacen referencia a almacenamientos h f i l i normalizados para corregirlos de acuerdo con la normalización. siempre que redefinimos la estructura de los .Clase 18 17 Estas transparencias proveen sólo una referencia a los temas. Análisis y Diseño de Sistemas . atributos. Para su estudio debe remitirse a la bibliografía.Clase 18 14 Impacto en los modelos del Análisis Estructurado Impacto en los modelos del Análisis Estructurado En el Diagrama de Flujos de Datos: Se reveen los diferentes niveles del DFD donde aparecen los almacenamientos que fueron normalizados y se reemplazan por los nuevos almacenamientos. almacenamientos.Clase 18 13 Análisis y Diseño de Sistemas . A partir de plantear los atributos. Abraham Silberschatz – Capítulo 2. Análisis y Diseño de Sistemas . relaciones.Clase 18 15 Análisis y Diseño de Sistemas .Clase 18 16 Temas de la clase de hoy Modelo ER Componentes: entidades.Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er. Conclusiones Impacto en los modelos del Análisis Estructurado Existen distintos caminos para encontrar un modelo de datos apropiado: A partir de construir el modelo Entidad Relación. sus dependencias y seguir el camino de la normalización. Relaciones distinguidas distinguidas. Se revisan los procesos de transformación para verificar los accesos a los almacenamientos.Cuatrimestre de 2007. A partir de identificar intuitivamente los almacenamientos en el DFD. Análisis y Diseño de Sistemas . Bibliografía: “Fundamentos de Base de Datos”. en el Diccionario de Datos: Se reemplazan las definiciones de los almacenamientos por las nuevas definiciones normalizadas. Restricciones de mapeo y cardinalidad. 3 .