Docstoc

Análisis de requisitos. Análisis Estructurado

Document Sample
Análisis de requisitos. Análisis Estructurado Powered By Docstoc
					 Análisis y Diseño Estructurado

                                Diagrama de Flujo de Datos

ENTIDAD
EXTERNA
                   P1
                 Proceso          Docente : Yessica Gómez Gutiérrez
flujo de datos   D ALMACÉN DE
                   DATOS




                                                                      1
                                           Introducción




Objetivo: Obtener una especificación detallada del SI,
  y de sus interfaces con otros sistemas, que satisfaga
  las necesidades de información de los usuarios y
  sirva de base para el diseño.
Integra las actividades de análisis estructurado
  y OO.
Se refinan los productos obtenidos en el proceso EVS.




                                                          2
Actividades Iniciales y Análisis de Requisitos.       Introducción
                                  Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI)
Definición del Sistema.



                   Productos que se generan:
                    Catálogo de requisitos
                    Glosario
                    En AE,
                       Contexto del sistema
                       Modelo conceptual de datos
                    En AOO,
                       Modelo del negocio / Modelo del dominio
                    Catálogo de estándares y de normas
                    Catálogo de usuarios (participantes y finales)
                    Entorno tecnológico del sistema
                    Plan de trabajo

                                                                      3
                                                      Introducción
Actividades Iniciales y Análisis de Requisitos.
                                  Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI)
Establecimiento de los Requisitos




        Objetivo: Definición, análisis y validación de los
         requisitos.
        Se completa el catálogo de requisitos.
        Modelos gráficos de requisitos: casos de uso
         (obligatorios en AOO, opcionales en AE)
        Las tareas se realizan de forma iterativa y con
         continuas realimentaciones y solapamientos.



                                                                     4
                                                                     Introducción
Actividades Iniciales y Análisis de Requisitos.
                                  Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI)
 Obtención de Requisitos




Sesiones de trabajo con los usuarios para extraer los requisitos
(con prioridades): Técnica de recogida de información.
         Catálogo de requisitos.
         Modelo de casos de uso.
 Requisitos funcionales
      Con casos de uso (obligatoriamente) en AOO:
          Actores.
          Casos de uso.
          Breve descripción de cada caso de uso.
 Requisitos no funcionales:
      Restricciones del entorno
      Niveles de servicio del sistema:
          Rendimiento, seguridad, implantación, disponibilidad...

                                                                              5
                                                                       Introducción
Actividades Iniciales y Análisis de Requisitos.
                                  Donde nos encontramos…
Análisis del Sistema de Información (Proceso ASI)
Análisis de los Requisitos




Objetivos:
       Detectar inconsistencias, ambigüedades, duplicidad o escasez de información.
       Se revisan las prioridades.
       Se relacionan requisitos.
       Identificar relaciones entre casos de uso.




 Objetivo:
 Mediante esta tarea, los usuarios confirman que los requisitos especificados en el
 catálogo de requisitos, así como los casos de uso, son válidos, consistentes y
 completos.



                                                                                       6
 Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
           Actividades Iniciales y análisis de necesidades.




Decisión de emprender el proyecto

 Recoger información sobre el proyecto (Directivos
 nivel alto/medio) -Técnicas recogida información



                Informe de Necesidades


               Estudio de la viabilidad del proyecto


                                                            Introducción
                                                                           7
                                                             Introducción
 Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                     Estudio de Viabilidad. EVS.




 Alternativas.
 Evaluación de las alternativas:
    Económico.
    Técnico.
    Legal (p.e. LOPD “Ley Orgánica de Protección de Datos”)
    Operativo.
 Especificación detallada de la alternativa
  seleccionada.
 Definición del plan inicial del proyecto.

                                                                          8
                                                           Introducción
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                       Estudio de Viabilidad.




                                                                          9
                                                            Introducción
Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                       Estudio de Viabilidad.




                                                                         10
                                                                       Introducción
    Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                   Técnicas de recogida de Información.


 En general, el proceso de análisis debería seguir los
  siguientes cinco pasos:
    Identificar las fuentes de información.
    Realizar las preguntas apropiadas.
    Analizar la información.
    Confirmar con los usuarios lo que parece haberse
     comprendido de los requisitos.
    Sintetizar los requisitos en un documento.
             Para la práctica y tras determinar la viabilidad del proyecto, como resultado
             de la aplicación de una o varias de las técnicas de recogida de información
             ,se entregará a los grupos un documento que resume/sintetiza los datos
             obtenidos, que será el punto de partida en la etapa análisis del sistema de
             información.
                                                                                       11
                                                             Introducción
  Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                 Técnicas de recogida de Información.



 Entrevistas vs JAD (Joint Application Design): Basada en la
  creación de equipos de usuarios y analistas que se reúnen para
  trabajar conjuntamente en el establecimiento de las necesidades
  del sw a desarrollar.
 Prototipado: Construcción de una maqueta o modelo de sistema
  para evaluar los requisitos.
 Observación: Análisis in situ del entorno a informatizar.
 Estudio de documentación / Cuestionarios / Tormenta de
  ideas (brainstorming)
 .....
 Posible proceso de Reingeniería. Análisis de los sistemas de
   información existentes.




                                                                           12
                                                                     Introducción
         Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                  Actividades generales de la etapa de análisis. ASI.


                          “El proceso de estudio de las necesidades de los
                          usuarios para llegar a una definición de los requisitos
Análisis de Requisitos:
                          del sistema, de hw. o de sw.”
                          “El proceso de estudio y refinamiento de dichos
                          requisitos” [IEEE Std. 610, Glosario estándar de
                          términos en ingeniería del software]


                     Condiciones que debe cumplir un sistema para satisfacer un
                     contrato, una norma o una especificación.
                     Condición o capacidad que necesita el usuario para poder resolver
REQUISITO:           un problema o conseguir un beneficio determinado.




                                                                                  13
                                                                     Introducción
         Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
                  Actividades generales de la etapa de análisis. ASI.


Requisitos Funcionales: describen la funcionalidad o los servicios que se
  espera que el sistema proveerá: sus entradas y salidas, excepciones, .. etc en
  resumen su lógica.
                  Nuestra asignatura se centrará en este tipo de requisitos, mientras en la asignatura de Diseño de
                     BBDD se centrará en su dominio, aunque el CGR en el mismo.
Requisitos no Funcionales: se refieren a las propiedades emergentes del
  sistema como la fiabilidad, el tiempo de respuesta, la capacidad de
   almacenamiento, la capacidad de los dispositivos de entrada/salida, y la
   representación de datos que se utiliza en las interfaces del sistema.

  Extracción: El proceso mediante el cual los clientes o futuros usuarios del software descubren, revelen, articulan y
  comprenden los requisitos que desean. Técnicas de recogida de información.
  Análisis: el proceso de razonamiento sobre los requisitos obtenidos, detectando y resolución de posibles
  inconsistencias o conflictos.
  Especificación de requisitos: el proceso de redacción o registro de los requisitos. Para este proceso puede
  recurrirse al lenguaje natural, lenguajes formales. Catálogo de requisitos.

  Validación de los requisitos: el proceso de confirmación, por parte de los usuarios o clientes, de que los requisitos
  especificados son válidos, consistentes, completos.

                                                                                                                    14
                                                                Introducción
    Análisis Estructurado. Actividades Iniciales y Análisis de Requisitos.
             Actividades generales de la etapa de análisis. ASI.



 Las características deseables para un buen análisis de los requisitos
  son las siguientes [IEEE 1984b]:


     No ambigua.
     Completa.
     Fácil de verificar.
     Consistente.
     Fácil de modificar.
     Fácil para identificar el origen u las consecuencias de cada
      requisito.
     Fácil de utilizar durante la fase de explotación y mantenimiento.




                                                                           15
Análisis y Diseño Estructurado


•Visión panorámica del Análisis y
Diseño Estructurado.

• Análisis : Diagramas de Flujo de
Datos.

• Diseño: Diagrama de Estructuras
                                                 P1
                              ENTIDAD          Proceso
                              EXTERNA




                              flujo de datos   D ALMACÉN DE

                                                  16
                                                 DATOS
     Visión panorámica del AyDE


Análisis Estructurado
  Método clave en el “desarrollo estructurado”
   o “convencional”
  Aparece a finales de los 70
  Facilita la comunicación en el proceso de
   desarrollo de un sistema de información
     análisis y diseño
     usuarios y analistas
  Sencillo, fácil de entender y fácil de aprender

                                                  17
    Visión panorámica del AyDE.
          Características

Amplia difusión
Descomposición funcional
  (Originariamente) Orientada a procesos
  (Originariamente) Top/down
Presente en numerosas metodologías
  p.ej. Métrica, SSADM, information
   engineering, Merise
Herramientas CASE disponibles

                                            18
    Bibliografía

Texto principal
  Mario Piattini,Jose Calvo-Manzano,Joaquín
   Cervera,Luis Fernandez, Análisis y diseño
   detallado de Aplicaciones Informáticas de
   gestión. Edit. Ra-ma
  Yourdon, E., Análisis estructurado moderno.
   1993: Prentice-Hall Hispanoamericana



                                            19
  Bibliografía (II)

 Entre la bibliografía básica...
    MAP, MÉTRICA versión 2.1. Guía de Técnicas. 1995, Madrid: Ministerio de
     Administraciones Públicas. Secretaría de Estado para la Administración Pública.
     Consejo Superior de Informática.

 Referencias clásicas...
    DeMarco, T., Structured analysis and system specification. 1979, Englewood
     Cliffs, New Jersey: Yourdon Press.
    Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires:
     El Ateneo (traducción de Gane, C. and T. Sarson, Structured systems analysis,
     tools and techniques. Software series. 1979, New Jersey: Prentice-Hall.)




                                                                                  20
       Visión panorámica del AyDE.
              Componentes

DFD (Diagrama de Flujo de Dato Dataflow
 diagram)
Diagrama E-R (Entidad-Relación), o
 alternativamente, DED (Diagrama de
 Estructura de Datos)
 Diagramas HVE (Historia de Vida de las
  Entidades)
 Diagramas de Transición de Estados (STD, State
  Transition Diagram)
                                               21
Visión panorámica del AE. componentes


Lógica de procesos
  Lenguaje estructurado
  Pre y post-condiciones
  Tablas de decisión
  Árboles de decisión
Diccionario de Datos (DD)



                                    22
                                                   P1
                                ENTIDAD          Proceso
                                EXTERNA


 Visión panorámica
    del AE. DFD                 flujo de datos   D ALMACÉN DE
                                                   DATOS




 Visión general de las funciones y
  transformaciones de datos en una organización
 Modelo lógico y gráfico del sistema
   también como modelo físico
 Identifica entradas, salidas, procesos y relaciones
  con el exterior
   ...a nivel general
   ...por refinamiento, a nivel detallado


                                                                23
Visión panorámica del AE. DFD

Tipos de símbolos en los DFDs
(notación de Yourdon/De Marco)

                                   P1
       ENTIDAD                   Proceso
       EXTERNA




      flujo de datos             D ALMACÉN DE
                                   DATOS


                                                24
Visión panorámica del AE. DFD: Ejemplo
              Práctico

  Ejemplo

                Sistema de distribución sin inventario
      “Se trata de un sistema que sirve pedidos de libros
      a unos clientes, con la particularidad de que no
      mantiene un stock o inventario interno. El sistema
      puede agrupar los pedidos que clientes distintos
      hacen a un mismo editor, de manera que se puedan
      conseguir descuentos.”

Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas.
1990, Buenos Aires: El Ateneo.
                                                                                        25
Visión panorámica del AE. DFD: Ejemplo
              Práctico


 Análisis de los procesos del sistema
           Aplicamos la visión sistémica

 Diagrama de contexto
                      CLIENTE           pedidos

                                                         órdenes de compra

                    libros entregados
                                               0.
                                          Sistema de
                                            Pedidos                     EDITOR
 en principio, no
 son materiales,                                       libros pedidos

    son datos                                                                    26
             Visión panorámica del AE. DFD: Ejemplo
                           Práctico

      0. Sistema de pedidos
                             pedidos
                                              D LIBROS
                                                                                             órdenes de compra
                                                      pedidos válidos                 2.
                                      1.
                                                                                   Armar
                                  Verificar            D PEDIDOS
     estado del crédito                                                            pedidos
                                   validez               PENDIENTES                                D ÓRDENES DE
                                                                                  a editores
                                  de pedido                                                          COMPRA
             D CLIENTES                                            pedidos en lote
                                           pedidos por título
                        dirección
                                                            4.                                  3.
                                5.       libros por     Asignar            libros           Verificar    libros pedidos
                             Armar       clientes       libros a         recibidos
libros entregados                                                                             envío
                             entrega                    pedidos                            de editores
                            a clientes
   libros entregados =                                               libros recibidos =
albarán + lista-novedades                                            {título + cantidad}



                  DD                                                                 DD                    27
Visión panorámica del AE. Diccionario de
                Datos

 “Es un conjunto de metadatos, es decir, de
  información (datos) sobre datos”
 Contiene las definiciones de todos los elementos
  de los diagramas
 Implementación
   Manual
   Procesador de textos
   Base de datos
   Automático e integrado

                                                 28
Visión panorámica del AyDE. Diccionario de
                 Datos

Flujo de datos: entrega
Descripción: Conjunto de libros enviados por un
  proveedor a la biblioteca, basado en la relación
  que previamente había recibido.
Sinónimos: *** none ***
Componente de: *** none ***
Composición:
   Libros
   + { Albarán }
Información de entrada y salida
Origen                        Destino
*** Off the diagram ***       Compra libros
PROVEEDORES                   Biblioteca

                                                     29
Visión panorámica AyDE
Diccionario de Datos (III)
Almacen: Facturas
Descripción: Información, por número de factura, sobre
   facturas en el sistema actual.
Sinónimos: *** none ***
Composición:
   @Número-factura
   + Fecha-factura
   + Dirección-cliente
   + { Número-producto
   + Cantidad-producto
   + Costo-unidad-producto }
   + Costo-envío
   + Tasa-de-descuento
   + Neto-factura
   + Estado-factura
Procesos asociados: Según DFD general
       Proc_cancelación        Proc_pago
       Proc_consultas          Adjuntar_albarán
                                                         30
Visión panorámica del AyDE. Pseudocódigo.

Proceso: Verificar estado del socio
Número: 1.1.1
Descripción: Se examina si el socio no está sancionado
Miniespecificación:
   Recibir “Socio ID” del socio
   Leer “SOCIOS” para
     Leer “Flag-de-precaución”
   Si OK, enviar “Socio ID válido”

Complejidad:              Prioridad:
Ratio de transacciones:   Memoria requerida (Kb):
                          Tiempo de proceso:




                                                         31
Visión panorámica del AyDE. Modelado de
                Datos

Diagramas E-R y DED (Diagrama de
 Estructura de Datos)
DED es, básicamente, un E-R limitado:
  no relaciones ternarias
  sólo cardinalidades 1:N
  no atributos multivaluados ni compuestos



                                              32
Visión panorámica del AE. Ejemplo de
               E/R .

                                                Diagrama E-R
  Departamento

          (1,n)                                     [EN2002] (Chen)
    pertenece


          (1,1)
  Empleado                asignado           Proyecto
                  (0,n)              (1,m)




                                             Departamento                Proyecto




                          DED                        pertenece                      requiere



                                             Empleado            tiene   Asignación

                                                                                               33
 Visión panorámica del AyDE. Lógica de
               Proceso.

Técnicas para describir la lógica de los
 procesos primitivos
  Lenguaje estructurado
  Pre y post-condiciones
  Tablas de decisión
  Árboles de decisión



                                            34
 Visión panorámica del AyDE. Lógica de
               Proceso.

Lenguaje estructurado
   SI la factura excede de 300€
      SI la cuenta del cliente tiene alguna factura sin pagar más
       de 60 días, dejar la confirmación pendiente de este pago.
      SI NO (la cuenta está en buen estado)
       hacer confirmación y factura
   SI NO (la factura es de 300€ o menos)
      SI la cuenta del cliente tiene alguna factura sin pagar más
       de 60 días hacer la confirmación, la factura y escribir un
       mensaje sobre informe de crédito
      SI NO (la cuenta está en buen estado)
       hacer confirmación y factura
   FIN-SI.
                                                                     35
      Visión panorámica del AE. Lógica de
                   Proceso.

 Pre y post-condiciones
Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin
   pagar más de 60 días)
Pos1 (confirmación pendiente de este pago)

Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura
   sin pagar más de 60 días)
Pos2 (confirmación y factura realizadas)

Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura
   sin pagar más de 60 días)
Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de
   crédito)

Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna
   factura sin pagar más de 60 días)
Pos4 (confirmación y factura realizadas)                                        36
 Visión panorámica del AyDE. Lógica de
               Proceso.

Tablas de decisión
ESTADO DE LA       CORRECTO   IMPAGADO   CORRECTO   IMPAGADO
CUENTA
NETO-FACTURA        >300€      >300€     <=300€      <=300€


CONFIRMACIÓN                     x
PENDIENTE
HACER                 x                     x          x
CONFIRMACIÓN
HACER FACTURA         x                     x          x

ESCRIBIR MENSAJE                                       x

                                                           37
    Visión panorámica del AyDE. Lógica de
                  Proceso.

   Árboles de decisión
                                                 1. Dejar confirmación
                        Cuentas impagadas        pendiente de los pagos
                        más de 60 días           debidos.
            Factura
            excede de
            300€        Cuentas en buen estado   2. Hacer confirmación y
                                                 factura
 Política
contable

                                                 3. Hacer confirmación y factura y
            Factura     Cuentas impagadas        escribir mensaje sobre informe de
            menos de    más de 60 días           crédito
            300€
                        Cuentas en buen estado   4. Hacer confirmación y
                                                 factura

                                                                           38
       ¿Y después del AE?


DISEÑO ESTRUCTURADO (DE)
 El diseño lógico de los requisitos del nuevo
  sistema de información se convierte en un
  modelo de la aplicación, plasmado en un
  DIAGRAMA DE ESTRUCTURA.
 En el paso AE  DE,
    Análisis de transacciones
    Análisis de transformaciones


                                                 39
Diseño Estructurado: DIAGRAMA DE
ESTRUCTURA. Ejemplo de diagrama de
                                             estructuras


                                                   Evaluar
                                                   peticiones



                              pet aceptada                                          informe préstamo
                                              pet aceptada       informe préstamo



                       Recibir                               Elaborar                      Informar
                       peticiones                            informe                       petición




pet préstamo                                   pet rechazada


               pet préstamo           ok




 Leer                         Consultar             Rechazar
 peticiones                   stock                 petición



                                                                                                       40
                   Visión panorámica AE
                     Esquema resumen
           Diagrama de                                                                 B   DESTINO
           flujo de datos                                              Z     PROC
                                                    X
                                           PROC               PROC
                                   V
                                                         Y                                           Paso al
     FUENTE         A       PROC       W                                                             diseño
                                                  PROC         D ALMACÉN DE
                                                                 DATOS                                  Diagrama de
                                                                                                        estructuras

Descrip.      Descripción              Definición
E. E.                                  del FD
              del proceso                                    Diagrama E-R
                                                             (o DED)



                Diccionario
                de Datos
                                                    Definiciones
                                                    de la BD


                                                                     Definiciones de                        41
                                                                     los módulos
Diagramas de Flujo de Datos
          (DFDs)




                          42
                                     2.- Diagramas de Flujo de
Símbolos del DFD                               Datos
(notación Yourdon/De Marco)


             P
           Proceso       Transformaciones o procesos
                         (funciones, cálculo, selección)

       Entidad Externa   Terminadores (Fuentes o Destinos)
                         (personas, entidades)

       Flujo de datos
                         Flujos de información
                         (inputs-outputs)
      Flujo de eventos
                         Flujos de control (Ward & Mellor 85)

                         Ficheros o depósitos temporales de
       D ALMACÉN DE
         DATOS           información (base de datos, armario,
                         clasificador, etc.)                    43
                                     2.- Diagramas de Flujo de
Símbolos del DFD                               Datos
(notación Métrica/SSADM)




   ID    Localización

        Proceso
                        Transformaciones o procesos

        Entidad
        Externa
                        Terminadores (Fuentes o Destinos)

   Flujo de datos       Flujos de información


   D    ALMACÉN DE      Ficheros o depósitos temporales de
        DATOS
                        información

                                                             44
                       2.- Diagramas de Flujo de
Procesos                         Datos



TRANSFORMACIÓN
 (cálculo, operación)
FILTRO
 (verificación fecha, validación transacción)
DISTRIBUCIÓN
 (menú, selección transacción)
                              E1                    S1
                                        P
                                   Transformación
                             E2                      S2

                             E3

                                                          45
                              2.- Diagramas de Flujo de
                                        Datos
Procesos (II)

 Nombres únicos, significativos y concisos
 Preferiblemente expresados en función de las
  entradas y salidas
 Recomendación:
      verbo (no ambiguo) + objeto
   Evitar verbos ambiguos
            procesar, gestionar, manejar...
   “objeto” está definido en el DD
 Los procesos se descomponen en “subprocesos”,
  hasta llegar a los procesos primitivos
                                                   46
                       2.- Diagramas de Flujo de
                                 Datos
Diagrama de contexto

Es el DFD más general de todos
Está formado por un solo macroproceso
 (el sistema), las entidades externas
 (fuentes y destinos) y sus relaciones con
 el macroproceso
Delimita el sistema y su entorno



                                             47
                                        2.- Diagramas de Flujo de
                                                  Datos
Entidades externas
Señalan los límites del sistema y
establecen sus relaciones con el entorno
           FUENTE                               DESTINO




                                P
           FUENTE             Sistema           DESTINO




           FUENTE                               DESTINO




Los identificadores (nombres) de las entidades externas serán
únicos, significativos y concisos                               48
                             2.- Diagramas de Flujo de
                                       Datos
Flujos de datos

 Los nombres de los FD deben ser únicos,
  significativos y concisos
 Son datos, así que nómbralos como datos.
 Pueden estar indistintamente en singular o en
  plural, ya que en los DFDs no se representan
  cantidades (Barranco 95)
 Los nombres no sirven sólo para identificar los
  datos, sino también la información que se tiene
  sobre ellos
   P.ej. Información (fecha-válida) > Información (fecha)

                                                        49
                                                 2.- Diagramas de Flujo de
                                                           Datos
Flujos de datos (II)

Flujos de datos interactivos (dialog flows)
   Cuando dos FD establecen un diálogo o comparten una acción
    de estímulo-respuesta, pueden dibujarse como un único FD de
    doble flecha, donde ambos extremos deben llevar el nombre del
    FD que representan.
                      P
                 Determinar     petición estado pedido
                   estado
                   pedido                                respuesta estado pedido



        pago                                                               denegación
                            autorización crédito                             crédito
                    P                                                  P
               Aceptar pago                   solicitud crédito     Analizar
                                                                    Petición
     recibo                                                         crédito

                                                                                        50
                          2.- Diagramas de Flujo de
                                    Datos
Flujos de datos (III)

Las flechas dobles con sentidos opuestos
 que transportan los mismos datos pueden
 sustituirse por flechas doblemente
 encabezadas
   ¡Pero sólo si transportan los mismos datos!

    P      X      P           P              P
    A             B           A              B
                                      X
           X




                                                 51
                                                                                                2.- Diagramas de Flujo de
                                                                                                          Datos
Flujos de datos (IV)

 Se puede representar, si se desea, el FLUJO DE
  MATERIAL, usando flechas de trazo grueso
                                                    P1
                                                 Selecc. y
                                                pedir nuevos
EDITORIALES           nuevas ofertas
                                                   libros
                                                                                          INTERVENTOR                     Notación Gane & Sarson

                                          pedidos de libros nuevos

          libros nuevos


                                                         P3       ajuste de inventario     D3     INVENTARIO
     P2
  Examinar                                        Registrar libros
 nuevos libros                                       nuevos        ajuste de signaturas
                                                                                           D4    SIGNATURAS
                          libros nuevos

                                                                       nuevos libros       D1 LISTA MAESTRA
                                                                                                 DE ISBN



                                                                                                P4                                 P5
                                                                     libros nuevos
             libros nuevos                 D9      CARRITO                                 Enviar al dpto.                     Poner libros   libros nuevos
                                                LIBROS NUEVOS                               comprador                           nuevos en                     D2   ESTANTES
                                                                                                               libros nuevos     estantes
                                                                                                                                                                   52
                                2.- Diagramas de Flujo de
                                          Datos
Flujos de datos (V)

 Se pueden considerar flechas convergentes o
 divergentes, con un mismo nombre                                 P
                                                               Validar
                        P                                     cod postal
                                                 cod postal
                        A
                                 dirección cli
                                                        telef
     número de cuenta
                                             calle                 P
                                                                Validar
                        P                       P                Telef.
                        B                    Validar
                                              calle




 Observaciones:
    Sólo los procesos pueden separar FD (Piattini et al. 96)
    No poner FD como señales de activación (Yourdon 89)
                                                                           53
                                                            2.- Diagramas de Flujo de
                                                                      Datos
   Flujos de datos (VI)

    Notación System Architect. Ejemplos
    FD divergentes (conectores XOR y AND)
                                              P
                                          Imprimir
                                                                                                         P
                                            lista                                                    Rellenar
                                        empaquetado                                                prescripción
                            datos de                             P
     P                      empaquetado
Determinar datos de envío                                   Determinar     prescripción
prods.para                                                  prescripción
                                     datos de facturación
  enviar                 XOR                                                     AND
                cuando los datos son                                    cuando todos los datos
              divididos en subconjuntos      P                        siguen por ambos caminos       P
                                         Imprimir                                                Actualizar
                                          factura                                                 registro
                                          cliente                                                 paciente




                                                                                                         54
                                                    2.- Diagramas de Flujo de
                                                              Datos
Flujos de datos (VII)

Notación System Architect. Ejemplos
FD convergentes (conectores XOR y AND)

       P                                                 P
  Aceptar pago                                       Confirmar
   en metálico                                        empleo
                                                                   historial de
                                           P                                      historia           P
                      datos de pago                                empleo
                                       Transferir     historial                   combinada     Conceder
                                          pago        de crédito                                tarjeta de
       P                XOR                                                                      crédito
                                                                               AND
 Aceptar pago    cuando los mismos                       P            cuando los subconjuntos
   a crédito     datos provienen de                 Confirmar          son combinados en uno
                 cualquier dirección                historial de
                                                      crédito




                                                                                                     55
                                           2.- Diagramas de Flujo de
                                                     Datos
 Flujos de datos (VIII)

                                  ¿El proceso “pide” el FD “pedido”?
                       P
     pedido
                 Evaluar pedido



criterios valoración              ¿El proceso “necesita” ambos FD?

   No lo sabemos, no importa:
         Los aspectos procedurales no se manifiestan
          en los DFDs
         Si tales aspectos son relevantes, se deben
          incluir en las miniespecificaciones

                                                                  56
                             2.- Diagramas de Flujo de
                                       Datos
Flujos de control

 En los DFDs no se muestra el control ni el orden
  de ejecución
 No se puede mostrar:
   Procesos que se realizan antes que otros
   Sincronización
   Periodificación
 Extensiones al AE para sistemas en tiempo real:
   (Ward & Mellor 85)
   (Hatley & Pirbhai 87)

                                                  57
                                  2.- Diagramas de Flujo de
                                            Datos
Almacenes de datos
 Nombre único, significativo y conciso
 Convenciones de nombres en los FD a/desde un
  almacén:
   No lleva etiqueta
      El FD se refiere a un paquete (instancia) completo de la
       información contenida en el almacén
   La etiqueta es la misma que la del almacén
      El FD se refiere a uno o más paquetes completos
       (instancias) de la información contenida en el almacén
   La etiqueta es distinta de la del almacén
      El FD se refiere a uno o más componentes (atributos) de
       una o más instancias del almacén


                                                                  58
                           2.- Diagramas de Flujo de
                                     Datos
Consistencia DFD / E-R          (MAP 95)




 Para facilitar validaciones cruzadas entre DFDs y
  E-R (o DED)...

 Correspondencia entre los almacenes de datos
  “principales” (permanentes) del DFD y las
  entidades del E-R
   Cada almacén de un DFD representa una o
    varias entidades del E-R
   Cada entidad del E-R pertenece a un único
    almacén principal de un DFD
                                                  59
                            2.- Diagramas de Flujo de
                                      Datos
Consistencia DFD / E-R (II)

ETIQUETA DE LOS ALMACENES
  Según explosione a
      Entidad de datos  Plural nombre entidad
      Diagrama E-R (o DED)  Nombre diagrama

 DEFINICIÓN DE LOS ALMACENES
   1. Pocos almacenes
       Para cada uno, diagrama E-R (o DED)
   2. Tantos almacenes como entidades se hayan
      identificado
       Preferible (si no hay muchas entidades)   60
                          2.- Diagramas de Flujo de
                                    Datos
Descomposición funcional

 Cada proceso se puede explotar, refinar o
  descomponer en un DFD más detallado
 El DFD de un sistema es realmente un conjunto
  de DFDs dispuestos jerárquicamente
 Los niveles de la jerarquía están determinados
  por la descomposición funcional de los procesos
 La raíz de la jerarquía es el “diagrama de
  contexto”, que es el más general de todos


                                                61
                                                           2.- Diagramas de Flujo de
                                                                     Datos
  Descomposición funcional                                                             (II)

              P     B        DESTINO
         A   Sist
FUENTE                                                                                  B
                                                                            P
                                                                            f5
                                                                 Z
                                   P             X         P
                                   f2                      f4
                         V
                                                     Y
                    P
             A      f1         W            P
                                            f3




                                                                                                       Z
                                                                       P           x2             P
                                                            x1        f43                        f45

                                                      P
                                        X            f41
                                                                                            y2

                                                                                  P
                                                                 y1              f44
                                                            P
                                                 Y         f42

                                                                                                           62
                        2.- Diagramas de Flujo de
                                  Datos
Consistencia en el DFD

Cada proceso en un diagrama “padre” es
 una consolidación del DFD “hijo”
Balanceo de DFDs
  Las E/S de un proceso “padre” deben
   corresponderse con las E/S del DFD “hijo”
   que lo explica



                                               63
                       2.- Diagramas de Flujo de
                                 Datos
Descomposición paralela

Descomposiciones de funciones
  Proceso en subprocesos (DFD)
Descomposición de flujos de datos
La regla de balanceo se aplica teniendo en
 cuenta la descomposición paralela




                                            64
                                    2.- Diagramas de Flujo de
                                              Datos
Descomposición paralela (II)

 Ejemplo:     pedido = autorización + cupón de pedido + pago

                        P2

    P1
               envío

              P6


                              P5
     pedido                                                                envío
                                              autorización
                                                                    P6.2
                       P4
    P3
                                   cupón de        P6.1
                                   pedido



                                                                    P6.3
                                                             pago

                                                                             65
                                  2.- Diagramas de Flujo de
                                            Datos
Jerarquía de DFDs

 En un DFD completo cada proceso tiene un
  número único que lo identifica en función de su
  situación en la jerarquía
 Cada DFD tiene también un número único que
  coincide con el proceso que describe
 Las hojas o nodos terminales corresponden a
  “procesos primitivos” o indescomponibles
 Para cada proceso primitivo existirá una
  miniespecificación.
           Localización
           Proceso        Proceso primitivo en Métrica

                                                         66
                                 2.- Diagramas de Flujo de
                                           Datos
Jerarquía de DFDs (II)

       P 1.2     B
     Proceso A
 A




                     DFD 1.2
                                             P 1.2.2
                                               f2          X


                                         V

                               P 1.2.1                           Y
                                 f1                    P 1.2.3
                           A                 W           f3




                                                                     67
                        2.- Diagramas de Flujo de
Jerarquía de DFDs                 Datos
      DFD 0


El primer diagrama general que sigue al
 de contexto es el número 0 por convenio
En el DFD 0 se hace una
 descomposición en subsistemas, es
 decir, se indican los procesos más
 importantes en el sistema

         Han de ser SUBSISTEMAS

                                             68
                       2.- Diagramas de Flujo de
Descomposición funcional y       Datos
   almacenes de datos


Los almacenes aparecen lo más tarde
 posible
En un nivel superior únicamente cuando
 son interfaz entre procesos
Una vez que aparezca en un DFD, el
 almacén aparecerá otra vez en cada DFD
 de nivel más bajo relacionado

                                            69
    Descomposición      2.- Diagramas de Flujo de
funcional y almacenes de          Datos
        datos (II)


              P                    P
              A                    B
                      D     FICH




                                       P
        P                              B.1
        A.1


                                             D   FICH
                  D       FICH


        P
                                       P
        A.2
                                       B.2




                                                        70
                                  2.- Diagramas de Flujo de
                                            Datos
Tamaño de la jerarquía de DFDs


 Cada DFD debería tener alrededor de 7
  procesos o menos (Miller 57)
 En general, habrá varios niveles intermedios,
  dependiendo del tamaño y complejidad del
  sistema que se está modelando
 ¿Cuántos niveles son convenientes?
    Yourdon: depende del problema
                 Diagrama   de   contexto / sistema
                 Diagrama   de   subsistemas
     Métrica     Diagrama   de   funciones
                 Diagrama   de   subfunciones
                 Diagrama de procesos (opcional)       71
                                          2.- Diagramas de Flujo de
                                                    Datos
Reglas sintácticas en DFDs


El origen y/o el destino de un FD es
 siempre un proceso
   Excepción: almacenes en el diagrama de contexto
    (Yourdon 89)
                                                                     CLIENTE
                                          datos del mercado
             CLIENTES
           CORPORATIVOS        informes anuales
                                                    D    DATOS DEL
                                                         MERCADO




           CENTROS DE     datos de             P            datos del mercado
         INVESTIGACIÓN    investigación     SIST. DE
                                          INVESTIG. DE
                                           MERCADOS




                                                                                72
                                2.- Diagramas de Flujo de
                                          Datos
Reglas sintácticas en DFDs            (II)


Todo almacén y todo proceso tienen uno o
 más FD de E y uno o más FD de S
   EXCEPCIÓN: un almacén puede no tener FD de salida,
    por simplificación (p.ej. BD Histórica)
   RECOMENDACIÓN: si aparece un proceso fuente o
    sumidero, replantearse los límites del sistema

                         P                      P
                       Fuente                Sumidero




                                                        73
                        2.- Diagramas de Flujo de
                                  Datos
Ideas útiles para construir el DFD

Identificar todos los elementos exógenos
Identificar sus relaciones con el sistema
Trabajar según alguna de las siguientes
 filosofías:
  De inputs a outputs
  De outputs a inputs
  Desde una posición intermedia hacia delante
   o hacia atrás

                                                 74
                          2.- Diagramas de Flujo de
                                     Datos
Ideas útiles para construir el DFD (II)


Nombrar adecuadamente todos los
 objetos del DFD
Numerar adecuadamente procesos y
 diagramas
Realizar una correcta división en
 subsistemas (DFD 0)
Utilizar la descomposición funcional
 jerárquica hasta alcanzar las funciones
 primitivas
                                               75
                        2.- Diagramas de Flujo de
                                  Datos
DFDs - Conclusiones

Valiosa herramienta de comunicación
  Usuario, analista, diseñador, programador
  Se puede combinar con el uso de prototipos
Fácil de entender y de aprender
Facilita las relaciones con el usuario
Amplia difusión


                                                76
                                 2.- Diagramas de Flujo de
                                           Datos
DFDs – Conclusiones (II)
 Superado por las metodologías OO,
     pero todavía vigente:
      se enseña en 12 de 15 ppales. universidades españolas,casi
       todas en Chile
      industria,
      administración (Métrica 2.1 y 3),
      cuerpo de conocimiento de ingeniería del software
       (SWEBOK, SEEK, etc.)
 El control no aparece hasta el final de la
  especificación estructurada
 No es inmediato el paso a la codificación y
  prueba  Diseño estructurado
                                                                77
                      2.- Diagramas de Flujo de
                                Datos
DFDs – Conclusiones (III)

Útil para el análisis y para el diseño del
 nuevo sistema
Más adecuado para el nivel lógico, aunque
 también puede ser adecuado para el nivel
 físico (indicando personas concretas,
 lugares geográficos, formatos de datos,
 etc.)


                                           78
                               3.- Diseño: Diagrama de
   Diseño Estructurado               Estructuras
   Introducción
     Concepto y Principios del Diseño
     Inicios del Diseño

     Efectividad del Diseño
            Módulo(laridad)
            Abstracción
            Refinamiento
       Factores de calidad
            Acoplamiento
            Cohesión
     Tipos de Acoplamiento
     Tipos de Cohesión

     Consideraciones para un Diseño de Calidad

     Resultados del Diseño

                                                  79
                               3.- Diseño: Diagrama de
                                      Estructuras



   Diseño Arquitectónico ( Diseño Preliminar)
       Elementos Diagrama de Estructura
       Partición Estructural de un Diagrama de
        Estructura
       Estrategias de Diseño
       Construcción del Diagrama de Estructura




                                                  80
Concepto y Principios del
Diseño
 “ El diseño es un proceso a través del cual los
  requerimientos establecidos en la fase de análisis
  deben traducirse en una representación -que se
  sugiere modular- del producto de software que se
  precisa construir y que se acompaña de los
  procedimientos en virtud de los cuales cada módulo
  debe llevar a cabo su tarea, y de las estructuras de
  datos que debe procesar”
       Larry Constantine „78
                                                     81
 Concepto y Principios del
 Diseño
 El diseño estructurado es un método de configuración de
  la organización modular del software que se desarrolla a
  partir de los flujos de datos que contiene la especificación
  de requerimientos obtenida en la fase de análisis bajo
  enfoque estructurado.     En este sentido, puede decirse
  que este enfoque consiste en el diseño de programas
  como estructuras de funciones únicas y de relativa
  independencia.
                                                          82
Efectividad del Diseño
     Para    poder    evaluar     la   efectividad   de   una
     representación de diseño, es preciso establecer lo
     que    se    denomina   en    Ingeniería   de   software,
     "criterios para un buen diseño", entre los cuales es
     posible destacar los siguientes:



     • El diseño debe exhibir una organización jerárquica
     con    mecanismos de control que no atenten contra
     la independencia relativa de cada componente de la
     jerarquía.

                                                           83
Efectividad del Diseño
    - El diseño debe ser modular, esto es, el software debe
    estar particionado lógicamente en elementos que ejecuten
    funciones y subfunciones específicas.

     - El diseño debe generar módulos que exhiban niveles
    adecuados de independencia funcional.

     - El diseño debe obtenerse a partir de la especificación de
    requerimientos generada durante la fase de análisis.

                                     - Módulo(laridad)

                                     - Abstracción

                                     - Refinamiento

                                                             84
Efectividad del Diseño

 - Módulo(laridad)

 “Módulo es una unidad claramente definida y manejable que forman
 parte de los elementos constituyentes del software”

 “La modularidad consiste básicamente en el particionamiento del
 software en elementos con nombres y direcciones separadas que se
 denominan módulos, los cuales en su composición generan la
 totalidad que debe ser capaz de resolver el problema global que da
 origen a la necesidad de construir un producto de software. “

 Tiene que ver con la separabilidad de las funciones que en conjunto cumplen
 un objetivo mayor, esto es, responden a la idea de totalidades emergentes
 propia de la noción de sistemas.

                                                                        85
Efectividad del Diseño
 - Beneficios de la Modularidad

       - Programas    más   simples,   ya    que   puede   ser   comprendido,
 verificado, programado, depurado, mejorado y alterado por partes.

   -     Módulos      que    pueden    ser     desarrollados     con   relativa
 independencia.

            - Disminución    de la posibilidad de errores al reducir la
 complejidad.

       - Programas que pueden evaluarse por partes, por lo cual todo test
 se hace más fácil.

           - Programas más fáciles de alterar ya que son menores las
 líneas de código a considerar para incorporar los cambios.

         - Módulos de función única que pueden ser reutilizados.
                                                                                  86
Efectividad del Diseño
- Beneficios de la Modularidad

 - La   posibilidad de cometer errores por parte de los programadores
disminuye porque son menos las líneas de código que deben enfrentarse
al mismo tiempo.

  - La rotación de personal se hace menos crítica, ya que los
programadores están involucrados en unidades de código más pequeñas
por lo cual la sustitución resulta menos dificultosa.

- Responder al requerimiento de la división del código en segmentos de
una página, como lo sugiere la programación estructurada, es casi total.




                                                                           87
Efectividad del Diseño

 - Módulo

  El Fan-out es una medida del número de módulos controlados
 directamente por otro módulo (número de subordinados inmediatos
 que posee). El Fan-in indica cuántos módulos controlan
 directamente un determinado módulo (número de superiores
 inmediatos que posee)



   Un    módulo    que   controla   a     otro   se   dice   que   es
 "superordinado" a éste y, recíprocamente, un módulo controlado
 por otro se dice que es "subordinado".


                                                                        88
Efectividad del Diseño
- Módulo




                         Módulo Superordinado




                          Módulo Subordinado




Fan-out : 2

Fan-in : 1
                                        89
      Efectividad del Diseño
             - Módulos & Integración

Costos
o Esfuerzo
                                  Costo Total SW   Costo por Integración




                                                        Costo por Módulo



                                                    N° Módulos
                                                                           90
                           Costos Mínimos
Efectividad del Diseño
 - Abstracción

 “Cuando se considera una solución modular para enfrentar un
 problema, se puede plantear en distintos niveles de abstracción.
 Un nivel superior de Abstracción supone una solución en
 términos amplios, usando un lenguaje del entorno del problema.
 A un niveles más bajos, se toma una orientación más
 procedimental, se combina una        terminologia orientada al
 problema con una orientada a la implementación. El nivel más
 bajo   de   abstracción   permite   que   la   solución   pueda
 implementarse directamente”




                                                                    91
Efectividad del Diseño
- Refinamiento

El refinamiento gradual es una estrategia de diseño top_down cuyo origen
es la propuesta de Niklaus Wirth (WIRTH-71) quien postula que "La
arquitectura de un programa se desarrolla refinando sucesivamente los
niveles de detalle de los procedimientos. De este modo se desarrolla una
jerarquía de procedimientos al descomponer sucesivamente una sentencia
global hasta alcanzar sentencias específicas a nivel de un lenguaje de
programación".

 R. Pressman (PRESSMAN-88) al respecto cita a Wirth señalando que: "En
cada etapa (del refinamiento), se descomponen una o varias de las
instrucciones del programa dado en instrucciones cada vez más detalladas.
Esta descomposición o refinamiento sucesivo termina cuando todas las
intrucciones están expresadas en términos de cualquier lenguaje básico de
                                                                       92
computador o de programación.
    Efectividad del Diseño
        - Refinamiento

         En el dominio de la Ingeniería de Software, la modularización se
        apoya en lo que se conoce como refinamiento sucesivo o
        gradual, para la configuración de la estructura del software que
        se precisa diseñar y luego construír.

Abstracción                                             Refinamiento
                                                          Gradual

                       Módulo A

                                                 Modularidad      Factorización


                                            A1          A2
                                                                            93
Factores de Calidad
- Acoplamiento
Corresponde al grado de independencia entre dos módulos. Entendido
así,   minimizar   el   acoplamiento   aparece   entonces   como    una
determinante prioritaria al configurar las conformaciones estructurales.

La obtención de módulos tan independientes como sea posible,se
puede ser lograda principalmente de tres maneras:

   - Eliminando relaciones innecesarias.

   - Reduciendo el número de relaciones necesarias.

   - Debilitando la dependencia de las relaciones necesarias.



                                                                      94
Factores de Calidad
-   Cohesión
Corresponde a la medida de relación funcional de los elementos de un
módulo, Los elementos de un módulo corresponden a instrucciones,
definiciones de datos, o llamadas o otros módulos. La idea es
organizar estos elementos de tal manera que tengan una mayor
relación entre ellos a la hora de realizar la tarea específica del módulo




                                                                            95
Factores de Calidad

  Acoplamiento




                            Principios de un
                 Cohesión   Buen Diseño




                                               96
Tipos de Acoplamiento

1. Acoplamiento Normal

2. Acoplamiento por Datos

3. Acoplamiento por Estampado o Imagen

4. Acoplamiento de Control

5. Acoplamiento Común

6. Acoplamiento por Contenido

                                         97
     Tipos de Acoplamiento
Mejor Acoplamiento


               NORMAL
                DATOS
                     ESTAMPADO

                        CONTROL

                          EXTERNO (caso especial de COMÚN)

                              COMÚN
                                  CONTENIDO
Grado de
Acoplamiento




                                                             98
 Tipos de Acoplamiento

1.Acoplamiento Normal

Dos Módulo A y B están Normalmente Acoplados si:
          •    Un Módulo A llama a otro B
          •    B retorna el control a A
        No se produce traspaso de parámetros entre ellos, sólo existe la
llamada de uno a otro.

                                A




                                B
                                                                    99
     Tipos de Acoplamiento
2. Acoplamiento por Datos
                                                        Obtener
                                                         Datos
Dos módulos están acoplados por
                                                        Cliente
datos si ellos se comunican por
parámetros, siendo cada parámetro         Rut_cliente
una unidad elemental de datos

El    acoplamiento      por      datos                  Leer Rut
corresponde a la comunicación de
datos necesaria entre módulos. Toda
vez que los módulos tienen que
comunicarse entre sí,    la ligazón por
datos es inevitable y serán adecuadas
si se mantienen a niveles mínimos.
                                                                   100
Tipos de Acoplamiento
3. Acoplamiento por Estampado
                                                      Calcular
o Imagen
                                                       Deuda
                                                       Cliente
 Dos         módulos       aparecen
acoplados      por   estampado     o
                                           Cliente
ligados por imagen si ellos se
refieren a la misma estructura
                                                     Leer Cliente
datos local. Cabe destacar que
por estructura de datos se debe
entender un grupo compuesto
de datos, tal como un registro,
el   cual,    por    su   parte,   se
                                        Cliente= rut+nombres+apellido_paterno+
constituye de varios campos.
                                        Apellido_materno+dirección+fono+e_mail
                                                                     101
Tipos de Acoplamiento

 4. Acoplamiento de Control                 Obtener
                                             Datos
 Dos módulos están acoplados                Cliente
 por control cuando uno de ellos
                                    Tipo_dato       Cliente
 pasa al otro módulo elementos
 de control (flags, switchs) como
 argumentos.                               Leer Cliente

 Provoca       dependencia    de
 ejecución entre un módulo y
 otro.

 No es muy recomendable.

                                                              102
   Tipos de Acoplamiento
                                           Actualizar       Obtener
   5. Acoplamiento Común                     Stock          Nombre
                                             Video           Video
   Los    módulos      presentan
   acoplamiento común, si ellos
   se refieren a la misma área
   estructura de datos (global).
   Cuando sólo se acomplan por                               video
   una variable (global), se trata
   de un Acoplamiento Externo                    Leer Registro
Programas con muchos datos globales son             Video
extremadamente difíciles de entender por
los programadores de mantención, porque
no es fácil saber cuáles son los datos
usados por un cierto módulo.
                                                                     103
      Tipos de Acoplamiento
6. Acoplamiento por Contenido                      A                      B

Este es un tipo de Acoplamiento              ………..                 ………..
Inaceptable.   Dos módulos presentan         Srch: Move..          ………
                                             ………..                 ………..
acoplamiento     de   contenido     (o
                                             ……….                  Jump to Srch
patológico) si uno hace referencia al        ……….                  ……….
interior del otro. Esto ocurre si por        ………                   ………

ejemplo, en un módulo se desvía la
secuencia de instrucciones al interior
de otro o si un módulo altera un         Tal acoplamiento torna el concepto de
comando de otro.                         módulos configurados bajo el criterio de la
                                         caja negra sin sentido, ya que fuerza a un
                                         módulo a conocer explícitamente los
                                         contenidos y la implementación de otro.
                                                                            104
 Tipos de Acoplamiento
 Dos módulos pueden estar relacionados por más de un tipo de
acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación
entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si
dos módulos están ligados por acoplamiento de imagen y acoplamiento
común a la vez, se dirá que los módulos están ligados por acoplamiento
común.

            Enfoques: ¿Cómo Analizar el Tipo de
                      Acoplamiento?

  • Imaginar el Módulo como una Biblioteca

  • Cada Módulo es codificado por un programador diferente

                                                                       105
     Tipos de Cohesión
Mayor Cohesión


             FUNCIONAL                            Módulo como
                 SECUENCIAL                        Caja Negra

                   COMUNICACIONAL


                      PROCEDURAL
                         TEMPORAL                    Módulo
                                                   Transparente
                              LÓGICA
                                COINCIDENTAL
Grado de
Cohesión


                      STEVEN, MYERS, CONSTANTINE y YOURDON (1974)
                      establecieron "una escala de cohesión"   106
  Tipos de Cohesión

1. Cohesión Funcional
                                      Ejemplos
Se puede decir que un
                                      • Calcular el coseno de un ángulo
módulo      con           cohesión
funcional     es        aquel   que   •Calcular el I.V.A. De una factura
contiene    elementos           que
                                      •Verificar el dígito de un RUT
contribuyen a la ejecución
de una y sólo una tarea
relacionada        al     problema
objeto de diseño,.


                                                                       107
  Tipos de Cohesión

2. Cohesión Secuencial
                                     Ejemplo: Calcular Salario
Un   módulo     secuencialmente      1. Obtener sueldo base
cohesionado   es     aquel   cuyos   2. Verificar número de cargas
elementos están envueltos en         3. Revisar días con permiso
actividades tales que los datos      4. Revisar días con licencia
de salida de una actividad sirven    5. Calcular horas de trabajo
como datos de entrada para la        6. Descontar horas de atraso
próxima actividad.                   7. Agregar horas extras
                                     ....


                                                                     108
Tipos de Cohesión

3. Cohesión Comunicacional
                                    Ejemplo:    Obtener      datos
Un módulo presenta cohesión         Video
comunicacional   cuando       sus
                                    1. Obtener nombre video
elementos     contribuyen       a
                                    2. Obtener stock video
actividades que usan la misma       3. Obtener ubicación
entrada o la misma salida. No       4. Obtener precio
importa el orden secuencial         ....




                                                                     109
 Tipos de Cohesión
4. Cohesión Procedimental

un módulo cohesionado por        Ejemplos:     Actividades en
procedimientos es aquel cuyos    una oficina
elementos están envueltos en
                                 1. Hablar por teléfono
actividades     diferentes   y
                                 2. Tomar un café
posiblemente no relacionadas,
                                 3. Leer correo electrónico
en donde el control fluye de
                                 4. Solicitar cotización
una actividad a otra.            ....




                                                                110
 Tipos de Cohesión

5. Cohesión Temporal
                                    Ejemplo:      Actividades   al
 Un   módulo       con   cohesión   iniciar el día
temporal      es   aquel   cuyos
                                    1. Apagar despertador
elementos están envueltos en
                                    2. Tomar una ducha
actividades        que      están
                                    3. Vestirse
relacionadas en función del
                                    4. Hacer la cama
momento en que se realizan.
                                    5. Tomar desayuno
                                    ....



                                                                     111
 Tipos de Cohesión
6. Cohesión Lógica

Un   módulo      tiene     cohesión    Ejemplo: Registrar Pago
lógica,   cuando existe alguna
                                       1. Registrar pago con tarjeta de
relación entre los elementos
                                              crédito
del módulo,     contribuyendo al
desarrollo de actividades de           2. Registrar pago con cheque

una misma categoría general,           3. Registrar pago con efectivo
                                       ....
donde     la   actividad     o   las
actividades a ser ejecutadas se
seleccionan desde fuera del

módulo.
                                                                      112
  Tipos de Cohesión

7. Cohesión Coincidental
                                     Ejemplo:
Un módulo coincidentemente
                                     1. Comprar un libro
cohesionado es aquel cuyos
                                     2. Comer un trozo de torta
elementos              desarrollan
                                     3. Ir al teatro
actividades      sin      relación
                                     4. Lavar la ropa
significativa entre sí.
                                     5. Dormir
                                     ....




                                                                  113
Árbol de Cohesión




                    114
Consideraciones Importantes
para un Diseño de Calidad
 La factorización consiste en separar la funcionalidad de un módulo, en
subfunciones claramente identificables, en términos tales que sea posible
considerarla como constitutiva de un módulo independiente.


1. La necesidad de reducir el tamaño de un módulo.

 2. Obtener las ventajas de la modularización mediante un diseño
"top_down". => Sistema más comprensible el sistema y facilitamiento de
cambios

 3. Evitar que una misma función aparezca en diferentes partes del
sistema, es decir, en más de un módulo.

 4. Proveer módulos de uso general.

 5. Simplificar la implementación.
                                                                     115
Reducir el Tamaño de un
Módulo

 1. De Marco señala,      un tamaño razonable para un módulo
corresponde a un conjunto de líneas de código de alrededor de
media página de listado (30 líneas más o menos),

 2. Page-Jones, señala que toda la codificación de un módulo
debería, idealmente, ser visible en una página de listado (una
exigencia que impone un límite no superior a 60 líneas)

 3. Geral Weinberg (WEI-72) muestran que la habilidad del hombre
para entender un módulo y encontrar errores depende de la
capacidad de aprehender el módulo como un todo de una sola vez.




                                                             116
Resultados del Diseño
El proceso de diseño debe lograr la determinación de las directrizes
en virtud de las cuales el producto de software ha de construirse,
tomando como base la especificación de requerimientos generada en
la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe
dar como resultado:

• el Diseño de la Arquitectura del producto de software a construir.

• la Especificación de los Procedimientos del software a construir.

• el Diseño de los Datos involucrados

• el Diseño de la Interfaz de usuario


                                                                       117
Diseño Arquitectónico




                        118
Diccionario de Datos

    Clave_votante_válida: Flag que indica que la
    combinación ingresada por el cliente es válida, y
    puede llevar a emitir su voto.




                                                        119
    Especificación de procesos
            Nombre : REGISTRAR DATOS
Interfaz     ACTUALIZACIÓN
            Entradas : Datos_actualización
            Salidas     :Datos_actualización,
             datos_actualización_registrados.
            Procedimiento:                                 Pseudocódigo

            Recibir Datos_actualización.
            Abrir archivo INFORMACIÓN MUNICIPAL.
            Escribir en archivo los Datos_actualización.
            Cerrar archivo INFORMACIÓN MUNICIPAL.
            Mandar mensaje indicando
             Datos_actualización_registrados.                   120
Diseño de Datos
                 clave_Vot
                                                                Nom _Cand           Id_Vot o               Nom _Cand
                                                                                                                            P art _Cand
                                       Id_P art ido
      Rut _Vot


                                                                                                                       candidat os
                        Vot ant e                                           Vot o

   Nom _Vot


                                                                                               cont iene


                                                      asigna
                         consult a

                                                                                      Nom_Cand




                                                        Dirección


    Servicios
                       Municipalidad
                                                        Fono

   Nom_Organ


                                                      Com una
    Id_Organ


                                                                                                                                          121
Diseño de Datos

          Votante
      Clave_Vot A10          Voto        Detalle_Voto
      Rut_Vot     A10    Id_Voto A10   Id_Voto     A10
      Nom_Vot     A30                  Id_Partido A30




           Servicio
     Cod_Serv       N5
     Descrip_Serv A30


                                            Candidato
                                         Id_Partido   A30
                                         Nom_Cand     A30

       Municipalidad
     Id_Orga      A10
     Nom_Orga A30
     Servcio      A30
     Dirección    A30
     Fono         N10
     Comuna       A20




                                                            122
Diseño de Interfaz




                     123
Elementos del Diagrama de
Estructura
Obtener
Nombre            Módulo
 Video

 Leer Registro
    Video         Módulo
                  Predetermina
                    do

    X            MÓDULO JEFE
                 (INVOCADOR)




    Y            MÓDULO SUBORDINADO
                 (INVOCADO)
                                      124
  Elementos del Diagrama
  de Estructura
            Obtener
             Datos
            Cliente                      Flujo de Control

Tipo_dato                                Flujo de Dato
                  Cliente



        Leer Cliente




                            Un dispositivo físico es cualquier dispositivo
                            mediante el cual se puede recibir o enviar datos
                            necesarios para el sistema




                             Un almacén de datos corresponde a la instancia real
                             en la cual van a estar los datos que precisa el sistema
                                                                                       125
Elementos del Diagrama de
Estructura

      Conectores




                            126
Elementos del Diagrama de
Estructura
                    Secuencia




        Iteración
                                127
Elementos del Diagrama de
Estructura
                Selección




                            128
Profundidad y Ancho de un
Diagrama de Estructura
                    Profundidad y ancho
                    proporcionan una idea del
                    número de niveles de control
                    y el ámbito global de control
                    respectivamente.
                    El grado de salida es una
                    medida del número de
                    módulos que son controlados
                    directamente por otro
                    módulo.
                    El grado de entrada indica
                    cuántos módulos controlan
                    directamente un módulo
                    dado.

                                            129
Estrategia de Diseño para
Construir Diagrama de
Estructura


             Diseño Centrado en
             Transformaciones


  DFD                             Diagrama de
                                   Estructura
             Diseño Centrado en
             Transacciones



  Análisis         Diseño


                                            130
Estrategia de Diseño
Diseño Centrado en
Transformaciones                      1.1       1.2

                                                            3
• Los datos entran al sistema                                         4.1
mediante caminos que se llaman
                                       2.1       2.2
flujos de entrada
                                                                            4.2
• En el núcleo ocurre la           Flujo de Llegada
transformación de los datos, que                                      Flujo de
                                                           Centro     Salida
entraron anteriormente                                       de
                                                       Transformación
•Finalmente los datos se mueven
por caminos llamados flujos de
salida
                                                                        131
Estrategia de Diseño
Diseño Centrado en
                                                           Camino de
Transacciones
                                                           Acción 1
                                               2.1   2.2
• Se presenta un centro de
transacción, como centro de
flujo de información
                                        1      3.1   3.2    Camino de
                                                            Acción 2
• Desde el centro de flujo de    Centro
Información, surgen muchos       de
                                 Transacción
caminos de acción alternativos                 4.1   4.2
                                                           Camino de
•Los caminos de acción                                     Acción 3
alternativos, son de forma
excluyentes

                                                              132
Estrategia de Diseño:
Transformación
 1. Revisión del Modelo Fundamental del sistema

         DFD, mínimo tres niveles

 2. Determinar si el DFD tiene características de Transformación o
 Transacción

         Analizar el centro de transformación propiamente tal

 3. Aislar el centro de Transformación, especificando los límites del
 flujo de llegada y de salida

        Delimitar   el   centro   de   transformación     (depende   del
 diseñador)

 4. Realizar el primer corte del diagrama de estructura

         Primer nivel de factorización, se incorporan módulos
 coordinadores                                               133
 Estrategia de Diseño:
 Transformación
•Módulos a incorporar
                                                     1.1     1.2
   • Módulo principal Cp, que
                                                                          3
   controla   el   resto    de       los                                             4.1
   módulos                                           2.1      2.2
                                                                     Centro         4.2
   •Módulo    coordinador       de    la                               de
                                                Flujo de Llegada
                                                                 Transformación Flujo de
   Información de Entrada, Ce
                                                                                Salida
   •Módulo controlador del centro
                                           Diagrama de
   de     transformación,            que   Contexto
                                                                     Cp
   supervisa las operaciones de
   los datos, Ct

   •Módulo     controlador,          del        Ce                   Ct                    Cs
   procesamiento           de         la
   información de salida, Cs
                                                                                      134
                                                           Nombres representativos
    Estrategia de Diseño:
    Transformación
5. Ejecución del “segundo nivel de factorización”

a
      1.1      1.2
                         3
b                                   4.1                               Cp
       2.1      2.2                            z
                         Centro         4.2
                           de                               Ce        Ct   Cs
    Flujo de Llegada
                     Transformación Flujo de
                                    Salida
                                                     1.2     2.2       3   4.1


                                                     1.1     2.1           4.2


                                                   Leer a    Leer b        Escribir
                                                                              z

                                                                           135
 Estrategia de Diseño:
 Transformación

6. Refinar la estructura obtenida, utilizando las guías, principios y
conceptos, para un diseño de calidad

        Aumentar o Disminuir el N° de módulos (ejemplo Ct)

        Incorporar flujos de datos (DFD) y de control

7. Asegurarse del trabajo realizado, representado en el diseño
construido

        Verificar funcioanalidad, orden de módulos, etc.




                                                                        136
Estrategia de Diseño:
Transacción
 1. Revisión del Modelo Fundamental del sistema

         DFD, mínimo tres niveles

 2. Determinar si el DFD tiene características de Transformación o
 Transacción

         Analizar el centro de transacción propiamente tal

 3. Aislar el centro de Transacción, especificando los límites del flujo
 de llegada y de salida

         El centro de transacción se encuentra ligado al origen de
 varios caminos de información que fluyen radialmente de él

 4. Realizar el primer corte del diagrama de estructura

         Primer nivel de factorización, se incorporan módulos
 coordinadores                                               137
 Estrategia de Diseño:
 Transacción
•Módulos a incorporar
                                         a
   • Módulo principal Cp, que
                                             A        D
   controla   el    resto   de     los
   módulos                                                            z
                                                      P    Q    R
   •Módulo    coordinador     de    la
   Información de Entrada, Ce                     b

   •Módulo gestor del centro de
                                                          Cp
   transacción, D

   •Módulo     controlador,        los
   distintos caminos que generan             Ce                D
   información de salida,

   Ci   i =1—n (n: n° caminos)
                                                          C1   C2   138 C3
 Estrategia de Diseño:
 Transacción
5. Ejecución del “segundo nivel de factorización”


                                        Camino 1

a                                                                      Cp
     A       D                            Camino 2

                                                       Ce                       D
             P      Q               z
                                R
                                                       a
         b           Camino 3
                                                                C1              C2           C3
                                                     Leer a

                                                                 P          Q            R


                                                                                     Escribir
                                                              Leer b                 139 z
 Estrategia de Diseño:
 Transacción

6. Refinar la estructura obtenida, utilizando las guías, principios y
conceptos, para un diseño de calidad

        Aumentar o Disminuir el N° de módulos

        Incorporar flujos de datos (DFD) y de control

7. Asegurarse del trabajo realizado, representado en el diseño
construido

        Verificar funcionalidad, orden de módulos, etc.




                                                                        140
   Diseño Procedimental (Diseño
    Detallado
    Especificación Interfaz-Función
    Especificación Mediante las
    Miniespecificaciones del Análisis
    Especificación por Pseudocódigo




                                        141
Diseño Detallado
 1. Especificación por interfaz-función

 Permite definir un módulo sin entrar en excesivos detalles. La interfaz del

 módulo contiene los parámetros de entrada y de salida, mientras la función

 del módulo describe las tareas que este lleva a cabo. Se permite el uso de

 tablas, fórmulas, lenguaje natural, etc. Permite variar el grado de

 formalismo en la definición del módulo, generalmente, dando bastante

 libertad a los programadores. Su inclusión como comentario en el código

 final facilita el mantenimiento.




                                                                           142
    Ejemplo:




Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus
preferencias de ubicación sean lo más cercanas (ponderadamente) al asiento
elegido.

                                                                             143
Diseño Detallado
 2. Especificación Mediante las Miniespecificaciones del Análisis

 Este método          considera que las miniespecificaciones
 generadas durante la fase de análisis sirven también
 como      especificación         de   módulos.       Se   considera,    en
 general,     que    la   especificación        de    cada    burbuja    del
 diagrama      de    flujo      de     datos     es    suficiente       para
 especificar        lo que en la fase siguiente al diseño se
 debe construir. La gran limitación de este método es
 que no siempre existe una correspondencia uno a uno
 entre las burbujas, explicitadas como necesarias de
 automatizar en la fase de análisis, y los módulos del
 diagrama de estructura.
                                                                           144
Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus
preferencias deubicación sean lo más cercanas (ponderadamente) al asiento
elegido.
Detalles de Funcionalidad
Buscar asiento disponible comenzando con la clase solicitada y continuando
con clases inferiores.
Anotar para cada asiento la diferencia respecto a la preferencia del cliente.
Seleccionar el asiento con menor diferencia: este será el Asiento-
Seleccionado.
(Diferencia=Dif-Fumador*PESO_FUMADOR+ ...)
Si el cliente necesita un asiento no fumador (y Peso-Fumador > 1) y ha sido
seleccionado un asiento fumador, intentar mover en una fila atrás la sección de
no fumadores en la clase del cliente (si es posible).
Si la diferencia entre el asiento preferido y el asiento seleccionado es 0,
realizar la asignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario
asígnele “N”.
                                                                                  145
Diseño Detallado
 2. Especificación por pseudocódigo

 Pseudocódigo es un lenguaje informal similar al lenguaje estructurado, el

 cual es más preciso y detallado que la especificación por interfaz-función.

 Tiene sintaxis fija para constructores, declaración de datos y módulos, y

 sintaxis libre para describir características de procesamiento




                                                                           146

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:160
posted:7/20/2011
language:Spanish
pages:146