Volver a Página de Inicio Volver
HERRAMIENTAS DE MODELADO DE SISTEMAS
Un día sin sonrisas es un día perdido..!! PARADIGMA
Cuanto un sistema funciona bién...
..es porque algo ha salido mal..!!
Wilucha
BIENVENIDO AL MUNDO SISTEMICO..!!

El modelado o modelización abarca las técnicas destinadas a generar una representación ideal de un objeto o fenómeno real, mediante simplificaciones y abstracciones de un sistema real, tratando de imitar el accionar del fenómeno del mundo real, abarcando sus aspectos complejos, de manera que luego nos permita plantear pronósticos sobre su comportamiento.
Los tipos del modelo o prototipo del sistema que buscan proporcionar información a bajo costo sobre las características de su comportamiento y un rápido conocimiento de las condiciones no observadas en el sistema real, son:

  • MODELO ESENCIAL
    • Modelo AMBIENTAL
      • Declaración de propósitos
      • Diagramas de contexto
      • Lista de acontecimientos

    • Modelo de COMPORTAMIENTO
      • Modelo de PROCESOS
      • Modelo de DATOS

  • MODELO DE IMPLEMENTACIÓN
    • Modelo de DISTRIBUCIÓN
      • Modelo de tareas
      • Modelo de procesadores

    • Modelo de PROGRAMAS

Un día sin sonrisas es un día perdido..!! PARADIGMA
Se conoce el corazón del hombre
por lo que hace,
..y su sabiduría,
por lo que dice...!!
Taleb
  1. Herramientas de Modelado
  2. Diagrama de Flujo de Datos
    Componentes y tipos de DFD. Flujos convergentes y divergentes. Como construye el analista de sistemas DFD. DFD por niveles. Nivelación ascendente y descendente.
  3. Diccionario de Datos
    Notación y necesidad del Diccionario de Datos en desarrollo de sistemas. Cómo realizar un Diccionario de Datos.
  4. Digrama Entidad Relación
    Componentes del DER. Reglas para construir un DER. Agregación y Eliminación de Tipos de Objetos.
  5. Diagrama Transición de Estados
    Componentes y notación de DTE. Reglas para la construcción de DTE Relación del DTE con el DFD.
  6. Especificación de Procesos
    Herramientas de Especificación de Procesos: pseudocódigo, Tablas de Decisión, Árboles de Decisión, Pre y Pos Condición.
  7. Balanceo de Modelos
  8. Modelo Esencial
    Modelos Ambiental. Modelo de Comportamiento: Inicial y Terminado. Modelo de Implantación del Usuario.
  9. Diseño de Sistemas
    Programación y Prueba. Mantenimiento de la Especificación.
  10. Orientación de Objetos
    Clase, objeto, generalización, asociación, relaciones, interfaz, mé1odo, herencia, polimorfismos. Análisis y Diseño Orientado a Objetos, Modelos y Aplicaciones.
  11. UML: Introducción


Un día sin sonrisas es un día perdido..!! PARADIGMA
Si se juntan suficientes datos
..se puede demostrar cualquier cosa..!!
.. con ayuda del sistema estadístico
Wilucha

Volver al principio


HERRAMIENTAS DE MODELADO Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA
Nunca confies en una PC
que no puedas tirar por la ventana ..!!
Wilucha

Las herramientas de modelado que son instrumentos metodológicos que dan soporte a la ingeniería de software, suelen ser:

  1. D F D: Diagrama de Flujo de Datos
  2. D D: Diccionario de Datos
  3. E R D: Modelo Entidad Relación
  4. D T E: Diagrama de Transición de Estados
  5. Especificación del Proceso

Para el proceso de modelado de sistemas, se acostumbra a manejar los siguientes tipos:

  • MODELO DE DESARROLLO EN CASCADA
    Este enfoque metodológico que ordena las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa espera la finalización de la inmediatamente anterior. Ejemplo, suelen usarse las etapas de:

    1. ANÁLISIS DE REQUISITOS
      Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

      En esta etapa se deben consensuar lo requerido por el sistema y lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

      Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que hará cada parte, así como la manera en que se combinan unas con otras.

    2. DISEÑO DEL PROGRAMA
      Se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como los análisis para saber que herramientas usar en la etapa de Codificación.

    3. CODIFICACIÓN
      O fase de programación propiamente dicha, donde se desarrolla el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. Se crean las librerías y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

    4. PRUEBAS
      Se comprueba que las partes del programa funcionen correctamente antes de ser puesto en explotación.

    5. IMPLANTACIÓN
      Implementan los niveles software y hardware que componen el proyecto; esta fase con mas duración y con más cambios en el ciclo de elaboración de un proyecto, es una de las fases finales del proyecto, que implica la explotación del sistema software donde pueden surgir cambios para corregir errores o para introducir mejoras.

    6. MANTENIMIENTO
      Cualquier error de diseño detectado en la etapa de prueba conduce al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo.

  • MODELO DEL CICLO DE VIDA ESPIRAL
    La Espiral de Barry Boehm o Modelo en espiral, establece los estados de desarrollo de un producto software, desde su concepción inicial, pasando por su puesta en producción y posterior mantenimiento, hasta su retirada del servicio. Este modelo de "Modelos de Ciclo de Vida" cuyo primer modelo fue el de Royce o de Cascada, establece que las diversas actividades que se van realizando para desarrollar un producto Sw. se suceden de forma lineal.

    El Modelo de Ciclo de Vida en Espiral considera el riesgo que aparece a la hora de desarrollar Sw, comienzando por las posibles alternativas de desarrollo, luego se opta por la del riesgo más asumible y se hace un ciclo de la espiral. Si el futuro cliente quiere seguir haciendo mejoras en el Sw. se vuelve a evaluar las distintas nuevas alternativas y se realiza otra vuelta de la espiral hasta que el producto Sw. desarrollado sea aceptado y no deba seguir mejorándo con otro nuevo ciclo. En cada iteración se tiene en cuenta:

    1. Los Objetivos:
      Que necesidad debe cubrir el programa.
    2. Alternativas:
      Las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:
    3. Características:
      Experiencia del personal, requisitos a cumplir.
      • Formas de gestión del programa.
      • Riesgo asumido con cada alternativa.
    4. Desarrollar y Verificar: Programar y probar el programa.

    Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades, se planificaran los siguientes pasos y se volverá a empezar la espiral, de forma de caracol que mantiene dos dimensiones la radial y la angular:

    • Angular = Avance del proyecto Sw. dentro de un ciclo.
    • Radial = Aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

  • MODELO INCREMENTAL
    Proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos, para tratar de lograr el equilibrio entre Casos de Uso y arquitectura durante cada mini proyecto. Así durante todo el proceso de desarrollo, cada mini proyecto es una iteración o recorrido completo a lo largo de todos los flujos de trabajo fundamentales, lográndose así, un incremento que produce un crecimiento en el producto.

  • RUP: PROCESO DE DESARROLLO UNIFICADO
    RUP: Rational Unified Process o Proceso Racional Unificado, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Este proceso RUP tiene tres características esenciales:
    1. - Está dirigido por los Casos de Uso
    2. - Está centrado en la arquitectura
    3. - Es iterativo e incremental.

    La estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos, permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto y así durante todo el proceso de desarrollo, para esto el RUP divide el proceso en cuatro fases

    1. - Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado y requisitos. Se busca

      • - Establecer el ámbito del proyecto y sus límites.

      • - Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la funcionalidad.

      • - Mostrar al menos una arquitectura candidata para los escenarios principales.

      • - Estimar el coste en recursos y tiempo de todo el proyecto.

      • - Estimar los riesgos, las fuentes de incertidumbre.

    2. - En la fase de elaboración, las iteraciones se orientan al desarrollo de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis y diseño. Se busca

      • - Definir, validar y cimentar la arquitectura.

      • - Completar la visión.

      • - Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.

      • - Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable.

    3. - En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Se busca

      • - Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.

      • - Conseguir una calidad adecuada tan rápido como sea práctico.

      • - Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico

    4. - En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios Se busca

      • - Conseguir que el usuario se valga por si mismo.

      • - Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al usuario.

  • PROCESO DIRIGIDO POR CASOS DE USO
    Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema.

    En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema, sino que también guían su diseño, implementación y prueba. Los Casos de Uso son un elemento integrador y una guía del trabajo, que no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo.

  • PROCESO CENTRADO EN LA ARQUITECTURA
    La arquitectura del sistema es la organización de sus partes más relevantes, lo que permite tener una visión común entre desarrolladores y usuarios, y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. Su definición considera elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo.

    Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Así, en las fases iniciales se debe consolidar la arquitectura, que luego se va modificando dependiendo de las necesidades del proyecto.

    Cada iteración pasa por todos los flujos de trabajo relevantes refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Se continúa así, hasta que se haya finalizado por completo con la versión actual del producto, logrado por el proceso descrito en dos dimensiones:

    1. Eje horizontal:
      Representa el tiempo y es considerado el eje de los aspectos dinámicos del proceso. Indica las características del ciclo de vida del proceso expresado en términos de fases e iteraciones.

    2. Eje vertical:
      Representa los aspectos estáticos del proceso. Describe el proceso en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades, artefactos y roles

  • PPS: PROCESO DE SOFTWARE PERSONAL
    Propuesto por Watts Humphrey a partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige a profesionales principiantes, se concentra en las prácticas de trabajo de los profesionals en una forma individual y sirve para producir software de calidad, se diseñó para enseñar a profesionales a cómo planear y darle un seguimiento a su trabajo, a utilizar un proceso bien definido y medido, a establecer metas mesurables, y a la utilización del rastreo constante para alcanzar dichas metas, demuestra cómo manejar la calidad desde el principio del trabajo, cómo analizar los resultados de cada trabajo, y cómo utilizar los resultados para mejorar el proceso del proyecto siguiente.

    • -PRINCIPIOS DE PSP:
      1. - Cada profesional es esencialmente diferente; para ser más precisos, los profesionals deben planear su trabajo y basar sus planes en sus propios datos personales.

      2. - Para mejorar constantemente su funcionamiento, los profesionals deben utilizar personalmente procesos bien definidos y medidos.

      3. - Para desarrollar productos de calidad, los profesionals deben sentirse personalmente comprometidos con la calidad de sus productos.

      4. - Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto que encontrarlos en las etapas subsecuentes.

      5. - Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

      6. - La manera correcta de hacer las cosas es siempre la manera más rápida y más barata de hacer un trabajo.

    • NIVELES DE PSP:
      Las KPA´s son las áreas de procesos clave o Key Process Areas por su significado en inglés, estas áreas ayudan a guiar a los programadores a que exista un mejoramiento notable en el proceso de software.

      La estrategia total de PSP es cerciorarse de que todos los componentes individuales se desarrollen con la más alta calidad. PSP logra esto proporcionando un marco de proceso personal ya definido que el programador puede utilizar. Este marco es:

      1. - Desarrollar un plan para cada proyecto y/o componente.

      2. - Registrar su tiempo de desarrollo.

      3. - Registrar sus defectos

      4. - Conservar sus datos en informes del proyecto

      5. - Utilizar sus datos para planear los proyectos y/o los componentes futuros.

      6. - Analizar sus datos para desarrollar sus procesos con mas calidad para mejorar su funcionamiento.

      Niveles y las KPAs:

      • Nivel 2 - Inicial:
        Seguimiento y control de proyectos

        Planeación de los proyectos

      • Nivel 3 - Repetible:
        Revisión entre colegas.

        Ingeniería del producto de software.

        Manejo integrado del software.

        Definición del proceso de software.

        Foco del proceso de software.

      • Nivel 4 - Definido:
        Control de calidad.

        Administración cuantitativa del proyecto.

      • Nivel 5 - Controlado:
        Administración de los cambios del proceso.

        Administración del cambio tecnológico.

        Prevención de defectos.


Un día sin sonrisas es un día perdido..!! PARADIGMA
Un poco de inexactitud en un sistema..
a veces evita.. toneladas de explicaciones..!!
Wilucha
Volver al principio


D F D: DIAGRAMA DE FLUJO DE DATOS Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA
Cuanto un sistema funciona bién...
..es porque algo ha salido mal..!!
Wilucha

Un DFD permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por conductos por donde circulan los flujos de datos y los almacenes donde se alojan los datos. No proveen información sobre las estructuras operacionales ni de control. Suele también designarse al DFD como:

  • Carta o Diagrama de burbujas.
  • Modelo de proceso o de Función.
  • Diagrama de flujo de trabajo.
  • Imagen de lo que sucede.

El DFD ilustra las funciones que el sistema debe realizar, describiendo:
- ¿qué transformaciones debe llevar a cabo el sistema?
- ¿Qué entradas se transforman en qué salidas?.

  • TIPOS DE D F D
    Sus tipos van de lo más sencillo a lo más complejo, de acuerdo al siguiente orden:

    1. DFD de CONTEXTO
      Definen al sistema con relación a su entorno.
    2. DFD de ANALISIS
      Definen los procesos de conexión entre el sistema y su entorno, indicando el camino que sigue la información y los sitios donde será almacenada o transferida.
    3. Diagramas EXPANDIDOS
      Identifican los subprocesos implícitos en cada uno de los procesos y otras interconexiones entre ellos. Estos diagramas se expanden hasta que el interesado comprende los procesos del sistema en elaboración.

  • COMPONENTES DEL DFD Volver al principio
    Los diagramas de flujo de datos consisten en procesos, agregados de datos y terminadores:

    1. PROCESOS:
      Se representan por medio de círculos, o 'burbujas' en el diagrama. Representan las funciones individuales que el sistema lleva a cabo. Las funciones transforman entradas en salidas

      Los flujos se muestran por medio de flechas curvas, son conexiones entre los procesos y representa la información que dicho proceso necesita como entrada o genera como salida.

      Existen flujos: Convergentes y Divergentes. Los convergentes son aquellos que se unen en una misma burbuja y los divergentes son aquellos que habiendo salido unos de una burbuja, tienden a separarse en caminos diferentes.

      Convergentes:

      Divergentes:

    2. AGREGADOS DE DATOS:
      Se representan por medio de dos líneas paralelas o mediante una elipse. Muestran colecciones de datos que el sistema debe recordar por un período de tiempo. Cuando los diseñadores de sistema y programadores terminen de construir el sistema, estos serán archivos o bases de datos.

    3. TERMINADORES:
      muestran la entidad externa con la que el sistema se comunica, típicamente son individuos; grupos de personas; organizaciones externas; otros sistemas, etc.

      El diagrama de flujo de datos proporciona una visión global de los componentes funcionales del sistema, pero no da detalles de estos. Para mostrar detalles acerca de que información se transforma y como se transforma, se ocupan dos herramientas textuales de modelado adicionales: el Diccionario de Datos y la Especificación de Procesos.

  • CONSTRUCCION DE UN DFD Volver al principio
    La confección de un DFD, suele abarcar el siguiente proceso:

    • Construcción del DFD de PROCESOS SIMPLES:

      1. ELEGIR NOMBRES DE PROCESOS: Ejemplo

        • CALCULAR Sueldo del empleado.
        • VALIDAR Legajo.
        • PRODUCIR Recibo de sueldo.

        Los nombres de procesos, de flujos y terminadores, deben provenir de un vocabulario con significado para el usuario, para ello, si el DFD se dibuja como resultado de una serie de entrevistas con los usuarios y si el analista tiene algún entendimiento de la materia de aplicación, cuidando:

        -> Evitar el uso de abreviaturas y acrónimos específicos con los que están familiarizados los clientes Ej. Consigue copia de la forma 100, y se la manda a José una vez llena.

        -> Si el DFD lo dibuja alguien con conocimientos en programación habrá tendencia a utilizar terminología orientada a la programación, tal como RUTINA, PROCEDIMIENTO, FUNCION.

      2. NUMERAR LOS PROCESOS
        La numeración implica secuencia, pues el modelo de DFD es una red de procesos asincrónicos que se intercomunican; representan la manera en que en realidad muchos sistemas operan. Así, conviene numerar los procesos para poder referirnos a una burbuja por su número en vez de por su nombre y luego los números se convierten en base para la numeración jerárquica cuando se introduzcan diagramas de flujos por niveles.

      3. REDIBUJAR EL DFD COMO SEA NECESARIO ESTETICAMENTE
        En un proyecto real de análisis de sistema, el DFD se dibujará tantas veces como se necesite antes de ser técnicamente correcto, ser aceptable para el usuario, estar lo suficientemente bien dibujado como para mostrarlo a la dirección de la organización.

        Procurar que el tamaño y forma de las burbujas, sean similares en tamaños para no crear confusiones acerca de importancia de un proceso en el proyecto.

      4. EVITAR LOS DFD COMPLEJOS
        El propósito de un DFD es modelar de manera precisa las funciones que deberá llevar a cabo un sistema y las interacciones entre ellas. Otro propósito de este es ser leído y comprendido, no sólo por quien construye el modelo sino también por los usuarios que participan. Entonces el diagrama deberá: ser fácilmente entendido, fácilmente asimilado y placentero a la vista.

      5. EL DFD DEBE SER CONSISTENTE INTERNAMENTE Y CON CUALQUIER DFD RELACIONADO CON EL
        Para asegurar la consistencia de un DFD:
        • Evite sumideros infinitos, burbujas que tienen entradas pero no salidas.
        • Evite burbujas de generación espontánea, que tienen salidas sin tener entradas; son generalmente erróneas.
        • Cuidado con flujos y procesos no etiquetados, suele indicar falta de esmero; pero peor aún confusión respecto a la información que contienen.
        • Cuidado con almacenes de solo lectura o solo escritura, esta regla es similar a la de los procesos de solo entradas o solo salidas, los almacenes comunes deben tener tanto entradas como salidas. La única excepción son los almacenes externos que sirve de interfaz entre el sistema y algún terminador externo.

    • Construcción del DFD de PROCESOS POR NIVELES Volver al principio
      Si el sistema es complejo y tiene muchas funciones que modelar se debe organizar el DFD global en una serie de niveles de modo de que cada uno proporcione sucesivamente más detalles sobre una porción del nivel anterior. Asi, el DFD de primer nivel consta de solo una burbuja, que representa el sistema completo; los flujos de datos muestran las interfaces entre el sistema y los terminadores externos. Este DFD se conoce como DIAGRAMA DE CONTEXTO.

      • ¿EXISTEN REGLAS ACERCA DEL NUMERO DE NIVELES DE UN SISTEMA TIPICO?
        En un sistema simple, se encontraran probablemente dos o tres niveles; uno mediano, tendrá generalmente de tres a seis niveles y uno grande, tendrá de cinco a ocho niveles.

      • ¿DEBEN PARTIRSE LAS PARTES DEL SISTEMA CON EL MISMO NIVEL DE DETALLE?
        No, algunas partes del sistema pueden ser más complejas que otras y pueden requerir uno o más niveles de partición.

      • ¿CÓMO SE MUESTRAN ESTOS NIVELES AL USUARIO?
        Muchos usuarios querrán ver solo un diagrama: Un usuario ejecutivo de alto nivel puede querer ver solo el diagrama de contexto, otro más operacional solo la parte que lo involucra.

      • ¿COMO ASEGURAR QUE LOS NIVELES DEL DFD SEAN CONSISTENTES ENTRE SI?

        Existe una regla: Los flujos de datos que entran y salen de una burbuja en un nivel dado deben corresponder con los que entran y salen en toda la figura en el nivel inmediato inferior que la describe.

      • ¿COMO SE MUESTRAN LOS ALMACENES EN LOS DISTINTOS NIVELES?
        La regla es mostrar el almacén más alto donde sirve de interfaz entre dos o más burbujas; luego mostrarlo en cada diagrama de nivel inferior que describa más a dicha burbuja de interfaz. Luego los almacenes locales que utilicen solo las burbujas en una figura de menor nivel, no se muestra en el nivel superior; puesto que se incluye de manera implícita en un proceso de un nivel inmediato superior.

        Ejemplo de DFD por niveles

      • ¿QUE TIPOS DE NIVELES PUEDO USAR?

        • NIVELACION ASCENDENTE
          Abarca tres reglas:
          1. Cada agrupación de procesos debe involucrar respuestas relacionadas cercanamente. Ésto, usualmente, significa que los procesos manejan datos relacionados cercanamente.
          2. Buscar la oportunidad de esconder o “enterrar” datos almacenados que aparecen en el nivel inferior.
          3. Recordar que la persona que ve el DFD, será un usuario u otro analista, no querrá ver demasiado a la vez.

        • NIVELACION DESCENDENTE
          Si encuentra que lleva tres páginas sobre la burbuja preliminar y que hay más qué decir, seguro que necesita la partición descendente , para lo cual conviene considerar algunas reglas:
          • Enfoque de descomposición funcional pura.
          • Si encuentra una burbuja de proceso que realiza una función compleja, trate de identificar subfunciones, cada una de las cuales puede ser hechas por una burbuja de nivel inferior.
          • En otros casos, los flujos de datos de entrada y salida proporcionarán la mejor guía para la nivelación descendente.


Un día sin sonrisas es un día perdido..!! PARADIGMA
La materia ni se crea ni destruye..
..se regulariza..!!
Wilucha
Volver al principio


DD: DICCIONARIO DE DATOS Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA:
La experiencia es el sistema
que te permite detectar un error ...
...cuando lo vuelves a cometer..!!!
Wilucha

Los diccionarios de datos son el segundo componente del modelo de comportamiento dentro del análisis estructurado, desarrollado despues del Diagrama de Flujo de Datos DFD, herramienta que no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema.

  • Un diccionario de datos es una lista de todos los elementos incluidos en el conjunto de los diagramas de flujo de datos que describen un sistema. Almacena detalles y descripciones de el flujo de datos, el almacenamiento de datos y los procesos.

  • Según [David M. Kroenke]: Un diccionario de datos es una herramienta de importancia para el administrador de la base de datos, es un catalogo accesible para el usuario de datos relacionados. Con la base de datos.

  • Según [Elmasri/Navathe]: Con el termino de diccionario de datos suele designarse una utilería de software más general que un catalogo. Los sistemas de diccionario de datos sirven para mantener información relativa al hardware y software, la documentación y los usuarios del sistema, así como otra información pertinente para la administración del sistema.

El diccionario de datos es un listado organizado de todos los datos pertinentes al sistema, con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento común de todas las entradas, salidas, componentes de almacenes y cálculos intermedios; para esto detalla:

  • El significado de los flujos (representación de los datos en movimiento) y almacenes (representación de paquetes de datos en reposos) que se muestran en los DFD (Diagrama de Flujo de Datos).

  • La composición de los paquetes de datos en los almacenes.

  • La composición de agregados de paquetes de datos que se mueven a lo largo de los flujos, es decir paquetes mas complejos que pueden descomponerse en unidades más elementales.

  • Los detalles de las relaciones entre almacenes que se enfatizan en un diagrama de entidad-relación.

  • EL DICCIONARIO DE DATOS ES NECESARIO PORQUE..
    Para conocer cuántos caracteres hay en un dato, con qué otros nombres o alias se les conoce en el sistema, o en donde se utilizan dentro del sistema debemos ser capaces de encontrar las respuestas en un diccionario de datos desarrollado durante el análisis de flujo de datos y ayuda el analista involucrado en la determinación de los requerimientos de sistemas. Sin embargo, también el contenido del diccionario de datos se utiliza durante el diseño del sistema.

    Para comprender mejor el significado de un diccionario de datos, puede considerarse su contenido como datos acerca de los datos ; es decir, descripciones de todos los demás objetos como archivos, programas, informes, sinónimos del existentes en el sistema. Para ello, almacena la totalidad de los diversos esquemas y especificaciones de archivos, así como sus ubicaciones.

    Si es completo incluye también información acerca de qué programas utilizan qué datos, y qué usuarios están interesados en unos u otros informes. Para esto describe:

    • El significado de los flujos y almacenes que se muestran en los DFD.
    • La composición de agregados de paquetes de datos que se mueven a lo largo de los flujos, es decir, paquetes complejos, que pueden descomponerse en unidades más elementales.
    • La composición de agregados de paquetes de datos en los almacenes.
    • Los detalles de las relaciones entre almacenes que enfatizan en un diagrama de entidad – relación.

    Los analistas usan los diccionarios de datos para:

    1. Manejar los detalles en sistemas grandes
    2. Comunicar un significado común para todos los elementos del sistema
    3. Documentar las características del sistema
    4. Facilitar el análisis de los detalles con la finalidad de evaluar las características y determinar donde efectuar cambios en el sistema
    5. Localizar errores y omisiones en el sistema

  • NOTACION del Diccionario de Datos.
    El diccionario especifica la forma en que se almacenará la información en la computadora; tratando de determinar lo que constituye un dato válido. Para ello, es común usar los siguientes esquemas de notación:

    • Definiciones (Simbolo = = está Compuesto de)
      La definición de una dato se introduce con el símbolo ‘=’. En este contexto, el ‘=’ se lee: ‘se define como’ o ‘se compone de’, o simplemente ‘significa’ Para definir un dato por completo, conviene incluir:
      • El significado del dato dentro del contexto de la aplicación de este usuario.
      • La composición del dato, si se compone de partes elementales con significado.
      • Los valores que pueden tomar el dato.

    • Datos opcionales ( Símbolo= () Optativo)
      Un dato opcional, como la frase implícita, es aquel que puede estar o no presente en un dato compuesto.

      * El nombre de un cliente pudiera no incluir un segundo nombre.

      * El domicilio de un cliente pudiera incluir o no información secundaria, como el numero del departamento.

    • Iteración ( Simbolo = {} )
      La notación de iteración se usa para indicar la ocurrencia repetida de un componente de dato. Ejemplo

      Solicitud= nombre del cliente + domicilio de envió + {artículo}

      Significa que la solicitud siempre debe contener un nombre de cliente, un domicilio de envió, y también cero o más ocurrencia de un articulo. Así, pudiéramos estar tratando con un cliente que pide un articulo, o dos, o varios.

    • Selección (Símbolo = [] Seleccionar una de varias alternativas)
      La notación de selección indica que un dato consiste en exactamente un elemento de entre un conjunto de opciones alternativas. Ejemplo:

      Sexo = [Femenino | Masculino]

      Tipo de Cliente = [ Gobierno | Industria | Universidad | Otro ]

      Es importante revisar las opciones de selección con el usuario para asegurarse de cubrir todas las posibilidades.

    • Alias
      Un alias es una alternativa de nombre usado cuando se trata con diversos grupos de usuarios en diferentes departamentos o ubicaciones geográficas, que insisten en utilizar distintos nombres para decir lo mismo. Ejemplo:

      Comprador = *alias de cliente*.

      Debe evitarse el uso de alias hasta donde sea posible, pues es mejor lograr que todos los usuarios se pongan de acuerdo en un solo nombre.

    • Separador (Símbolo = |)
      Separa opciones alternativas en la construcción.

    • Agragar o Suma (Símbolo = +)
      Sirve para el agragado de elementos en las definiciones de datos.

    • Comentario (Simbolo =¨¨)
      Utilizado para agregar anotaciones sobre los terminos registrados en el diccionario.

  • EJEMPLOS Volver al principio

    1. Ejemplo
      Nombre = titulo+primer_nombre+(nombre_intermedio)+último_ nombre
      Título = [Sr | Sra | Sras | Srta | Dr. | Profesor ]
      Primer_nombre = { caracter_válido }
      Nombre_intermedio = { caracter_valido }
      Ultimo_nombre = { caracter_valido }
      Caracter_válido = { A_Z | a_z | 0_9 | }

    2. Ejemplo
      A = B + C
      PESO = *Peso del paciente al llegar al hospital *
      * unidades:kilogramos; intervalo: 1-200 *
      ALTURA = *Altura del paciente al llegar al hospital*
      *unidades:centímetros;intervalo:20-200*

      altura_actual = **
      * unidades:libras;intervalo:1-400*
      peso_actual = **
      *unidades:pulgadas;intervalo:1-96*
      sexo = **
      *valores: [ M | F ] *

    3. Ejemplo
      nº-de-telefono = *cualquier secuencia correcta de dígitos que provoca una llamada a tel fijo* [cód_área + 4 + numero_tel] cód-área = * sólo para llamadas fuera de la ciudad * 0 + 2{cualquier-digito}4 cualquier-digito = [0|1|2|3|4|5|6|7|8|9] numero_tel= *nº de telefono local del abonado* 5 {dígitos} 7 dígitos = [0|1|2|3|4|5|6|7|8|9]

    4. Datos Opcionales: Ejemplo
      Un dato opcional es aquel que puede estar o no presente en un dato compuesto. Las situaciones de este tipo deben verificarse con cuidado con el usuario y deben documentarse precisamente en el diccionario de datos. Existen muchos ejemplos de datos opcionales en sistemas de información: el nombre de un cliente pudiera o no incluir segundo nombre; el domicilio de un cliente pudiera o no incluir información secundaria, como el nº de departamento; etc.

      Ejemplo: La estructura de dato de carnet referido al ejemplo del sistema de gestión de biblioteca podría haber sido así:

      Carnet Biblioteca = Num_Carnet + Apellidos + Nombres + Tipo Carnet + (DNI)
      	Num_Carnet = 5 {DIGITO} 5
      	Apellidos = 1 {carácter} 50
      Nombres = 1 {carácter} 50
      Tipo Carnet = [Sistemas | Electrónica | Construcción | Eléctrica | Mecánica | Docente]
      DNI = 7 {DIGITO} 8
      DÍGITO = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
      

      Se ve en el ejemplo que el DNI puede o no estar presente en Carnet Biblioteca.

    5. Ejemplo completo: Biblioteca

      Sistema para la gestión de préstamos de libros de una biblioteca. En el diagrama de contexto el sistema interactúa con dos entidades externas: el usuario y el bibliotecario: El usuario elige un libro de la biblioteca, el cual desea retirar. Para esto se dirige al bibliotecario y a través de él realiza el pedido del libro al sistema con su carnet más la ficha que está dentro del libro al igual que para la devolución del libro. Si no ocurriera la devolución el sistema genera según la fecha el flujo de datos correspondiente a la sanción.

      • Modelo de comportamiento:

      • Diccionario de datos del sistema Biblioteca
        Pedido libros = * Info concerniente a la solicitud de préstamo * Carnet_Biblioteca + Ficha_Libro
        	Carnet Biblioteca = Num_Carnet + Apellidos + Nombres + Tipo Carnet
        		Num_Carnet = 5 {DIGITO} 5
        		Apellidos = 1 {carácter} 50
        		Nombres = 1 {carácter} 50
        		Tipo Carnet = [Sistemas | Electrónica | Construcción | Eléctrica | Mecánica | Docente]
        	Ficha_Libro = * libro para préstamos * Num_Ficha_Libro + Libro
        		Num_Ficha_Libro = *es un número autoincremental * 1 {DIGITO} 6
        		Libro = * Datos del libro * ISBN + Título + Autor + Volumen
        			ISBN = * Código internacional asignado a cada tipo de libro * 12{DÍGITO}16
        			Título = 1 {carácter} 50
        			Autor = 1 {carácter} 50
        			Volumen = *copia dentro del establecimiento * 1{Digito}2
        			DÍGITO = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
        	

        Se ve que en el flujo de datos concerniente al pedido del libro están incluidas las estructuras de datos del carnet del socio más la ficha del libro que se encuentra dentro del libro.

        Ficha préstamo = * Info concerniente al préstamo * Num_préstamo + Num_Carnet + Num_Ficha_Libro + Fecha_Prestamo
        	Num_préstamo = * número autoincremental *
        	Num_Carnet = 5 {DIGITO} 5
        	Num_Ficha_Libros = 1 {DIGITO} 6
        		DÍGITO = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
        	Fecha_Prestamo = * fecha actual * Día + Mes + Año
        		Día = [0-31]
        		Mes = [0-12]
        		Año = [1990 – 2030]
        
        Libros disponibles = * Cantidad de volúmenes de cada libro que no se han prestado * Cantidad + Ficha_Libro
        	Cantidad = 1 {DIGITO} 2
        		DÍGITO = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
        	Ficha_Libro = * libro para préstamos * Num_Ficha_Libro + Libro
        		Num_Ficha_Libro = *es un número autoincremental *  1 {DIGITO} 6
        		Libro = * Datos del libro * ISBN + Título + Autor + Volumen
        		ISBN = * Código internacional asignado a cada tipo de libro * 12{DÍGITO}16
        		Título = 1 {carácter} 50
        		Autor = 1 {carácter} 50
        		Volumen = *copia dentro del establecimiento * 1{Digito}2
        
        Alta/bajas libros = Fecha + Ficha_Libro
        	Ficha_Libro = * libro para préstamos * Num_Ficha_Libro + Libro
        		Num_Ficha_Libro = *es un número autoincremental *  1 {DIGITO} 6
        		Libro = * Datos del libro * ISBN + Título + Autor + Volumen
        		ISBN = * Código internacional asignado a cada tipo de libro * 12{DÍGITO}16
        		Título = 1 {carácter} 50
        		Autor = 1 {carácter} 50
        		Volumen = *copia dentro del establecimiento * 1{Digito}2
        			DÍGITO = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
        	Fecha = * fecha actual * Día + Mes + Año
        		Día = [0-31]
        		Mes = [0-12]
        		Año = [1990 – 2030]
        
        Sanción = * sanción aplicada ante la no devolución en tiempo y forma * [amonestación | suspensión | aviso | cobro del libro]
        
DER: DIAGRAMA ENTIDAD RELACION Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA:
Si pudiese volver a la juventud..
cometería todos aquellos errores de nuevo..
solo que más temprano. 
Tallulah Bankhead

El DER es un modelo de red que describe con abstracción la distribución de datos almacenados en un sistema, enfatizando las estructuras de datos y las relaciones para examinarlas, independiente del proceso que se llevará a cabo. Permite comunicarse con el administrador de base de datos, permite ver el tipo de claves o índices o apuntadores que se necesitarán para llegar de manera eficiente a los registros de las bases de datos.


Un día sin sonrisas es un día perdido..!! PARADIGMA:
Errar es humano pero, para enrredar las cosas de verdad..
...hace falta una computadora...!!!
Wilucha
Volver al principio


DIAGRAMA DE TRANSICION DE ESTADOS Volver al principio


Volver al principio


ESPECIFICACION DEL PROCESO Volver al principio
La especificación del proceso es la descripción de lo que sucede en cada burbuja del DFD, describe las reglas sobre cómo realizar el proceso para transformar las entradas en salidas, indicando el proceso a realizar y la transformación de datos. A este fin sus herramientas son:


Un día sin sonrisas es un día perdido..!! PARADIGMA
La única anormalidad..
es la incapacidad de amar..!!
Anais Nin
Volver al principio


BALANCE DE MODELOS Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA
El joven conoce las reglas
pero el viejo las excepciones..!!
Wilucha
El balance de modelos abarca las reglas de balanceo presentadas en el modelo de sistema para detectar errores alguno de los cuales son simples en cada modelo individual, por ejemplo, un diagrama de flujo de datos con un sumidero infinito, otros son errores entre modelos, es decir, inconsistencia entre un modelo y otro.

Una especificación estructurada en la cual todas las herramientas se han verificado entre si para asegurar su consistencia se dice que esta Balanceada.

Los tipos del balanceo son:


Un día sin sonrisas es un día perdido..!! PARADIGMA
La materia ni se crea ni destruye..
..pero se puede perder..!!
Wilucha
Volver al principio


MODELO ESENCIAL Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA
La lógica es un método sistemático de generar..
... con confianza la conclución erronea..!!
Wilucha

El modelo esencial del sistema abarca lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo acerca de como se implanta, así cuando el analista habla con el usuario sobre los requerimientos del sistema, evita describir implantaciones especificas de procesos en el sistema; ni que funciones del sistema están siendo realizadas por humanos o por sistemas de computo existentes.

 
La figura muestra un modelo esencial más apropiado de lo que la función del sistema debe realizar sin importar su implantación final.

El modelo esencial contiene en dos componentes principales:


Un día sin sonrisas es un día perdido..!! PARADIGMA
La materia ni se crea ni destruye..
..pero se puede perder..!!
Wilucha
Volver al principio


DISEÑO DE SISTEMAS Volver al principio Dentro de la creativa tarea de analizar y diseñar sistemas informáticos, opino que existe "un Antes y un Después" definido por el Paradigma Orientados a Objetos. Por ello a pesar del rol que desempeñaron los otros métodos, en esta page solo expondré el Análisis y Diseños Orientados a Objetos, ADOO para los amigos.

Sus conceptos fueron desarrollados para dar soporte a la tecnología de la POO, cuya evolución se remonta al conjunto de conceptos algo desconectados que luego fueron compaginados para formar del nuevo paradigma para la ingeniería de software, cuyos elementos verás en los siguiente links. Para entender este enfoque destaquemos los siguientes conceptos:


Un día sin sonrisas es un día perdido..!! PARADIGMA
La materia ni se crea ni destruye..
..pero se puede perder..!!
Wilucha
Volver al principio


DISEÑO ORIENTACION A OBJETOS: DOO Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA
La lógica es un método sistemático de generar..
... con confianza la conclución erronea..!!
Wilucha


Un día sin sonrisas es un día perdido..!! PARADIGMA
La materia ni se crea ni destruye..
..pero se puede perder..!!
Wilucha
Volver al principio


U M L: Unified Modeling Language Volver al principio

Un día sin sonrisas es un día perdido..!! PARADIGMA:
Lo importante de este sistema
está adentro..!!
Jack el Destripador


Un día sin sonrisas es un día perdido..!! PARADIGMA:
Para estudiar mejor un sistema..
..entiéndolo plénamente, antes de empezar..!!
Wilucha

Volver al principio

27/09/07