ANALISIS Y DISEÑO DE

SISTEMAS

SESION 04

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com
 DISEÑO ESTRUCTURADO
Aspectos a considerar:
 Modelamiento de datos
 Definiciones básicas
 Modelo Conceptual
 Modelo de Datos Físico
 Normalización
 Diseño Estructurado

2
Conceptos Básicos

3
 Modelo Entidad Relación
 Se trata de una técnica cuyo objetivo es la
representación y definición de todos los
datos que se introducen, almacenan,
transforman y producen dentro de un
sistema de información

4
 ENTIDAD
 Conjunto de Atributos que describen a una
persona, organización, evento, idea o
cualquier concepto que exista por si mismo.

 Se representan gráficamente
por un rectángulo
ENTIDAD

ATRIBUTOS

5
 ATRIBUTO

 Un atributo es cualquier detalle que sirve

para calificar, identificar, clasificar,
cuantificar o expresar el estado de una
entidad

 Un atributo puede ser un texto, un color,

un dibujo un sentimiento, etc según se
requiera.

6
REPRESENTACIÓN DE ATRIBUTOS

7
 RELACIÓN
 Es una asociación entre dos entidades.
 Tiene 2 extremos, para cada uno de los cuales
se tiene las siguientes propiedades:
- Nombre
- Grado / Cardinalidad (cuántos)
- Opcionalidad (opcional u obligatorio).
 Estas propiedades se utilizan para describir la
asociación y se deben definir en ambos
extremos.
8
REPRESENTACIÓN DE UNA RELACIÓN

Entidad1
Nombre1 entidad1_Entidad2 Entidad2
Nombre2
Cardinalidad
Cardinalidad

9
 Ejemplo

• Una Persona puede tener uno o muchos

carros
• Un Carro pertenece a uno y solo una Persona 10
 IDENTIFICADOR UNICO
 Atributo(s) que permite(n) identificar una
instancia (registro) en particular.
 También conocido como clave.
 Los valores del atributo clave deben ser únicos.
 Para las entidades las claves están dadas por
un solo atributo.
 Para las relaciones las claves están dadas por
concatenación de claves de las entidades
asociadas.
11
 Modelamiento de datos
 Realidad
 Diversa, Ambigua y se percibe o interpreta
 Cada usuario la enfoca de acuerdo a su necesidad y experiencia.
 Real Percebido
 Producto del filtro y percepción.
 Genera datos relevantes.
 Modelo Externo
 Esta dado por todas las pantallas, reportes y documentos fuentes que
el usuario pueda manejar.
 Es el primer nivel de formalismo de los datos.
 Modelo Interno
 Es el más alto nivel de especificación y residen en discos magneticos.
 Están soportados por: Método de Acceso, Estructuras de datos y
Gestores de Base de Datos.
12
MODELO CONCEPTUAL

13
 CARACTERISTICAS

 Lugar intermedio entre el Modelo Externo y

Modelo Interno.
 Punto de acercamiento entre Usuarios y
Analistas de Sistemas.
 Describe conceptualmente al Sistema.
 La estructura del Modelo refleja los procesos y
reglas de gestión de forma implícita y la
naturaleza de los Datos de manera explicita.
 Esta compuesto por entidades y relaciones.
14
 Ejemplo de Modelo Conceptual

CARRO

1 placa
marca
<pi> A6
VA20
<M>
documento
PERSONA
<pi> A11 <M>
modelo VA20 apellido_paterno VA30
serie_motor VA15 pertenece a apellido_materno VA30
tipo_carro VA2 nombre VA50
tiene direccion VA50
ano_fabricacion DC4 Persona_carro
asiento DC3 telefono VA9
color VA15 documento <pi>
placa <pi>

CARRO
PERSONA
placa <pi> A6 <M>
marca VA20 documento <pi> A11 <M>
apellido_paterno VA30

2 modelo
serie_motor
tipo_carro
VA20
VA15
VA2
pertenece a
Persona_carro
apellido_materno
nombre
VA30
VA50
tiene direccion VA50
ano_fabricacion DC4
asiento DC3 telefono VA9
color VA15 documento <pi>
placa <pi>

15
MODELO FISICO DE DATOS

16
 MODELO FISICO DE DATOS

ENTIDADES TABLAS
CLASES

ATRIBUTOS COLUMNAS

IDENTIFICADOR CLAVE PRIMARIA

RELACIONES CLAVE FORÁNEA

17
 CARACTERISTICAS

 Cada registro posee un número fijo de

atributos.

 Cada relación posee una clave.

 Al interior de una relación las ocurrencias

(registros) están ordenadas por sus claves.

18
EJEMPLO DE MODELO FISICO
CARRO

1 num_placa
num_documento
nom_marca
CHAR(6)
CHAR(11)
VARCHAR2(20)
<pk>
<fk> num_documento
ape_paterno
PERSONA
CHAR(11)
VARCHAR2(30)
<pk>

nom_modelo VARCHAR2(20) FK_CARRO_PERSONA ape_materno VARCHAR2(30)

serie_motor VARCHAR2(15) nombre VARCHAR2(50)
tipo_carro VARCHAR2(2) direccion VARCHAR2(50)
ano_fabricacion NUMBER(4) telefono VARCHAR2(9)
num_asiento NUMBER(3)
nom_color VARCHAR2(15)

CARRO
PERSONA
num_placa CHAR(6) <pk>
num_documento CHAR(11) <pk>
nom_marca VARCHAR2(20)
ape_paterno VARCHAR2(30)
nom_modelo VARCHAR2(20)
ape_materno VARCHAR2(30)

2
serie_motor VARCHAR2(15)
nombre VARCHAR2(50)
tip_carro VARCHAR2(2)
direccion VARCHAR2(50)
ano_fabricacion NUMBER(4)
telefono VARCHAR2(9)
num_asiento NUMBER(3)
nom_color VARCHAR2(15)

FK_CARRO__PERTENECE_PERSONA

FK_PERSONA__TIENE_CARRO

Persona_carro
num_placa CHAR(6) <pk,fk1>
num_documento CHAR(11) <pk>
19
 RESTRICCIONES DE INTEGRIDAD

 Reglas del Negocio:

- Integridad de Entidades
- Integridad Referencial
- Dominios
- Triggers

20
 Integridad de Entidades

 Cada ocurrencia de una entidad debe tener

un único identificador (o clave primaria), el
cual no debe ser nulo (null)

21
 Integridad Referencial

 Regla: “Cada valor de una columna de una

tabla que es clave foránea puede ser nulo o
debe tener el mismo valor que en la columna
de la tabla referenciada donde es clave
primaria”

22
 Dominios
 Es el conjunto de tipos de datos y rangos de
valores que los diferentes atributos pueden
asumir.

 Especifican características de los atributos

como:
 Tipo de dato
 Tamaño
 Formato
23
 Triggers

-Un trigger es un mecanismo que activa

automáticamente un conjunto de sentencias
SQL cuando se dan determinadas condiciones
en la tabla.

24
NORMALIZACION

25
 Por Qué Normalizar?

Conseguir un conjunto de tablas relacionadas con la

mínima redundancia donde todo atributo dependa de
su clave así:

A B C D

Supuesto Basico: Buen conocimiento del negocio.

26
La normalización de datos
Vista Usuario

Entidad no normalizada

Eliminar Grupos Repetitivos

Entidades normalizadas
1FN
Eliminar Dependencias Parciales
Entidades en 2FN

Eliminar Dependencias Transitivas

Entidades en 3FN

Conjunto de entidades, relaciones o tablas 27

 DESNORMALIZACION
• Arquitecturas como DW (data warehouse) son ideales para
Sistemas de Soporte de Desiciones (DDS) porque convierten los
datos de una aplicación especifica en datos de soporte a las
decisiones.

• El diseño de arquitecturas de datos para DDS no deben guiarse

por los conceptos de normalizacion de datos ya que estos son un
obstaculo a la hora de acceso a la información.

• La desnormalización en este tipo de arquitecturas de datos permite

la realización de “queries” utilizando SQL estándar, los cuales
serian demasiado complejos y costosos al realizarlos con una
normalización tradicional.
28
 DISEÑO DE
SISTEMAS
ESTRUCTURADO

29
 Diseño Estructurado
Qué es:
• El proceso disciplinado de transformar un
Modelo Lógico de un Sistema en un plan
para la implementación.
Qué no es:
• Diseño Estructurado no es Programación
Estructurada.
• Diseño Estructurado no es Diseño
Automatizado.
30
 Diseño Estructurado: Objetivos

• El objetivo global del Análisis Estructurado es la

transmisión completa, precisa y confiable de los
requerimientos del usuario a la gente que implementará
estos requerimientos.
• El Objetivo del Diseño Ideal es elegir un particionamiento
y organización del sistema mecanizado en componentes
que tengan un mínimo costo de implementación de los
requerimientos del usuario durante la vida del proyecto.
• El Diseño Estructurado nos entrega las herramientas que
nos permiten satisfacer los objetivos del diseño ideal a
partir del resultado del Análisis Estructurado.
31
 Diseño Estructurado

El Diseño Estructurado nos dan:

• Una técnica de documentación gráfica para describir la
visión interna (computacional) del sistema. (Diagrama
de Estructura).
• Una Metodología formal que nos permite durante todo
el proceso ir controlando la complejidad del Sistema.
• Tanto el DFD como el Diagrama de Estructura pueden
ser evaluados en términos del:
• Corrección
• Complejidad
• Comprensibilidad
32
¿Cómo Controlamos la Complejidad?

• Particionando el sistema en sub-sistemas, cada uno

realizando una función concreta, bien definida y fácil
de comprender.
• Refinando los sub-sistemas para independizarlos de
implementaciones anteriores.
• Organizando los sub-sistemas para que ellos sean lo
más independientes unos de otros.
• Agrupando los sub-sistemas altamente relacionados
como uno sólo en un nivel superior como un sub-
sistema más general.

33
 Relaciones del Modelo de Procesos
Lógico al Físico
Diagrama
Contexto

Nivel Nivel Nivel Nivel

DFD’s DFD’s DFD’s DFD’s

PPS PPS PPS PPS PPS PPS PPS

Transformación

MODULOS MODULOS MODULOS MODULOS MODULOS MODULOS MODULOS MODULOS MODULOS MODULOS

DIAGRAMA DE ESTRUCTURA
34
 Diseño Estructurado: El Diagrama
de Estructura
• Representa, vista desde el computador, la interacción
entre los componentes de un sistema.
• Definiciones:

A MODULO

Un Módulo llama a otro Comunicación

A (entrega el control) A entre Módulos
Acoplamiento por
Dato de Control Acoplamiento de
Datos
Ejemplo: PL/I: Procedure

B COBOL: Program, Subprogram

section, paragraph B
35
 Diseño Estructurado: Definición de
un Módulo
Posee 4 atributos básicos:
QUE: EXTERNO
1. Input (Lo que recibe de quien lo llama)
2. Output (Lo que devuelve a quien lo llama)
COMO:
INTERNO
3. Mecánica (Cómo hace su función)
4. Datos Internos
Además:
• Tiene un nombre (Por el cual es llamado)
• Puede usar o ser usado por otros módulos

36
 Características de un Diseño
Estructurado
• Fácil de entender en términos de representación durante
el análisis.
• Un diseño que usa vocablos familiares en datos y funciones a los
negocios, será fácil de mantener.
• Minimiza los efectos del cambio.
• Buena modularidad de datos y funciones hace fácil identificar los
cambios.
• Funciones siguen formas necesarias.
• Implementar sólo lo que es necesario - ni más ni menos.
• Toma lo simple
• Un buen diseño es usualmente el más simple de todas las
alternativas disponibles.
37
 Diseño Estructurado : Especificación
de Módulos
• Diagrama de Estructura muestra la organización o
estructura del sistema, pero omite los detalles (mecánica
de los módulos y datos internos).

• Esto implica que, es necesario especificar cada uno de

los módulos del diagrama de estructura.

• Pueden recomendarse 3 métodos distintos que van de

menos a más en la formalización del problema:
1. Especificación de Módulo por Interfase
2. Utilización del Diseño Estructurado
3. Especificación en Pseudo-código 38
 Diseño Estructurado :
1. Especificación por Interfase
• Método: Calcular Balance Final
• Función: Calcular el Balance Final de los Movimientos
(Débitos y Créditos) de un grupo de clientes del banco
• Usa:
• Tabla de Clientes “PIC 9(6) OCCURS 999 VECES”
• Códigos válidos de Clientes
• Número-Cliente “PIC 9(3). (Número de códigos en la
Tabla CLIENTES).
• Devuelve: Balance Final i.e. SUMA(Débitos - Créditos)

39
 Diseño Estructurado :
2. Utilización del Diseño Estructurado
• Si es que el Diseño Estructurado fue precedido del
Análisis Estructurado la Mini-Especificación de los
procesos de datos pueden ser suficientes para
especificar el Módulo.
• Aunque no siempre hay una correspondencia exacta
entre “Burbujas y Módulos”. Las diferencias típicas
incluyen control, reportes de error, acceso físico a
archivos y factorización de una Burbuja en muchos
Módulos.
• El programador puede sin embargo, trabajar con las Mini-
especificaciones y el Diagrama de Estructura.
40
 Diseño Estructurado :
3. Pseudo-Código
• Es preciso en el procedimiento reflejar la estructura organizacional del Diseño
• Módulo: Cálculo del Balance Final de Movimientos
/* Encuentra el Balance ...
... especificados por una Tabla de sus códigos */
• Usa: Tabla-Código-Cliente
/* Contiene los Números de Tas. de Clientes */
Número de Clientes
/* El total de clientes */
• Proc: Ponga Balance-Final en 0.
Repeat varying Contador desde 1 hasta No-Clientes
Perform Obtenga-Movimientos using No-Cta.
receiving Débito, Crédito
Sume (Crédito - Débito) a Balance-Final
End Repeat
• Devuelve: Balance-Final
/* Balance Neto del Grupo */
FIN -MODULO 41
 ¿Cómo Transformar Mallas en
Estructuras Jerárquicas?
Primera Versión del
DFD FISICO Diagrama de Estructura
(Malla)
Obtener
Jerárquico
Diseño
Inicial

• Las estrategias de obtención (Derivate Strategies) son un conjunto

de técnicas que nos permiten generar un diseño razonablemente
bueno y en forma rápida.
• Las Técnicas son:
1. Análisis de Transformaciones
2. Análisis de Transacciones
3. Factorización de Arriba-Abajo (Top-Down)

42
Diseño Estructurado:
El Procedimiento de Derivación
DFD Diagrama de
FISICO 1. Análisis
de Transfor- Estructura
maciones

2. Análisis de
Transac-
ciones
3.
Factorización
Top-Down
Diagrama de
Diagrama de Estructura
Refinamiento Estructura
con Técnicas Mejorado
Preliminar

43
 El Procedimiento de Derivación:
1. Análisis de Transformaciones
Diagrama de Estructura
DFD FISICO Balanceado
(Malla) Análisis de
Transforma-
ciones

• El Análisis de Transformaciones es una técnica para

definir una buena estructura jerárquica balanceada
basada en el DFD.
• La idea es manipular el DFD de manera que los procesos
centrales terminen como módulos de transformación
central y los procesos físicos se transformen en los
módulo de las jerarquías aferentes y eferentes.

44
 El Procedimiento de Derivación:
1. Análisis de Transformaciones
• Jerarquía Balanceada:
• El módulo raíz supervisa la transformación de entradas
lógicas en salidas lógicas. Para ello llama varios tipos
de jerarquías subordinadas:
• Subjerarquías Aferentes (Inputs al Mod. Central)
• Subjerarquías de Transformación Central (Transf.)
• Subjerarquías Eferentes (Outputs desde el Mod.
Central)

45
Estrategia de diseño centrada en
transformaciones
z C p
y B q
D
x A Módulo
Ejecutivo E r
z p
z
Obtener Producir
y una “z” C una “p” q
p q
Obtener Producir
una “y” B D una “q”
x
r r
Obtener Producir
una “x” A E una “r”

46
 El Procedimiento de Derivación:
2. Análisis de Transacciones
• Para nuestros propósitos una transacción es cualquier
flujo de datos que:
• viene en distintas formas
• contiene un elemento de identificación de datos que
nos dice qué forma tiene
• Dependiendo de la forma, se toman acciones. Ejemplo:
T1 T
T2
T
T1 T4
T3 T2 T3
T4
47
 El Procedimiento de Derivación:
3. Factorización Top-Down
• Factorizar es dividir el módulo en un Jefe y en varios
subordinados a los que se llama para realizar la labor.
horas-trab horas-trab
tarifa tarifa
pago-bruto pago-bruto

Calcular Calcular
Remunerac. Remunerac.
Bruta tarifa
Bruta tarifa
horas-norm horas-ext.
p.bruto ext.
p.bruto norm
Calcular Calcular
Horas Horas
Normales Extra

Horas-Trabaj. = Horas-norms + Horas-Ext.

48
 Diseño Estructurado: Evaluación y
Refinamiento
• Criterios de Evaluación del Diseño:
• Cohesión y Acoplamiento son los criterios
fundamentales para evaluar la calidad del diseño
• Cohesión: Es la fuerza o criterio que une los elementos de un
componente.
• Acoplamiento: Es la medida de la dependencia de un
componente que está comunicada con otra.
• Máxima Cohesión => Mínimo Acoplamiento.
• El Objetivo global que se debe tener en cuenta al
evaluar y refinar un diseño es el de hacer máximo
el grado de independencia entre los módulos.
49
 Diseño Estructurado:
Tipos de Acoplamiento
0. Traspaso de Control Mejor
1. Traspaso de Datos
2. Acoplamiento de Huella
3. Acoplamiento por datos de control
4. Area Común
5. Contenido Peor

50
 Diseño Estructurado:
Tipos de Cohesión

0. Funcional Mejor
1. Secuencial
2. Comunicacional
3. Procedimiento
4. Temporal
5. Lógica
Peor

51
Decisiones y Actividades para subdividir el
sistema en unidades implementables
(Empaquetamiento)
• Criterios a utilizar
• Hardware (máquinas distintas)
• Modo Procesamiento (batch, en línea,
etc.)
• Periodicidad

52
 Herramientas CASE. Generalidades
• Apoyo automático a una o todas las fases de desarrollo
de sistemas
• Planificación, Análisis, Diseño, Generación de código
• Apoyo a la reingeniería de software
• Características generales
• Interfaz gráfica y textual
• Diccionario central de datos
• Conjunto de herramientas de diseño, que abarca ayudas para la
diagramación, rutinas para generar prototipos y códigos
• Bibliotecas de diseño, tanto genéricos como desarrollados
previamente, que sirvan como punto de inicio para el desarrollo
de nuevos diseños
53
 Herramientas CASE. Clasificación

Ing.
Reversa

Planif. de
Análisis Diseño Construcc.
Sistemas

Upper-Case Lower-Case
I-Case 54
 Herramientas CASE

Apoyo Procesos Físicos

• Editor de diagramas de esquema de datos

• Interfaz textual para especificar módulos
• Analizador de esquema de procesos físicos
• Especificación del diseño, punto de entrada para
generación automática de código

55
 Resumen
• La Fase de Análisis Lógico provee las entradas a la Fase
del Diseño Físico
• Diseño Físico proporciona las bases para el Desarrollo
• Diseño Estructurado es un conjunto de reglas y técnicas
que asisten a un diseñador de sistemas en determinar qué
módulos, interconectados de alguna forma, será la mejor
solución para un problema
• Las capacidades de Análisis y del Repositorio de Datos de
las herramientas CASE pueden ser usadas para ayudar a
particionar el modelo propuesto en una jerarquía de
funciones
• Una Carta/Diagrama de Estructura es un gráfico jerárquico
que documenta el diseño de un sistema o un programa.56
 Analisis y Diseño de Sistemas

FIN Sesión 4

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com 57