Ingeniería de Software I

7. Análisis Estructurado

Licenciatura en Ciencia de la Computación

Principios del análisis
Cada método de análisis tiene su punto de vista. Sin embargo,
todos los métodos de análisis se relacionan por un conjunto de
principios operativos:

 Debe representarse y entenderse el dominio de la información.

 Deben definirse las funciones que debe realizar el software.
 Debe representarse el comportamiento del software (como
consecuencia de acontecimientos externos).
 Deben dividirse los modelos que representan información,
función y comportamiento de manera que se descubran los
detalles por capas (o jerárquicamente).
 El proceso de análisis debería ir desde la información esencial
hasta el detalle (refinamiento sucesivo).
 El análisis estructurado es un método que cumple estos principios.
2
Análisis estructurado. Modelado
 El modelado del análisis es la primera representación técnica de un
sistema.

 El análisis estructurado es una actividad de “construcción de

modelos”.
 La construcción de los modelos se realiza mediante una notación
que satisface los principios del análisis operacional:
dominio, funciones, comportamiento, partición (división),
refinamiento.

PARTICIÓN:

A menudo, los problemas son demasiado grandes o complejos para

entenderse globalmente. Por este motivo, tendemos a hacer una partición
(dividir) de estos problemas en partes que puedan entenderse fácilmente y
establecer las interacciones entre las partes de manera que se pueda
conseguir la función global.
En esencia, la partición “descompone un problema
en sus partes constitutivas”.
3
Análisis estructurado. Antecedentes
 Primeros trabajos sobre modelos de análisis: década de los 60. El
término “análisis estructurado” fue popularizado por Tom Demarco
(80’).
 Clave en el “desarrollo estructurado” o “convencional”.
 Facilita la comunicación en el proceso de desarrollo de un sistema de
información:
- Analista: entender con precisión lo que el usuario quiere.
- Usuario: entender con precisión el producto que se le ofrece.

 Sencillo, fácil de entender y fácil de aprender. Amplia difusión.

 Descomposición funcional: Orientada a procesos (Top/down).
 Presente en numerosas metodologías: Métrica, SSADM.
 Herramientas Case: System Architect, PowerDesign. 4
Análisis estructurado. Objetivos
El modelo de análisis debe lograr tres objetivos primarios:

1. Describir lo que requiere el cliente.

2. Establecer una base para la creación de un diseño de software

3. Definir un conjunto de requisitos que se puedan validar una vez

que se ha construido el software.

Para lograr estos objetivos, el modelo de análisis (análisis

estructurado) toma la siguiente forma:

5
Análisis estructurado. Objetivos

6
Análisis estructurado. Elementos
En el centro del modelo del análisis se encuentra el
Diccionario
diccionario de datos (un depósito que contiene de Datos
definiciones de todos los objetos de datos consumidos
y producidos por el software).

Tres diagramas diferentes rodean el núcleo:

 El diagrama entidad-relación (DER).

 El diagrama de flujo de datos (DFD).

 El diagrama de transición de estado (DTE).

Cada diagrama (modelo) aporta al Diccionario de Datos.

7
Análisis estructurado. Diagrama E/R
Representa las relaciones entre los objetos de datos. El DER es la
notación que se usa para realizar la actividad de modelado de datos.

DED es, básicamente, un DER limitado:

- NO relaciones ternarias.
- SÓLO cardinalidades 1:N.
- NO atributos multivaluados ni compuestos.

DED

Diagrama E-R
Departamento
(Chen) Proyecto

Departamento

(1,n)
pertenece requiere

pertenece

(1,1)

Empleado asignado Proyecto tiene

(0,n) (1,m) Empleado Emp-Proyecto

8
Análisis estructurado. Diagrama F/D
El DFD representa un modelo del flujo de información del sistema y se
caracteriza porque:

 Representa las funciones (y subfunciones) que transforman el flujo

de datos.

 Muestra las transformaciones aplicadas a los datos desde la

entrada hasta la salida.
E1 S1
P
Transformación
E2 S2
 Especifica QUÉ hace el sistema.
E3

 Permite el particionamiento del sistema en diferentes niveles de

detalle.

9
Análisis estructurado. Diagrama T/E
El diagrama de transición de estados (DTE) indica cómo
se comporta el sistema como consecuencia de sucesos
externos.

Permite expresar el comportamiento del sistema dependiente del

tiempo.

Se aplica este modelamiento a una categoría especial de sistemas

conocidos como sistemas de tiempo real.
Este tipo de sistemas trabajan con fuentes de datos a alta velocidad y
por tanto deben proporcionar respuestas y salidas de datos lo
suficientemente rápidas a las exigencias del entorno del sistema. Una
parte importante para especificar este tipo de sistemas es describir “qué
pasa cuándo”.
Para sistemas de información convencionales, este tipo de modelado no
tiene mayor relevancia. 10
Análisis estructurado. Diagrama T/E (ATM)

11
Análisis estructurado. Modelamiento de procesos
Diagrama de Flujo de Datos (DFD)

 Visión general de las funciones y transformaciones de datos en una

organización.
 Modelo lógico y gráfico del sistema:
QUÉ hace el sistema.
 Identifica entradas, salidas, procesos y
relaciones con el exterior:
...a nivel general
...por refinamiento, a nivel detallado
 Tipos de notación: Yourdon/DeMarco, Métrica/SSADM.

12
Análisis estructurado. Diagrama de Flujo de Datos
Notación Yourdon/DeMarco

P
Transformaciones o procesos (funciones)
Proceso

Entidad Externa Terminadores (fuentes o destinos)

(personas, entidades, otros sistemas).

Flujo de datos
Flujos de información
(inputs-outputs).

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

DATOS
información (base de datos, archivos, etc.).
13
Análisis estructurado. Diagrama de Flujo de Datos
Notación Métrica/SSADM

ID Localización
D Proceso
Transformaciones o procesos.

Entidad Terminadores (Fuentes o Destinos).

Externa

Flujo de datos Flujos de información.

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

DATOS
información.

14
Análisis estructurado. Diagrama de Flujo de Datos
Ejemplo: “Sistema de Pedidos de Libros” (adaptado del capítulo 2 de Gane, C.
and T. Sarson, “Análisis estructurado de sistemas”).

Diagrama de contexto:

Un DFD de contexto también es denominado modelo fundamental del

sistema o de nivel 0 y representa al software completo como una sola
burbuja (proceso) con datos de entrada y de salida.

15
Análisis estructurado. Diagrama de Flujo de Datos
Diagrama de contexto:

 Es el DFD más general de todos.

 Está formado por un macroproceso (el sistema), las entidades
externas (fuentes y destinos) y sus relaciones con el macroproceso.
 Delimita el sistema y su entorno.

Entorno Facturación

P Gestión de
Sistema caja (pagos)
de
pedidos

Información
sobre el crédito
Gestión del
Entorno
almacén
16
Análisis estructurado. Diagrama de Flujo de Datos
Entidades Externas:

 Señalan los límites del sistema y establecen sus relaciones con el

entorno.

 Los identificadores (nombres) de las entidades externas deben ser

únicos, significativos y concisos.

FUENTE DESTINO

P
FUENTE Sistema

FUENTE DESTINO

17
Análisis estructurado. Diagrama de Flujo de Datos
DFD Nivel 1. Primer nivel de descomposición funcional (Top/down)

18
Análisis estructurado. Diagrama de Flujo de Datos
Niveles de un DFD:

19
Análisis estructurado. Diagrama de Flujo de Datos
Niveles de un DFD:

 Diagrama de Contexto (Nivel 0)

- Es un resumen genérico del sistema.
- Un único proceso y las entidades externas.
 DFD 0 (Nivel 1)
- Modelo con toda la funcionalidad del sistema.
 DFD 1,..., DFD 2,... (Nivel 2)
- DFDs que corresponden a la explosión (descomposición funcional) de
cada proceso padre del Nivel 1.
 Niveles adicionales (3, 4,...)
- DFDs que representan la explosión de procesos contenidos en los DFDs
del nivel inmediatamente anterior.

20
1
Análisis estructurado. Diccionario de datos
El Diccionario de datos contiene la descripción detallada de cada dato del
sistema:

 “Es un conjunto de metadatos, es decir, de información (datos) sobre

datos”.
 Contiene las definiciones de todos los elementos de los diagramas.
 Existirá una entrada por cada flujo de datos o almacén de datos que
aparezca en los DFDs del sistema. Se especificará cada estructura
de datos hasta el nivel más elemental.
 Cada dato debería tener una definición que incluya:
- Comentario que explique el significado en el contexto del
sistema.
- Composición, si no es un dato elemental.
- Valores posibles, si es un dato elemental.

21
Análisis estructurado. Diccionario de datos

Notación:

= está compuesto de
+ concatenación de datos
( ) dato opcional
{ } repetición
[ ] selección de una de las alternativas
* * comentario
@ campo clave para un almacén de datos
| separador de alternativas en el constructor [ ]

22
15
Análisis estructurado. Diccionario de datos
Ejemplos (metadata):
nombre = título_cortesía + primer_nombre + (segundo_nombre) + apellido_paterno +
apellido_materno

título_cortesía = [Sr| Sra.|Don|Doña]

primer_nombre = {caracter_permitido}
segundo_nombre = {caracter_permitido}
apellido_paterno = {caracter_permitido}
apellido_materno = {caracter_permitido}
caracter_permitido = [A-Z|a-z|0-9|‘|-| |]

estado_civil = [s|c|v|d|o]

registro_empleado = * datos de un empleado*

nombre_empleado + num_empleado + fecha_nacimiento + (num_teléfono) +
dirección + estado_civil

23
Análisis estructurado. DFD - Procesos
 Proceso: transforma y/o manipula flujos de datos.
 Nombres únicos, significativos y concisos.
 Preferiblemente expresados en función de las entradas y salidas.
 Nombre: verbo (no ambiguo) + objeto
- Evitar verbos ambiguos: procesar, manejar, hacer...
- “objeto” está definido en el DD

 Los procesos se descomponen en

“subprocesos”, hasta llegar a los
procesos primitivos.

24
5
Análisis estructurado. DFD - Especificación
Son descripciones de la lógica interna de los procesos de los DFDs de
último nivel.

Definen qué debe hacerse para transformar las entradas en salidas.

Métodos (herramientas):
 Lenguaje estructurado o pseudocódigo.
 Pre y post-condiciones.
 Tablas de decisión.
 Árboles de decisión.

Otros:
 Diagramas de Nassi-Schneiderman.
 Diagramas de flujo.
 Descripción narrativa.
25
Análisis estructurado. Lenguaje estructurado
 Implica utilizar el lenguaje natural con algunas restricciones. Verbos
tipo:
}

- Obtener (leer), mover, borrar, escribir, reemplazar, ordenar,

encontrar (buscar o localizar), calcular, validar.

 Equilibrio entre la precisión de un lenguaje formal y la informalidad

y legibilidad del lenguaje natural.

 Una sentencia del lenguaje estructurado podría ser:

- Una ecuación algebraica: X = (Y*Z)/(Q+14)
- Una sentencia imperativa consistente de un verbo y un objeto
(elementos del diccionario de datos).
- Combinación de constructores estructurados (SI - SINO FINSI).

26
Análisis estructurado. Lenguaje estructurado
Ejemplo especificación con lenguaje estructurado proceso 3.5
INICIO
LEER historia_de_pagos, id_cliente, pedido
EN CASO
CASO cliente es nuevo
ENVIAR solicitud_de_pago_previo
CASO cliente es corriente (*promedio de dos solicitudes
mensuales*)
OBTENER balance
SI balance esta vencido más de dos meses
ENVIAR solicitud_rechazada
SI NOENVIAR solicitud_con_credito_ok
FIN_SI
FINCASO
TÉRMINO
27
85
Análisis estructurado. 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: pago pendiente.
Pre2: (la factura excede de 300) o (la cuenta del cliente no tiene ninguna
factura sin pagar más de 60 días)
Pos2: emitir factura.
Pre3: (la factura no excede de 300) y (la cuenta del cliente tiene alguna
factura sin pagar más de 60 días)
Pos3: emitir factura y cambiar calificación de riesgo del cliente.
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: emitir factura.

28
85
Análisis estructurado. Tablas de decisión
Se utiliza la tabla de decisión cuando existen muchas combinaciones.

29
Análisis estructurado. Árboles de decisión
Se recomienda el uso del árbol de decisión cuando el número de acciones
es pequeño y no son posibles todas las combinaciones.

30
Análisis estructurado. DFD - Flujos de datos
Representan “movimientos” de información dentro del sistema.

 Los nombres de los FD deben ser únicos, significativos y concisos.

 Son datos, así que deben nombrase como datos.
 Se recomienda que puedan estar en singular, aunque los DFDs no
se representan cantidades.
 Los nombres no sirven sólo para identificar los datos, sino también la
información que se tiene sobre ellos.
. Ejemplo: Información (fecha-válida) > Información (fecha)

31
Análisis estructurado. Tipos de Flujos de datos
Análisis estructurado. DFD - Especificación
Flujos de datos convergentes/divergentes:

 Se pueden considerar flechas convergentes o divergentes, con un

mismo nombre.
 Sólo los procesos pueden separar FD.

32
Análisis estructurado. Tipos de Flujos de datos

Flujos de datos divergentes:

(Notación System Architect: conectores XOR y AND)

33
Análisis estructurado. Tipos de Flujos de datos
Flujos de datos convergentes:

(Notación System Architect: conectores XOR y AND)

34
Análisis estructurado. DFD - Almacenamientos
D ALMACÉN DE
 Nombre único, significativo y conciso DATOS

 Representan un depósito de datos.

 Archivos o repositorios que conservan información para uso
posterior.
- Ejemplo: una tabla de un modelo de datos relacional.
 Sólo aparecen en los niveles 1..n del DFD.
 Un almacenamiento también puede consistir en datos almacenados
en cualquier soporte que contenga datos (archivos de papel,
tarjetas, etc.).


35
Análisis estructurado. DFD - Almacenamientos
Convenciones de nombres en los FD (flujos de datos) a/desde un
almacenamiento:

A) No lleva etiqueta

El FD se refiere a un paquete (instancia) completo de la información

contenida en el almacenamiento.

Crear
Asignatura

D ASIGNATURA

El flujo de dato hacia el almacenamiento representa una transacción:

SQL: Insert, Delete, Update. Desde el almacenamiento representa una
consulta (SQL Select)
36
 Análisis estructurado. DFD - Almacenamientos
B) 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 almacenamiento.
publicaciones

Imprimir
nuevas D PUBLICACION
publicaciones

C) 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 almacenamiento.
Validar
rut
ID cliente

D CLIENTE

37
Análisis estructurado. 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.
 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.
38
8
 Análisis estructurado. Descomposición funcional
B DESTINO

F
A
FUENTE

f2 X
V f6
f4 Z1 Z2
Z B
f1
A f5 f7

W Y Z3
f3

X X1
f41 f43 X2

f45 Z

f42 f44
Y Y2
Y1

39
Análisis estructurado. DFD - Reglas sintácticas
 El origen y/o el destino de un FD es siempre un proceso.

EXCEPCIÓN: Entidades en nivel de contexto, almacenamientos.

 Todo almacenamiento y todo proceso tienen uno o más FD de entrada

y uno o más FD de salida.

EXCEPCIÓN: un almacenamiento puede no tener FD de salida, por

simplificación (p.ej. BD Histórica).
RECOMENDACIÓN: si aparece un proceso fuente o sumidero
(repositorio), replantearse los límites del sistema.

P P
Fuente
Sumidero

40
Análisis estructurado. Conclusiones

 Los aspectos procedurales no se manifiestan en los DFD.

 Si tales aspectos son relevantes, se deben incluir en las
miniespecificaciones.
 En los DFDs no se muestra el control ni el orden de ejecución.
 El control no aparece hasta el final de la especificación (mini-
especificaciones).
 Los DFD deben ser independientes de la implementación.
 No es inmediato el paso a la codificación y a las pruebas:

“Diseño estructurado”

41
Lecturas relacionadas:

"Modelado del análisis"

“Capítulo 8. R. Pressman, “Ingeniería de Software”, 6° Edición”

42