Get documents about "Presentacion 4 Analisis DFD
Document Sample
Capítulo 4
Enterprise Modeling
Prof. Nelliud D. Torres
1 1
Introducción
• En este capítuo se van a utilizar las técnicas
enterprise modeling para desarrollar un
modelo lógico del sistema propuesto y para
documentar los requerimientos del sistema.
– Logical model – Muestra lo que el sistema debe
hacer.
– Physical model – Describe como es que el
sistema será construido. (Fase de Diseño)
2 2
CICLO DE DESARROLLO DE SISTEMAS
Capítulos 3 - 5
Capítulo 2
PLANIFICACIÓN ANÁLISIS
Aprobación
del usuario
Vida útil
Especificaciones de Capítulos 6 - 8
Input, Output,
MANTENIMIENTO Processing y control DISEÑO
Capítulo 10 HCI – Human computer
Pruebas, conversión, interface
adiestramientos y
documentación.
IMPLANTACIÓN DESARROLLO
Capítulo 9 Capítulos 6 - 8 3 3
FASE DE ANÁLISIS
ANÁLISIS
DATA AND DEVELOPMENT
REQUIREMENTS
PROCESS STRATEGIES
MODELING (Capítulo 5)
(Capítulo 3)
MODELING
(Capítulo 4)
4 4
Enterprise Modeling Tools
• Los analistas de sistemas utilizan muchas
técnicas gráficas para describir un Sistema de
Información
• Dos herramientas populares son el entity-
relationship diagram (Se discutirá en el
capítulo 7) y el data flow diagram (DFD)
• Un data flow diagram (DFD) utiliza varios
símbolos para mostrar como el sistema
transforma datos de input en información útil.
5 5
Data Flow Diagrams
• Un data flow diagram (DFD) muestra como la
data se mueve en un Sistema de Información
sin mostrar pasos de lógica o de procesos.
• Un conjunto de DFDs muestran un modelo
lógico que explica lo que el sistema hace y no
como lo hace.
El analista utiliza
con frecuencia
ayudas visuales
durante las
presentaciones.
6 6
Data Flow Diagrams
• Símbolos del DFD
– Los DFDs utilizan
4 símbolos básicos
que representan:
processes
(procesos), data
flows(flujo de
datos), data stores
(almanecamiento
de datos), y
entities (entidades)
7 7
Data Flow Diagrams
• Existen dos
tipos de
diagramas:
• Gane and
Sarson
symbol
set
• Yourdon
symbol
set
8 8
Data Flow Diagrams
Nosotros vamos
a utilizar: Gane
and Sarson
9 9
Data Flow Diagrams - Process
• Símbolos DFD
– Process symbol (proceso)
• Recibe data de input y produce output que tiene
un formato o contenido diferente o ambos.
• Contiene la lógica del negocio también conocida
como reglas (rules)
• Se le define también como una caja negra.
10 10
Data Flow Diagrams - Process
Los procesos pueden ser bien sencillos o
complejos. Algunos ejemplos pueden
ser:
1. Calcular tendencia de ventas.
2. Llenar una reclamación de seguro en
línea.
3. Ordenar inventario de un sistema de
suplidores.
4. Verificar el e-mail de un cliente de Web.
11 11
Data Flow Diagrams - Process
El símbolo de un proceso es un rectángulo con las
esquinas redondeadas. Otras características
importantes son:
1. El nombre del proceso aparece dentro del
rectángulo.
2. Identifica una función específica del sistema.
3. Consiste de un verbo (y un adjetivo si hace falta)
seguido de un nombre en singular.
4. Algunos ejemplos son:
• APPLY RENT PAYMENT
• CALCULATE COMMISION
• ASSIGN FINAL GRADE
• VERIFY ORDER
• FILL ORDER
12 12
Data Flow Diagrams – Data flow
Es un sendero (path) o data que se mueve de una
parte a otra en un Sistema de Información. Otras
características importantes son:
1. Puede consistir de un solo data item (ej. número
de estudiante) o un conjunto de varios datos.
2. No detalla el contenido de los datos (eso lo hace
el data dictionary).
13 13
Data Flow Diagrams – Data flow
1. El símbolo consiste de una línea con una flecha sencilla o
doble en la punta.
2. El nombre del data flow casi siempre aparece arriba de la
línea,pero puede ser abajo también.
3. El nombre consiste de un nombre singular y de un adjetivo
si hace falta.
4. Algunos ejemplos de nombres son:
• DEPOSIT
• INVOICE
• PAYMENT
• STUDENT GRADE
• ORDER
• COMMISSION 14 14
Data Flow Diagrams – Combinaciones
correctas
Data Flow & Process
• Por lo menos debe entrar y
salir un símbolo tipo data
flow hacia y desde un
símbolo process.
• Los procesos pueden tener
más de un data flow de input
o output.
• Un data flow debe tener por
lo menos un proceso en una
de sus extremidades.
• Un proceso se puede
conectar a otro proceso a
través de un data flow.
15 15
Data Flow Diagrams – Combinaciones
INcorrectas
• No puede haber un
proceso con dos outputs
y sin ningún input
(spontaneous
generation)
• Tampoco puede haber un
proceso con dos inputs y
sin ningún output (black
hole)
• Si el input no es suficiente
para generar eloutput
también está incorrecto.
(gray hole)
16 16
Data Flow Diagrams – Data Store
• DFD Symbols
– Data store symbol
• Representa data que el sistema almacena
• Las características físicas del almacenamiento de
los datos no es importante ya que solo estamos
enfocado con el modelo lógico.
• Es importante almacenar los datos para
referencias futuras (Ej. W2)
• Su almacenamiento puede durar solo segundos o
años.
• Lo importante es destacar que más adelante algún
proceso va a necesitar esos datos. 17 17
Data Flow Diagrams – Data Store
• Su forma es de un rectángulo el cual está abierto en la parte
derecha y cerrado en la izquierda.
• El nombre del Data Store aparece adentro e identifica la
data que contiene.
• Su nombre es plural y consiste de un nombre y adjetivo si
hace falta.
• Ejemplos de nombres pueden ser:
– STUDENTS
– ACCOUNTS RECEIVABLE
– PRODUCTS
– DAILY PAYMENTS
– PURCHASE ORDERS
– OUTSTANDING CHECKS
– INSURANCE POLICIES 18 18
– EMPLOYEES
Data Flow Diagrams – Combinaciones
Correctas - Data Store
19 19
Data Flow Diagrams – Combinaciones
INcorrectas - Data Store
No se pueden conectar dos data store sin que haya de
intermediario un proceso. Cada data store debe
tener un data flow de input y de output. 20 20
Data Flow Diagrams - Entity
• DFD Symbols
– Entity Symbol
• Denota entidades externas.
• Estas entidades proveen data al sistema o reciben algún
tipo de output.
• Muestra como el sistema se relaciona (interface) con el
mundo exterior.
• También se llaman terminators debido a que originan o
reciben datos.
– Source – La entidad suple data al sistema.
– Sink – La entidad recibe data del sistema.
21 21
Data Flow Diagrams - Entity
• DFD Symbols
– Entity Symbol
• El símbolo es un rectángulo con sombra que de la
apariencia de 3D.
• El nombre de la entidad aparece adentro del símbolo.
• Algunos ejemplos de entidades pueden ser:
– Cliente que somete una orden
– Paciente que suple de data un sistema médico
– Dueño de un hogar que recibe un cobro de propiedad inmueble.
– Sistema de cuentas a pagar que recibe datos del sistema de
compras. 22 22
Data Flow Diagrams – Combinaciones
Correctas - Entity
23 23
Data Flow Diagrams – Combinaciones
INcorrectas - Entity
No se pueden conectar dos entidades. Una entidad
tiene que estar conectada a un proceso y no
24 24
directamente a un data store. Sea de input o de output.
Creating a Set of DFDs
• Se va a crear un modelo gráfico de un
sistema basado en los resultados
encontrados (fact finding)
• Se ejecutan tres tareas principales:
– Step 1: Dibujar un context diagram
– Step 2: Dibujar un diagrama 0 DFD
– Step 3: Dibujar los diagramas de menor nivel
25 25
Creating a Set of DFDs
Guías para dibujar el Context Diagram
1. Dibuja el context diagram de modo que quepa en una
sola página.
2. Usa el nombre del sistema como el nombre del
proceso inicial en el context diagram
3. Utiliza nombres únicos en cada conjunto de símbolos
4. No tires líneas que se cruzen
5. Provee un nombre y número de referencia único para
cada proceso.
6. Busca insumo (input) y retroalimentación (feedback)
de parte del usuario.
26 26
Creating a Set of DFDs
Dibuja el Context Diagram de un sistema de registro
27 27
Creating a Set of DFDs
Dibuja el Context Diagram de un sistema de orden de compra
28 28
Creating a Set of DFDs
Dibuja el Context Diagram de un sistema de manufactura
29 29
Creating a Set of DFDs
• Dibuje el Diagram 0 DFD
– Diagram 0
– Expande el context diagram y muestra los
procesos más importantes, el flujo de datos y
los data storages.
– Tiene que mantener todas las conecciones
que se definieron anteriomente (data flow)
– Cada proceso tiene un numero propio
– Diverging data flow
30 30
Creating a Set of DFDs
• Dibujar el Diagrama 0 DFD
– Si la misma data fluye en ambas direcciones,
se puede utilizar la flecha con doble cabeza.
– El Diagrama 0 representa una visión más
amplia del proceso 0.
– Se establece una relación Parent – Child
entre ambos diagramas.
– Functional primitive
31 31
Diagrama 0 - Registro
32 32
Diagrama 0 – Orden de Compra
33 33
Diagrama 0 - Manufactura
34 34
Creating a Set of DFDs
• Dibujar los niveles de menor nivel
– El analista debe ir creando niveles hasta que
pueda descomponer el Sistema en todos sus
procesos
– Debe utilizar técnicas de niveles (leveling) y
balanceo (balancing)
– Leveling
• Se van detallando los DFD hasta que se describan
todos los componentes del sistema
• Esta técnica se conoce también como exploding,
partitioning, o decomposing
35 35
Creating a Set of DFDs
• Ejemplo de como descomponer el proceso 1
(FILL ORDER) del sistema de compras
36 36
Creating a Set of DFDs
• Draw the Lower-Level Diagrams
– Balancing
• Se asegura de que los data flows de input y output
del DFD padre (parent) se siguen manteniendo en
el DFD hijo (child)
• A continuación se muestra un ejemplo
37 37
Diagrama 0 – Sistema de Compras
Vamos a
detallar este
diagrama
38 38
Detalle Proceso 3 – Sistema de Compras
Mantiene los
mismos data
flows
anteriores en
adición a los
que se crean
nuevos.
39 39
Creating a Set of DFDs – Ejemplo 2
Contex
Diagram de
un Sistema.
Tiene dos
inputs y dos
outputs data
flow
40 40
Creating a Set of DFDs – Ejemplo 2
En el próximo
nivel se
puede
observar que
se mantienen
los data flows
originales y
se crean
cuatro data
flows
internos, dos
data store y
tres procesos.
41 41
Ejemplo DFD de SSS del grupo
Alphasolutions
42 42
Ejemplo DFD de SSS del grupo
Alphasolutions
43 43
Data Dictionary
• Un data dictionary, o data repository, es
un central storehouse de información
relacionada a la data del sistema
• Un analista utiliza el data dictionary para
colectar, documentar y organizar
factores en específicos del sistema.
• También define y describe todos los
data elements y sus combinaciones
significativas con otros data elements
44 44
Data Dictionary
• Un data element, también llamado un data item
o campo (field), es el componente de data
menor que tiene significado en el sistema
• Los data elements se combinan para componer
records, también llamados data structures
• Un record es una combinación significativa de
data elements relacionados que se mencionan
en los data flows y en los data store
45 45
Contenido de un Data Dictionary
46 46
Data Dictionary
• Documentando los
Data Elements
– Se debe documentar
cada data element en
el data dictionary
– El objetivo es proveer
información clara y
comprensiva sobre
los datos y procesos
que componene el
sistema
47 47
Data Dictionary
• Documentando los Data Elements
– Los siguientes atributos usualmente se incluyen en la
documentación
• Data element name or label
• Alias
• Type and length
• Default value
• Acceptable values - Domain and validity rules
• Source
• Security
• Responsible user(s)
• Description and comments
A continuación se muestra una forma que se puede utilizar para
documentar los data elements. (Pag: 168)
48 48
EJEMPLO FORMA
DOCUMENTAR DATA ELEMENTS
49 49
Data Dictionary
• Documentando los Data
Flows
– Los atributos típicos son:
• Data flow name or label
• Description
• Alternate name(s)
• Origin
• Destination
• Record
• Volume and frequency
50 50
Data Dictionary
• Documentando los
Data Stores
– Los atributos típicos
son:
• Data store name or label
• Description
• Alternate name(s)
• Attributes
• Volume and frequency 51 51
Data Dictionary
• Documentando los
Procesos
– Los atributos típicos
son:
• Process name or label
• Description
• Process number
• Process description
52 52
Data Dictionary
• Documentando las
Entidades
– Los atributos típicos son:
• Entity name
• Description
• Alternate name(s)
• Input data flows
• Output data flows 53 53
Data Dictionary
• Documentando los
Records
– Los atributos típicos
son:
• Record or data structure
name
• Definition or description
• Alternate name(s)
• Attributes
54 54
Data Dictionary
• Data Dictionary Reports
– Puede generar muchos reportes importantes:
• Todos los data elements en orden alfabético por nombre.
• Reporte que describe cada data element e indica el
usuario o departamento responsable de entrar el dato,
actualizarlo o eliminarlo
• Reporte de todos los data flows y data stores que utilizan
un data element en particular
• Reporte detallado que muestre todas las caracteristicas
de los data elements, records, data flows, processes, o
cualquier otro item del data dictionary.
55 55
Process Description Tools
• Un process description documenta los
detalles de un functional primitive (el
proceso mas pequeño de un DFD), y
representa un conjunto específico de
pasos relacionados a la lógica del negocio
(business logic)
56 56
Process Description Tools
• Modular Design
– Se basa en la combinación de tres estructuras
lógicas también llamadas control structures que
sirven como definiciones claves (building blocks)
para el proceso. Las tres estructuras son:
1. Sequence
2. Selection
3. Iteration - looping
57 57
Sequence
• Completa los pasos en orden secuencial
uno detras del otro. Uno o más de esos
pasos puede representar un sub-proceso
que contenga estructuras (instrucciones)
lógicas adicionales.
58 58
Selection
• El completar uno o más pasos depende
del resultado de una prueba o condición
anterior.
59 59
Iteration - looping
El completar una serie de pasos que se repiten
hasta que una condición en particular cambia.
60 60
Process Description Tools
• Structured English
– Debe seguir las siguientes reglas:
• Solo utilizar las tres estructuras anteriores
• Utilizar indentación para mayor claridad
• Utilizar un vocabulario limitado que incluya
termninos estandar y palabras específicas que
describan las reglas de procesamiento
61 61
Process Description Tools
• Structured English
– Como se puede apreciar, es similar al pseudocode
62 62
Process Description Tools
• Decision Tables
– Muestra una estructura lógica con todas las
posibles combinaciones de condiciones y
resultados (accciones)
– Es importante considerar cada posible resultado
para asegurarse de que se cubrieron todas las
posibilidades
63 63
Process Description Tools
• Decision Tables
– Debe tener más de dos posibles resultados
– En muchas ocasiones es la mejor forma de evaluar
un grupo complejo de condiciones
64 64
Process Description Tools
• Decision Trees
– Representación gráfica de las condiciones,
acciones y reglas que se encuentran en un decision
table
– Si se va a utilizar un decision table o un decision
tree es cuestión de preferencia
65 65
Logical Versus Physical Models
• Mientras que estas herramientas (tools) se
utilizan para desarrollar modelos lógicos
para un nuevo sistema, también se
pueden utilizar para desarrollar modelos
físicos de un sistema nuevo de
información.
• Recordatorio – Un modelo físico muestra
como los requerimientos del sistema son
implementados
66 66
Logical Versus Physical Models
• Sequence of Models
– Muchos analistas crean el modelo físico del
sistema corriente y luego crean un modelo
lógico también del sistema corriente antes de
crear el modelo lógico del nuevo sistema.
– El hacer estos pasos extra, le ayuda al
analista a entender mejor como funciona el
sistema actual
67 67
Logical Versus Physical Models
• Four-Model Approach
1. Desarrolle un modelo físico del sistema
corriente
2. Un modelo lógico del sistema corriente
3. Un modelo lógico del nuevo sistema
4. Un modelo físico del nuevo sistema
– La única desventaja de este método es el
tiempo y costo adicional
68 68
