Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Análisis Estructurado

Fundamentos de

Ingeniería del Software

Capítulo 3. Análisis de Requisitos

Situación en el

programa de teoría

1. Actividades iniciales.

2. Técnicas de recogida de la información.

3. Requisitos y análisis de requisitos.

4. Actividades generales de análisis de requisitos.

5. Documentos de especificación de requisitos.

6. Análisis estructurado.

7. Introducción a los casos de uso.

6.1. Introducción – Visión

panorámica del AE

ANÁLISIS ESTRUCTURADO

6.1. Introducción - Visión panorámica del AE

6.2. Diagramas de flujo de datos

6.2. Diagramas de flujo de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos

6.5. Modelado de datos

6.6. Historia de vida de las entidades

6.7. El proceso de Yourdon

Introducción

Análisis Estructurado

Método clave en el “desarrollo estructurado” o “convencional”

Aparece a finales de los 70

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

Características principales

Amplia difusión

Descomposición funcional

(Originariamente) Orientada a procesos (Originariamente)

Top/down

(Originariamente)

Top/down

Presente en numerosas metodologías

p.ej. Métrica, SSADM,

information

engineering

Bibliografía

Texto de referencia

Yourdon, E., Análisis estructurado moderno. 1993: Prentice-Hall Hispanoamericana

− Introducción

• Capítulo 4. Herramientas del análisis estructurado

• Capítulo 4. Herramientas del análisis estructurado

• Capítulo 7. Cambios en el análisis de sistemas

− Técnicas

• Capítulo 9. Diagramas de flujo de datos.

• Capítulo 10. El diccionario de datos.

• Capítulo 11. Especificaciones de proceso.

• Capítulo 14. Balanceo de modelos.

− El proceso de análisis

• Capítulo 17. El modelo esencial.

• Capítulo 18. El modelo ambiental.

• Capítulo 19. Construcción de un primer modelo de comportamiento.

Bibliografía (II)

Entre la bibliografía básica...

Piattini, M., et al., Análisis y diseño detallado de Aplicaciones Informáticas de

Gestión. 2004: Ra-ma.

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.

Consejo Superior de Informática.

En castellano y en la biblioteca...

Barranco de Aruba, J., Metodología del Análisis Estructurado de Sistemas (2ª

edición). 2001, Madrid: Publicaciones de la Universidad Pontificia de Comillas.
Hawryszkiewycz, I. T. Introducción al análisis y diseño de sistemas con

ejemplos prácticos. 1ª ed., Madrid : Anaya Multimedia, 1990.

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,

AE utiliza...

Modelado funcional

DFD (Diagrama de Flujo de Datos, Dataflow diagram)

Modelado de datos

Diagrama E-R (Entidad-Relación), o alternativamente,

Diagrama E-R (Entidad-Relación), o alternativamente,

DED (Diagrama de Estructura de Datos)

Modelado del comportamiento

Diagramas HVE (Historia de Vida de las Entidades)

Diagramas de Transición de Estados (STD, State Transition

AE utiliza...

Lógica de procesos

Diccionario de Datos (DD)

Visión panorámica AE

DFDs

Visión general de las funciones y

transformaciones de datos en una

organización

Modelo

lógico

y gráfico del sistema

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

Visión panorámica AE

DFDs (II)

P1

Tipos de símbolos en los DFDs

(notación de Yourdon/De Marco)

P1

Proceso

ENTIDAD EXTERNA

flujo de datos _{D ALMACÉN DE}

Visión panorámica AE

DFDs (III)

Sistema de distribución sin inventario

“Se trata de un sistema que sirve pedidos de libros

Ejemplo

Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.

“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.”

Visión panorámica AE

DFDs (IV)

Análisis de los procesos del sistema

⇒ Aplicamos la visión sistémica

Diagrama de contexto en principio, no son materiales, son datos 0. Sistema de Pedidos EDITOR libros entregados pedidos CLIENTE órdenes de compra libros pedidos

Visión panorámica AE

DFDs (V)

pedidos por título

libros recibidos libros por

clientes

D CLIENTES

estado del crédito

dirección libros entregados libros entregados = albarán + lista-novedades

∈

∈

∈

∈

∈

∈

∈

∈

Visión panorámica AE

DFDs (V)

pedidos por título

libros recibidos libros por

clientes

D CLIENTES

estado del crédito

dirección

libros entregados

D PEDIDOS

PENDIENTES D ÓRDENES DE

Visión panorámica AE

DFDs (VI)

El DFD del ejemplo pertenece al nivel lógico

un FD puede estar contenido en una nota, una factura, una llamada telefónica, etc.

un almacén de datos puede ser una BD o un fichero en papel

no se dice qué deberá ser automático o manual.

no se dice qué deberá ser automático o manual.

... en el nivel lógico

se evita caer en decisiones físicas prematuras

se maneja la complejidad

En un DFD 0 real, se haría una auténtica división en

subsistemas

Se obvian los FD de error

En el ej. no se muestran las funciones de creación,

Visión panorámica AE

Diccionario de Datos

“Es un conjunto de

metadatos

Contiene las definiciones de todos los elementos de los diagramas de los diagramas
Implementación
Manual
Procesador de textos
Base de datos
Automático e integrado ⇐

Visión panorámica AE

Diccionario de Datos (II)

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

Visión panorámica AE

Diccionario de Datos (III)

Fichero o base de datos: Facturas

Descripción: Información, por número de factura, sobre

facturas en el sistema actual.

Sinónimos: *** none *** Composición: @Número-factura @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

Visión panorámica AE

Diccionario de Datos (IV)

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 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:

Visión panorámica AE

Modelado de datos

Diagramas E-R y DED (

Diagrama de

Estructura de Datos

)

DED es, básicamente, un E-R limitado:

DED es, básicamente, un E-R limitado:

no relaciones ternarias

sólo cardinalidades 1:N

no atributos multivaluados ni compuestos

DED. Ejemplo

Visión panorámica AE

Lógica de procesos

Técnicas para describir la lógica de los

procesos primitivos

Lenguaje estructurado

Pre y post-condiciones

Tablas de decisión

Visión panorámica AE

Lógica de procesos (II)

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)

− 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

Visión panorámica AE

Lógica de procesos (III)

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)

ESTADO DE LA CUENTA

CORRECTO IMPAGADO CORRECTO IMPAGADO

NETO-FACTURA >300€ >300€ <=300€ <=300€

Visión panorámica AE

Lógica de procesos (IV)

Tablas de decisión

Visión panorámica AE

Lógica de procesos (V)

Árboles de decisión

Cuentas en buen estado

Cuentas impagadas más de 60 días

Cuentas en buen estado

2. Hacer confirmación y factura

3. Hacer confirmación y factura y escribir mensaje sobre informe de crédito

4. Hacer confirmación y factura

¿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 modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA.

En el paso AE ⇒ DE,

− Análisis de transacciones

Ejemplo de diagrama de

estructuras

Visión panorámica AE

Esquema resumen

Visión panorámica AE

Proceso de aplicación

Aproximación “clásica”

1. Análisis del sistema actual

− Modelo físico, modelo lógico

2. Análisis de requisitos del nuevo sistema

2. Análisis de requisitos del nuevo sistema

3. Diseño de soluciones alternativas

4. Evaluación de las soluciones

5. Selección y documentación de una solución

6. Diseño estructurado

6.2 Diagramas de Flujo de

Datos (DFDs)

6.1. Introducción - Visión panorámica del AE 6.2. Diagramas de flujo de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos 6.5. Modelado de datos

6.6. Historia de vida de las entidades 6.7. El proceso de Yourdon

Símbolos del DFD

(notación Yourdon/De Marco)

P Proceso

Entidad Externa

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

Terminadores (Fuentes o Destinos) (personas, entidades) D ALMACÉN DE DATOS Flujo de eventos Flujo de datos (personas, entidades) Flujos de información (inputs-outputs)

Flujos de control (Ward & Mellor 85) Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)

Símbolos del DFD

(notación Métrica/SSADM)

Transformaciones o procesos

Terminadores (Fuentes o Destinos)

Localización Proceso ID Entidad Externa D ALMACÉN DE DATOS Flujo de datos

Terminadores (Fuentes o Destinos)

Flujos de información

Ficheros o depósitos temporales de información

Procesos

TRANSFORMACIÓN

(cálculo, operación)

FILTRO

FILTRO

(verificación fecha, validación transacción)

DISTRIBUCIÓN

(menú, selección transacción)

P

Transformación

Un consejo:

Keep it simple!

E3 E1

S2 S1

Procesos (II)

Nombres únicos, significativos y concisos

Preferiblemente expresados en función de las entradas y salidas

Recomendación:

Recomendación:

verbo (no ambiguo) + objeto

Evitar verbos ambiguos

procesar, gestionar, manejar...

“objeto” está definido en el DD

Los procesos se descomponen en “subprocesos”,

Diagrama de contexto

Es el DFD más general de todos

Está formado por un solo macroproceso

(el sistema), las entidades externas

(el sistema), las entidades externas

(fuentes y destinos) y sus relaciones con

el macroproceso

Entidades externas

Señalan los límites del sistema y

establecen sus relaciones con el entorno

DESTINO FUENTE P Sistema DESTINO DESTINO FUENTE FUENTE

Los identificadores (nombres) de las entidades externas serán únicos, significativos y concisos

Límites del sistema

Actividad crítica y difícil

Puede haber problemas,

tanto por ser demasiado ambicioso, como poco ambicioso

P Sistema de pedidos Facturación Gestión de caja (pagos) Gestión del almacén Información sobre el crédito Entorno Entorno

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

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

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.

FD que representan.

P

Determinar estado

pedido respuesta estado pedido

petición estado pedido

denegación crédito P Analizar Petición crédito P

Aceptar pago solicitud crédito

autorización crédito

recibo pago

Flujos de datos (III)

Las flechas dobles con sentidos opuestos

que transportan los mismos datos pueden

sustituirse por flechas doblemente

encabezadas

encabezadas

¡Pero sólo si transportan los mismos datos!

P B P A X X P A P B X

Flujos de datos (IV)

Se puede representar, si se desea, el FLUJO DE MATERIAL, usando flechas de trazo grueso

EDITORIALES INTERVENTOR

P1 Selecc. y pedir nuevos

libros

nuevas ofertas Notación Gane & Sarson

EDITORIALES INTERVENTOR P4 Enviar al dpto. comprador P3 Registrar libros nuevos P5 Poner libros nuevos en estantes P2 Examinar nuevos libros D2 ESTANTES D3 INVENTARIO D4 SIGNATURAS D9 CARRITO LIBROS NUEVOS D1 LISTA MAESTRA DE ISBN nuevas ofertas

pedidos de libros nuevos

ajuste de inventario ajuste de signaturas nuevos libros libros nuevos

libros nuevos

libros nuevos libros nuevos

libros nuevos

libros nuevos

Flujos de datos (V)

Se pueden considerar flechas convergentes o divergentes, con un mismo nombre

P A P Validar cod postal dirección cli cod postal P B número de cuenta P Validar calle P Validar Telef. calle telef Observaciones:

Sólo los procesos pueden separar FD (Piattini et al. 04)

Flujos de datos (VI)

Notación System Architect. Ejemplos

FD divergentes (conectores XOR y AND)

P Imprimir P Imprimir factura cliente Imprimir lista empaquetado P Determinar prods.para enviar XOR

cuando los datos son divididos en subconjuntos datos de facturación datos de empaquetado datos de envío P Determinar prescripción P Rellenar prescripción P Actualizar registro paciente AND

cuando todos los datos siguen por ambos caminos

Flujos de datos (VII)

Notación System Architect. Ejemplos

FD convergentes (conectores XOR y AND)

P Aceptar pago en metálico P Transferir pago P Aceptar pago a crédito XOR

cuando los mismos datos provienen de cualquier dirección datos de pago P Confirmar historial de crédito P Conceder tarjeta de crédito P Confirmar empleo AND

cuando los subconjuntos son combinados en uno

historial de empleo historial de crédito historia combinada

Flujos de datos (VIII)

No lo sabemos, no importa:

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

¿El proceso “necesita” ambos FD?

P

Evaluar pedido

criterios valoración pedido

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

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

Procesos que se realizan antes que otros

Sincronización

Periodificación

Extensiones al AE para sistemas en tiempo real:

(Ward & Mellor 85)

Flujos de control (II)

Señales de activación “ON/OFF”

Sirven para “Habilitar/Deshabilitar” procesos

También hay:

Procesos de control

Procesos de control

− Coordinan el resto de procesos

− Usualmente uno por DFD

− Se describen mediante Diagramas de transición de estados

Almacenes de control

− Almacenes de eventos

FD discretos

Flujos de control (III)

Flujos de control (IV)

P

Monitorizar datos satélite

datos satélite habilitar proc satélite

P Monitorizar datos radar P Controlar sistema vigilancia D DATOS DE VIGILANCIA datos radar habilitar proc radar

señal radar señal satélite

Almacenes de datos

Nombre único, significativo y conciso

Convenciones de nombres en los FD a/desde un

almacén:

No lleva etiqueta

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

Consistencia DFD / E-R

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

Correspondencia entre los almacenes de datos

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

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

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 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

Descomposición funcional

Descomposición funcional

Consistencia en el DFD

Cada proceso en un diagrama “padre” es

una consolidación del DFD “hijo”

Balanceo de DFDs

Balanceo de DFDs

Las E/S de un proceso “padre” deben

corresponderse con las E/S del DFD “hijo” que lo explica

Descomposición paralela

Descomposiciones de funciones

Proceso en subprocesos (DFD)

Descomposición de flujos de datos

Descomposición de flujos de datos

La regla de balanceo se aplica teniendo en

Descomposición paralela (II)

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

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

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

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

Jerarquía de DFDs (II)

Jerarquía de DFDs

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

En el DFD 0 se hace una

descomposición en subsistemas, es

decir, se indican los procesos más

importantes en el sistema

Descomposición funcional y

almacenes de datos

Los almacenes aparecen lo más tarde

posible

En un nivel superior únicamente cuando

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

Descomposición funcional y

almacenes de datos (II)

P B P A D FICH P A.2 P A.1 D FICH P B.2 P B.1 D FICH

Tamaño de la jerarquía de

DFDs

Cada DFD debería tener alrededor de 7 procesos o menos (Miller 57) Miller, G.A. The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psycological Review, vol. 63, pp.81-97.

En general, habrá varios niveles intermedios, dependiendo del tamaño y complejidad del 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

Diagrama de funciones Diagrama de subfunciones

Diagrama de procesos (opcional)

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 93) P SIST. DE INVESTIG. DE MERCADOS CENTROS DE INVESTIGACIÓN CLIENTE CLIENTES CORPORATIVOS D DATOS DEL MERCADO informes anuales datos de investigación

datos del mercado

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)

Regla de Balanceo

por simplificación (p.ej. BD Histórica)

RECOMENDACIÓN: si aparece un proceso fuente o

sumidero, replantearse los límites del sistema

P Sumidero P

Localización de los procesos

Form 55 revisado regionalmente Copia de Form 55 Form 55 autorizado Form 55 revisado Form 55 Form 55

STAFF PLANNING CONTROL DE CALIDAD ADMIN REGIONES W, S, N ESCÁNER D600 P Crear Informe 55 P Crear Xact 55 P Det. estado Form 55 P Revisar Form 55 DESTINO DESTINO informe 55 Informe 55 Xact 55 Form 55 aceptado Form 55 no aceptado Form 55 no autorizado

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:

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

Ideas útiles para construir el

DFD (II)

Nombrar adecuadamente todos los

objetos del DFD

Numerar adecuadamente procesos y

diagramas

diagramas

Realizar una correcta división en

subsistemas (DFD 0)

Utilizar la descomposición funcional

jerárquica hasta alcanzar las funciones

primitivas

Ideas útiles para construir el

DFD (III)

La descomposición top/down adolece de

problemas

SOLUCIÓN:

partición de eventos

Es importante que sea preciso y completo, pero

Es importante que sea preciso y completo, pero ¡es muy importante que sea legible!

El convenio de nombres de FD a/desde almacenes

ayuda a hacer el DFD más legible

Agregar FD en los niveles superiores

MEGASUBASTA PÚBLICA 1 GESTIONAR USUARIOS 3 GESTIONAR ANUNCIOS BANCO 2 ADMINISTRAR PUJAS NAVEGANTE D1 PARTICIPANTES e-mail adjudicatario nº de serie datos puja confirmación id. identificación

datos bancarios usuarios nombres usuarios id. usuario registro usuario consulta de datos borrado usuario datos usuario autorización datos bancarios cobro de participación confirmación de cobro datos de usuario confirmación solicitud de anuncio datos de anuncio solicitud de puja nº serie confirmación de cancelación datos de prducto confirmación subasta solicitud de baja notificación de pujas confirmación de baja solicitud de cancelación D F D 0 ( E je mp lo a ). P rá c ti c a s s e p t. 2 0 0 4 4 VALIDAR SUBASTA ADMINISTRADOR D PUJAS D ANUNCIOS D RESULTADOS e-mail adjudicatario id. adjudicatario puja adjudicataria datos resultados consulta de resultados resultados de pujas registro anuncio n. anuncio confirmación de referencia referencia de artículo id. creador anuncio revisado

fecha fin edición anuncio a cancelar datos de subasta anuncio información anuncio petición anuncio datos anuncio pujas relacionadas num. anuncio nº subasta datos de revisión revisión pujas borrado registro de puja nº de serie e-mail login usuario nº cuenta id. usuario registro usuario cargo de penalización confirmación de penalización cargo confirmación de cargo solicitud de resultados listado de resultados nº anuncio pujado listado pujas relacionadas

confirmación de cierre cierre edición impago puja adjudicataria

datos de penalización impago de participación D F D 0 ( E je mp lo a ).

D F D 0 ( E je mp lo b ). P rá c ti c a s s e p t. 2 0 0 4

La Mega Subasta Pública

P3 Gestionar Pujas P1 Gestionar Participantes P2 Gestionar Edición y Subastas D SUBASTAS EXTENDIDAS D SUBASTAS CIEGAS D EDICIONES D PRODUCTOS D PARTICIPANTES avisoPujaExtendid a respuestaPuja peticiónSobrePujas avisoAnulamiento acciónSobreEdicionesYSubastasO K peticiónSobreEdicionesYSubasta s peticiónValidarTarjeta tarjetaValidadaOK acciónSobreParticipanteOK peticiónSobreParticipante D F D 0 ( E je mp lo b ). P5 Genstionar Tranferencia de Productos P4 Seleccionar Ganadores D EDICIONES D SUBASTAS EXTENDIDAS D SUBASTAS CIEGAS D PUJAS D PARTICIPANTES D LISTA DE RESULTADOS avisoAdministrador tranferenciaOK validarTranferencia peticiónDevolverProducto productoDevueltoOK productosAEntregar productoEntregadoOK peticiónConsultaResultados respuestaConsultaResultados avisoGanador peticiónControlResultados respuestaControlResultados

DFDs - Conclusiones

Valiosa herramienta de comunicación

Usuario, analista, diseñador, programador

Se puede combinar con el uso de prototipos

Se puede combinar con el uso de prototipos

Fácil de entender y de aprender

Facilita las relaciones con el usuario

DFDs – Conclusiones (II)

Superado por las metodologías OO,

pero todavía vigente:

− educación

− industria,

− 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

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

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.)

DFDs – Conclusiones (IV)

Según algunos autores, la aproximación

top-down

no es la más correcta para

analizar los sistemas de información

Aunque no es intrínsecamente mala: se

Aunque no es intrínsecamente mala: se puede usar en proyectos pequeños

Alternativamente, se puede usar:

− bottom-up

− de un nivel intermedio hacia arriba o hacia abajo

6.3. Diccionario de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos 6.5. Modelado de datos

6.6. Historia de vida de las entidades 6.7. El proceso de Yourdon

Diccionario de datos (DD)

“Es un conjunto de información (datos) sobre datos”

Objetivos del DD:

Glosario de términos

Glosario de términos

Establecer terminología estándar

Proporcionar referencias cruzadas

Proporcionar control centralizado para cambios

Evolución histórica: desde el directorio/diccionario de datos hasta el diccionario de recursos de información

Posibles elementos para

definir en el DD

Flujos de datos

Procesos

Ficheros Mínimo necesario

Entidades externas

Estructuras de datos

Datos elementales

Cualquier otra cosa que el analista considere conveniente

Información requerida para

cada elemento del DD

Nombre

Tipo de elemento

Breve descripción

Breve descripción

Sinónimos

Observaciones

Información requerida para

cada elemento del DD (II)

Frecuencias y fechas

Volúmenes (Ks estimadas, nº líneas impresas, etc.)

Cuellos de botella, valores máximos y mínimos (tablas,

ficheros, impresos, entradas de datos)

Referencia o código de impreso

Rango de valores permitido y clase (numérico,

alfanumérico, etc.)

Miniespecificaciones (sólo procesos)

Referencias cruzadas

Usuarios afectados

Soporte del DD

Manual

Editor/procesador de textos

Base de datos

Base de datos

Automático e integrado

(sw. específico)

Descomposición

top-down

de datos

todos están definidos en el DD

Ejemplos de descomposición:

− Ficheros en “subficheros” o registros

− Procesos en subprocesos

− Flujos en “subflujos”

Operadores relacionales

“=” — es equivalente a

“+” — y

“<>” — o (inclusivo: al menos una de las opciones)

opciones)

“[ ]”, “|” — o (exclusivo: sólo una de las opciones)

“1{ }N” — iteraciones entre 1 y N veces del término entre llaves

Operadores relacionales (II)

Actualmente (Yourdon 93) “<>” no se usa

(en System Architect tampoco)

Se utiliza “[ ]” , “|” con combinaciones de “( )” y “+”

Ejemplos:

Ejemplos:

direccion-cliente = <direccion-envio, direccion-facturacion> * se puede expresar como *

dirección-cliente = [direccion-envio | direccion-facturacion | direccion-envio + direccion-facturacion]

* si se admite que direccion-cliente esté vacio *

Operadores relacionales (III)

“*...*” —

comentario

@ —

identificador de campo clave en un

almacén (también, alternativamente, se

puede subrayar la clave)

puede subrayar la clave)

Ejemplos:

Solicitud-destino = @nºascensor + (nºplanta) = nºascensor + (nºplanta) * ambas definiciones son equivalentes *

Ejemplos DD

pedido = cupon-correos + (pago-previo) etiqueta = 1{carácter}8

nº-de-telefono =

*cualquier secuencia correcta de dígitos que provoca una llamada *

[extension-local | 9 + numero-exterior] extension-local = * sólo dentro del edificio *

primer-digito + 3{ cualquier-digito}3 primer-digito = [1|2|3|4|5|6|7]

¿Hasta cuándo especificar?

El proceso de descomposición finaliza en

los términos autocontenidos

Ejemplo

Ejemplo

persona = apellidos + nombre + nºss + edad

¿ “edad” es autocontenido?

Sinónimos

Origen:

Distintos usuarios dan distintos nombres a los

mismos objetos

El analista introduce, por error, un nombre distinto

El analista introduce, por error, un nombre distinto

para un objeto ya nombrado

Distintos analistas que trabajan en el mismo proyecto

dan nombres distintos a un mismo objeto

Los sinónimos deben evitarse siempre que sea posible

Ejemplos DD (II)

Nombre: hoja-verde

Sinónimos: petición, solicitud Tipo: sinónimo

Observaciones:

Nombre: estado

Sinónimos: estado-cliente, EST$ Tipo: elemento de datos

Valores y significado:

OK.- Cuenta en buen estado C.- Cuenta cerrada

D.- Cuenta en “números rojos” * cliente moroso * Observaciones:

Ejemplos DD (III)

Nombre: peticion

Sinónimos: solicitud, hoja-verde Tipo: flujo de datos

Composición: [peticion-estado-cliente | peticion-stock | peticion-estado-de-un-pedido | petición-de-materia-prima]

pedido | petición-de-materia-prima] Pertenece a: * ninguno *

Observaciones:

Nombre: Contabilidad de proyectos Sinónimos: Cuentas

Tipo: fichero

Composición: { @nº-de-proyecto + descripción-proyecto + cuenta-del-gabinete + { nombre-del-empleado + fecha-ingreso } }

Organización: * secuencial, por número de proyecto * Observaciones:

Elementos y estructuras de

datos

Son la base sobre la que se definen los

flujos de datos, los almacenes y las

entidades del diagrama E/R.

Un elemento de datos es una pieza de

información atómica.

Una estructura de datos es un registro,

compuesto por otras estructuras o

elementos de datos.

Ejemplos DD (IV)

(Flujo de datos) “Libros prestados” =

[ “Libros entregados” |

“Libros devueltos” ]

donde “Libros entregados” y “Libros

devueltos” son

estructuras de datos

.

“Libros entregados” = {ISBN + Copia-ID }

“Libros devueltos” = { ISBN + Copia-ID }

6.4. Modelado de la lógica de

los procesos

6.1. Introducción - Visión panorámica del AE 6.2. Diagramas de flujo de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos 6.5. Modelado de datos

6.6. Historia de vida de las entidades 6.7. El proceso de Yourdon

Miniespecificaciones (ME)

Proceso primitivo ⇒ miniespecificación

La ME describe las reglas sobre cómo

realizar el proceso para transformar las

entradas en salidas

entradas en salidas

La ME indica el proceso a realizar, la

transformación de datos, no el algoritmo

(que se selecciona en el proceso de

Herramientas para describir

la lógica de los procesos

Lenguaje estructurado

Tablas de decisión

Árboles de decisión

Árboles de decisión

Pre y post-condiciones

Lenguaje estructurado

Vocabulario (restringido) de una lengua

(español, inglés, etc.)

Verbos imperativos

Términos definidos en el DD

Palabras reservadas para formulación lógica (mayúsculas)

Lenguaje estructurado (II)

Los objetos de una ME (sujetos de las

sentencias) serán términos del DD o bien términos locales

Los términos locales se definen explícitamente

Los términos locales se definen explícitamente dentro de una ME, y son conocidos, relevantes y significativos sólo dentro de esa ME (por tanto, no es imprescindible su inclusión en el DD)

Ejemplo:

variables utilizadas para cálculos intermedios, como sumas parciales, dentro de un proceso.

Lenguaje estructurado

-Sintaxis

Sentencia declarativa simple (secuencia)

Estructura de decisión

Estructura de repetición

Estructura de repetición

Combinaciones de las estructuras

Sentencias declarativas

Concisión

Evitar verbos ambiguos (manejar, realizar, procesar,

etc.)

Utilizar verbos precisos que describan acciones

concretas (imprimir, enviar, acumular...) concretas (imprimir, enviar, acumular...)

Mencionar expresamente el objeto de la sentencia,

preferiblemente utilizando los términos del DD

Ejemplos:

Recoger INF-CLIENTE

Separar PETICION

Archivar PETICION en F-PETICION *fichero*

Estructura de decisión

Ejemplos:

a) SI Valor-capital-actual es menor que 600€

SI Condición CASO Condición:Acción(es)

Acción(es)

SINO

Acción(es)

a) SI Valor-capital-actual es menor que 600€

Asignar Cantidad-depreciada = Valor-capital-actual = 0

SINO

Asignar Cantidad-depreciada = 10% de Valor-capital-actual

b) Seleccionar la política que se aplica: Caso 1: (Costo-de-pedido > 1000€) :

enviar por avión

Caso 2: (Costo-de-pedido entre 100€ y 1000€) : enviar por correo urgente

Caso 1: (Costo-de-pedido < 100€) : enviar por correo normal

Estructura repetitiva

REPETIR (condición de selección)

Acción(es)

HASTA (condición de terminación) MIENTRAS (condición)

Acción(es) Acción(es)

FIN MIENTRAS

Ejemplo:

REPETIR para cada registro-de-pasajero en fichero-de-reservas

Acumular Cantidad-debida en Total Construir registro Nuevo-débito Escribir Nuevo-débito en el diario

Estructura repetitiva (II)

a) PARA CADA cliente en fichero-cuentas

Acceder al registro de cuenta del fichero-cuentas Si estado-cuenta es moroso y balance < 10

Poner estado-cuenta en pendiente

Acumular balance-cuenta en total-pendiente Acumular balance-cuenta en total-pendiente

Asignar a fecha-última-transacción la fecha de hoy b)

Poner estado-cuenta en pendiente

Acumular balance-cuenta en total-pendiente

Asignar a fecha-última-transacción la fecha de hoy Acceder al registro de cuenta del fichero-cuentas

Si estado-cuenta es moroso y balance < 10 REPETIR para cada cliente en fichero-cuentas

Lenguaje estructurado

-Observaciones

Utilizar “funciones” o “subrutinas”

Subrayar los términos del DD o usar con

mayúsculas

mayúsculas

en SA, usar comillas

Evitar sentencias largas e imprecisas

Usar indentación o notación de bloque

Usar paréntesis para las combinaciones

Lenguaje estructurado.

Ejemplos (I)

PROCESO 3.1: PRODUCIR RECIBOS EFECTIVO

COMIENZA

efectivo-recolectado = 0

MIENTRAS haya más registros en DINERO LEER siguiente registro en DINERO LEER siguiente registro en DINERO

ENVIAR dinero *en (Yourdon 93) pone “DESPLEGAR”*

efectivo-recolectado = efectivo-recolectado + cantidad-dinero FIN-MIENTRAS reporte-efectivo = efectivo-recolectado ENVIAR reporte-efectivo TERMINA P3 PRODUCIR RECIBOS EFECTIVO D DINERO dinero + reporte-efectivo

Lenguaje estructurado.

Ejemplos (II)

P1 P2 PRODUCIR REPORTE reporte-mensual-ventas reporte-diario-ventas PRODUCIR REPORTE MENSUAL VENTAS REPORTE DIARIO VENTAS D DEVOLUCIONES D CREDITOS D PEDIDOS

Lenguaje estructurado.

Ejemplos (III)

PROCESO 3.2: PRODUCIR REPORTE DIARIO VENTAS

COMIENZA total-diario = 0

MIENTRAS haya más pedido en PEDIDOS con fecha-pedido= fecha actual

LEER siguiente pedido con fecha-pedido = fecha actual LEER siguiente pedido con fecha-pedido = fecha actual

SUMAR numero-factura, nombre-cliente, nombre-compañía, pedido-total como nuevo renglón en reporte-diario- ventas

SUMAR total-pedidos a total-diario

FIN_MIENTRAS

SUMAR total-diario como nuevo renglón en reporte-diario-ventas ENVIAR reporte-diario-ventas

Lenguaje estructurado.

Ejemplos (IV)

PROCESO 3.3: PRODUCIR REPORTE MENSUAL VENTAS COMIENZA

total-ventas = 0

total-devoluciones = 0 total-créditos = 0

MIENTRAS haya más pedido en PEDIDOS con fecha-pedido de este mes MIENTRAS haya más pedido en PEDIDOS con fecha-pedido de este mes

SUMAR total-pedidos a total-ventas

FIN_MIENTRAS

MIENTRAS haya más devolución en DEVOLUCIONES con fecha-devolución de este mes

SUMAR valor-devolución a total-devoluciones

FIN_MIENTRAS

MIENTRAS haya más crédito en CREDITOS con fecha-crédito de este mes

SUMAR monto-de-crédito a total-créditos

FIN_MIENTRAS

reporte-mensual-ventas = total-ventas, total-devoluciones, total-créditos ENVIAR reporte-mensual-ventas

Lenguaje estructurado.

Ejemplos (V)

D LIBROS P4 PROCESAR FACTURAS IMPRENTA factura-imprenta-aprobada autorizacion-fact-imprenta respuesta-fact-imprenta factura-imprenta id-imprenta + fact-imprenta

Lenguaje estructurado.

Ejemplos (VI)

PROCESO 4.4: PROCESAR FACTURA IMPRENTA

COMIENZA

ENCONTRAR libro en LIBROS con clave-libro que corresponda con clave-libro en fact-imprenta SI no se encuentra registro

respuesta-fact-imprenta = “No existen pedidos pendientes para este libro”

ENVIAR respuesta-fact-imprenta

OTRO OTRO

ENVIAR factura-imprenta (a administración para su aprobación) ACEPTAR autorización-factura-imprenta

SI autorización-factura-imprenta = “NO”

respuesta-fact-imprenta = “Factura rechazada; comuníquese con la administración para discutirlo”

ENVIAR respuesta-fact-imprenta

OTRO

respuesta-factura-imprenta = “Factura aceptada”

ENVIAR respuesta-factura-imprenta factura-imprenta-aprobada = fact-imprenta ENVIAR factura-imprenta-aprobada FIN_SI FIN_SI TERMINA

Lenguaje estructurado.

Ejemplos (VII)

PROCESO 6.1: PRODUCIR ETIQUETAS ENVIO

COMIENZA

ORDENAR CLIENTES por código-postal en etiquetas-envío ENVIAR etiquetas-envío TERMINA TERMINA P6 PRODUCIR ETIQUETAS ENVIO D CLIENTES etiquetas-envío solicitud-etiquetas

Tablas de decisión

Autorización de tarjeta de crédito 1 2 3 4

Encabezamiento Reglas Estados de condición Sentencia de acción Anotación de condición Anotación de acción Se han desarrollado procesadores de

Autorización de tarjeta de crédito 1 2 3

Valor de la compra p p > 100€ 50€ < p < 100€ 0< p < 50€

Autorizar automáticamente X

Asignar autorización X X

Autorización de tarjeta de crédito 1 2 3 4

Compra inferior a 50€ Y N N N

Compra entre 50 y 100€ Y N N

Compra superior a 100€ Y N

Autorizado automáticamente X

Dar número de autorización X X

Anotar en la cuenta X Error X procesadores de tablas de decisión que generan automáticamente el código del proceso correspondiente.

Árboles de decisión

año _{cuota a pagar}

Cuotas de socio asociado de grado senior segundo tercero primero segundo tercero primero segundo tercero 4€ 6€ 5€ 6€ 7€ 3€ 4€ 5€

Comparativa

Moderada Muy buena Buena Moderada

Visualización de la Muy buena (pero sólo Moderada (sólo Buena (para todo) Moderada (para todo, de la estructura lógica (pero sólo decisiones) (sólo decisiones)

todo) (para todo, pero

depende del autor)

Simplicidad Muy buena Muy pobre Moderada Buena

Validación por el usuario

Buena Pobre (si el usuario no está formado en TD) Pobre-Moderada Buena Especificación de programa

Moderada Muy buena Muy buena Moderada

Editable por la máquina

Pobre Muy buena Moderada (necesita sintaxis)

Pobre

Pre y post-condiciones

entrar en los detalles del algoritmo

Particularmente útiles cuando:

El usuario tiene tendencia a describir el proceso en

El usuario tiene tendencia a describir el proceso en

términos de un algoritmo particular

El analista está razonablemente seguro de que

existen muchos algoritmos alternativos

El analista desea que el diseñador/programador

explore varios algoritmos, pero no quiere enredarse con el usuario en discusiones acerca del mérito

Precondiciones

Entradas disponibles

“llega el dato X” * en (Yourdon 93) pone “ocurre” *

Relaciones entre las entradas

“llegan detalles de pedido y detalles de envío con el mismo número de cuenta” z y x a cuenta”

“llega un pedido con fecha de entrega de más de 60 días”

Relaciones entre entradas y almacenes

“hay un pedido-de-cliente con número-de-cta-de-cliente que

corresponde con un número-de-cta-de-cliente del almacén de clientes”

Relaciones entre almacenes distintos (o dentro del mismo almacén)

“hay un pedido en el almacén de pedidos cuyo

número-de-cta-del-cliente corresponde con un número-de-cta-del-número-de-cta-del-cliente en el almacén de clientes”

“existe un pedido en el almacén de pedidos con fecha-de-envío igual a la fecha actual”

Post-condiciones

Salidas producidas

“se producirá una factura”

Relaciones entre entradas y salidas

“la factura-total se calcula como suma de

precios-unitarios-de-artículos más costos-de-envío” de-artículos más costos-de-envío”

Relaciones entre salidas y almacenes

“el balance-actual en el almacén INVENTARIO se

incrementará con cantidad-recibida, y el nuevo

balance-actual se producirá como salida de este proceso”

Cambios en los almacenes

“el pedido se anexará al almacén de PEDIDOS”

Pre y post-condiciones

Ejemplos

ESPECIFICACIÓN DE PROCESO 3.5: CALCULAR

EL IMPUESTO SOBRE VENTAS

Precondición 1

− Llega DATOS-VENTA con TIPO-ITEM que corresponde con CATEGORÍA-ITEM en CATEGORÍAS-IMPUESTO

− Llega DATOS-VENTA con TIPO-ITEM que corresponde con CATEGORÍA-ITEM en CATEGORÍAS-IMPUESTO

Postcondición 1

− IMPUESTO-SOBRE-VENTA se hace igual a MONTO-VENTA * IMPUESTO

Precondición 2

− Llega DATOS-VENTA con TIPO-ITEM que no concuerda con CATEGORÍA-ITEM en CATEGORÍAS-IMPUESTO

Postcondición 2

Pre y post-condiciones

Ejemplos (II)

Precondición 1

El comprador llega con un número-de-cta que corresponde con un número de cuenta en CUENTAS, cuyo código-de-status es “válido”

Postcondición 1

Postcondición 1

Se produce una factura con número-de-cuenta y monto-de-venta

Precondición 2

La precondición 1 falla por algún motivo (el número-de-cta no se encuentra en CUENTAS, o el código-de-status no es “válido”)

Postcondición 2

ME – Otras técnicas

Grafos y diagramas propios del usuario

Si son claros, se pueden agregar a la especificación

como redundantes.

Diagramas Nassi-Shneiderman

Diagramas Nassi-Shneiderman

Flowcharts

Lenguaje narrativo

Sirve para descripción breve

6.5 Modelado de datos

6.1. Introducción - Visión panorámica del AE 6.2. Diagramas de flujo de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos 6.5. Modelado de datos

6.6. Historia de vida de las entidades 6.7. El proceso de Yourdon

Objetivo

Obtener una representación de la información del

sistema independiente de aplicaciones y dispositivos físicos

⇒ Facilitar cambios en los requisitos, SGBD, equipos físicos

Con el análisis estructurado moderno de Yourdon el

Con el análisis estructurado moderno de Yourdon el

modelado de datos cobra la misma importancia que el modelado de procesos.

Técnicas de modelado de datos en AE:

E/R ⇐ RECOMENDADO

DED (Diagramas de Estructura de Datos)

Representa esquemas

DED

BD lógica, no simplificada ni optimizada, a

efectos de validación por el usuario

(esta especificación pasaría al

implementador de la BD)

implementador de la BD)

BD optimizada y normalizada, lista para

ser implementada físicamente

Diseño externo, lógico

DED (II)

“E/R limitado”

Sólo interrelaciones de grado 2

− Ternarias: descomponer

Cardinalidad sólo 1:N

− Otras cardinalidades:

− Cardinalidad 1:1

• Agrupar las dos entidades

• Conservar las dos entidades, con una interrelación en cualquier sentido

− Cardinalidad M:N

• Entidad auxiliar con dos relaciones 1:N

JUGADOR EQUIPO

DED. Ejemplo

Notación [EN2002] (Chen) Elmasri, R.; Navathe, S.B. : "Fundamentos de Sistemas de Bases de Datos". 3ª Ed. Madrid [etc.]: Addison-Wesley, Pearson Educación, 2002. Proyecto Empleado asignado (0,n) (1,m) Asignación Departamento Empleado Proyecto requiere tiene pertenece DED

DED. Interrelaciones

Interrelaciones OPCIONALES

Interrelación opcional en el extremo B y obligatoria en el A

“∀ ocurrencia de A pueden ∃ o no una o varias ocurrencias de B, y para cada

ocurrencia de B existe una ocurrencia de A asociada”

B A

DED. Interrelaciones (II)

Interrelaciones EXCLUSIVAS

Dos o más interrelaciones entre varias

entidades son exclusivas si la existencia de una implica la no existencia de la otra

una implica la no existencia de la otra

− P.ej. En la CARM...

(notación De Miguel Piattini)

CONSEJERÍA

EMPRESA EXTERNA

6.6. Historia de vida de las

entidades

6.1. Introducción - Visión panorámica del AE 6.2. Diagramas de flujo de datos

6.3. Diccionario de datos

6.4. Modelado de la lógica de los procesos 6.5. Modelado de datos

6.6. Historia de vida de las entidades 6.7. El proceso de Yourdon